Applying Domain-Driven Design to IGA Integrations
Should IGA solutions apply the Conformist or Anticorruption Layer pattern when integrating with IT systems?
Next week, on Thursday December 11th at 12:00pm CST, I will appear as a guest on Identerati Office Hours Episode 158 to discuss Declarative IGA.
Domain-Driven Design (DDD) has shaped how I think about software since around 2006 when I first read Eric Evans’ book Domain-Driven Design: Tackling Complexity in the Heart of Software. At the heart of DDD is the concept of a bounded context, which drives a ubiquitous language that is shared among software developers and domain experts. I have hinted at some aspects of DDD in a previous article, but this week I want start getting more explicit about how DDD has influenced my view of IGA (identity governance and administration).
A key challenge of IGA is the ingestion and manipulation of authorization data across numerous IT systems. Many of these IT systems are heterogeneous in the sense that they implement distinct authorization models. Aside from the nearly ubiquitous Active Directory Domain Services (ADDS), there may be various LDAP directories, UNIX/Linux platform systems, databases, content management platforms, mainframe security providers, cloud infrastructure providers, SaaS applications, ERP applications, custom applications and so on.
If IGA itself is considered to be a bounded context, then the IT systems with which an IGA solution integrates are contexts as well. With DDD, the relationships between these contexts are observed and analyzed through a Context Map. Typically in a Context Map, upstream contexts are shown above downstream contexts. The simplest version of an IGA Context Map, with explicit references to various types of IT system integrations, is shown below.
This simple Context Map is not too interesting, but it does get us started down the path of characterizing the relationship between IGA (downstream, labeled as D) and its integrations with upstream (labeled as U) IT systems. DDD does not dictate any particular manner of integration between contexts, but it does provide a vocabulary for describing the patterns of integration that are available. This provides an opportunity to systematically analyze the relationships between IGA and the upstream contexts to characterize the nature of each integration.
DDD considers this activity to be strategic design, and several organizational and integration patterns have been defined for integrating contexts. In the context of IGA, all upstream contexts are independent of the IGA solution, so it is likely that only three patterns are candidates for consideration:
Customer/Supplier Development: The upstream context may accommodate downstream needs similar to a customer-supplier relationship
Conformist: There is no possibility of changes to upstream contexts to suit downstream needs, causing the downstream context to conform to the upstream context by adopting elements of its models
Anticorruption Layer: Translation layers are needed to defend the downstream model from pollution caused by an upstream context’s models
For example, a customer-supplier relationship may be possible with an organization’s custom applications. Certain application teams may see a benefit to integrating with the IGA solution, so they may be open to making changes to their applications to ease integration. Essentially, these teams are sharing the burden of translation between models with the IGA solution. This could take many forms, including:
Create a custom API, perhaps based on SCIM (System for Cross-domain Identity Management), for the IGA solution to consume authorization-related resources and execute commands
Create a custom database view with authorization constructs such as accounts and permission assignments for the IGA solution to consume and potentially manipulate
Provide a specifically formatted report for consumption by the IGA solution
Forward certain events to the IGA solution
This pattern is common with organizations that have built their own IGA solutions. Even with commercial solutions, some organizations have extended this approach beyond their custom applications by mandating that all systems provide feeds of authorization-related information to their IGA solutions, occasionally through something characterized as an authorization data warehouse. Such mandates can make life easier for the team operating an IGA solution, but may also impose significant costs throughout the organization that can be difficult to isolate and control.
Conformist is an integration pattern adopted by some IGA solutions, whereby the structures and vocabularies of upstream authorization models are imported into the IGA context. The implication is that the IGA solution provides minimal abstraction for IT-side elements. For example, an IGA solution integrating with ADDS might distinguish between local, global and universal groups.
There are some potential advantages to the Conformist pattern, such as direct support for a richer set of authorization models than might be possible with typical IT-side abstractions. This offers more opportunities for managing the authorization models of target systems themselves. For example, if an IT system supports an RBAC model where roles are composed of fine-grained access rights, the IGA solution could be used to manipulate the composition of roles in the system itself. An indicator of an IGA solution that has applied the Conformist pattern is when the terminology of target system contexts is adopted internally, where one type of integration may model accounts assigned to groups and another type may model accounts assigned to roles.
From an IGA perspective, the Conformist pattern usually imposes a much more IT-centric experience than may be desirable. A more business-friendly alternative involves more thorough abstraction or generalization of authorization models provided by upstream contexts. This more defensive approach to integration is a realization of the Anticorruption Layer pattern.
Whereas the Conformist pattern attempts to minimize the complexity of integration by allowing elements of other contexts’ models to leak into the core domain’s context, the Anticorruption Layer pattern accepts more integration complexity to defend its models from corruption. An Anticorruption Layer performs two-way translation between the upstream and downstream contexts’ models. From a design perspective, IGA solutions applying the Anticorruption Layer pattern have abstracted the models of the upstream contexts in a manner similar to the Context Map below.
In this case, the IGA context provides an Anticorruption Layer to handle integration with an abstracted context that represents the entire universe of systems that could be integrated. Such an Anticorruption Layer is implemented with adapters that handle translation between the IGA models and the IT systems’ models. This is consistent with how most IGA solutions tend to handle IT system integrations.
IGA solution developers typically face a dilemma when selecting a preferred pattern for integrating with upstream contexts. IGA serves multiple constituencies within an organization, ranging from business users who care little about the details of upstream systems’ authorization models to various domain experts who care a great deal about upstream systems’ authorization models. The choice of context integration pattern comes down to the bias of developers toward a particular constituency.
Committing to either the Conformist or Anticorruption Layer pattern for IT system integration is a defensible position. Where I have seen developers run into trouble is when they fail to commit to one pattern and end up mixing elements of both. This often leads to excessive complexity and confusion for both sets of competing constituencies.
This is why DDD considers context mapping to be a strategic design activity. Integration between contexts is something that must be considered carefully throughout development — it’s one of those decisions that is hard to change. If the development team (in consultation with other stakeholders) decides to change a pattern, the change should be accompanied by a decisive refactoring of models and implementation. Unfortunately, what often happens is that developers don’t have a clear understanding of the strategic design, which allows them to be pushed in multiple directions that make integrations messy — this is how the Big Ball of Mud anti-pattern materializes.
One thing that I have observed in commercial software development in general is that executives dislike refactoring. The pressure for new feature development is immense because vendors operate in competitive markets, so executives are suspicious of anything that seemingly distracts from adding new functionality. These same organizations often claim to adhere to agile software development principles, perhaps not realizing that refactoring is a fundamental contributor to maintaining code quality. Refactoring can make designs more supple, allowing new functionality to be added more quickly. The alternative is for diminishing returns on feature work over time as developers must contend with increasing technical debt, which is the reality for most vendors.