This article is the third in a series of three looking at a proposed common Identity Governance Data Model (IGDM). This third article suggests an implementation of the module using a SCIM-like approach.
This model attempts to address the needs of managing heterogeneous complex target system access models in an Identity Governance and Administration (IGA) environment.
The proposed IGDM is designed to standardize identity management and governance data flows between IGA systems and target systems hosting access repositories, by providing a common data structure that could be implemented with clients/servers at both the IGA systems and the target systems.
The proposed data model is shown below.
It provides for a standard set of objects, such as Person, Account, Resource and Permission, and relationships between objects. This allows for different target system access models, some which apply changes via objects and attributes, and some which apply changes via relationships.
This article will propose an implementation of the IGDM using a SCIM-like approach to address the needs of hybrid-cloud and multi-cloud environments, whilst managing the variability that you will get with different IGA object schemas (e.g. different account types). This is the last article in the series.
Introduction
The previous articles in this thread presented and validated a proposed Identity Governance Data Model (IGDM) to meet the needs of large and complex Identity Governance and Administration (IGA) ecosystems with identity management/governance tools and target systems with complex access models.
The proposed IGDM is shown in the following figure.
It describes a set of objects and relationships to provide a standard approach to IGA data that is shipped between IGA tools and target systems.
This data model supports the variability in object schemas we see across IGA systems, such as different account types, or different access or resource types. However, it needs an implementation to become real.
Prior attempts at creating a standard identity management data model have had limited traction in the marketplace and vendors have either implemented bespoke models or heavily extended common models. Solutions like LDAP Data Interchange Format (LDIF), Directory Services Markup Language (DSML) and Service Provisioning Markup Language (SPML) were seen by the industry as very flexible but complex and bloated, particularly in the cloud era. They are also more focused on the implementation of the methods rather than the data.
The System for Cross-Domain Identity Management (SCIM, or Simplified Cloud Identity Management) was designed to be lightweight and internet-friendly leveraging Representational State Transfer (REST) protocols, but the resources defined are way too simple for complex IGA needs.
This article will present how IGDM could be implemented in a SCIM-like protocol to leverage the benefits of SCIM but also support the variability needed of complex access models without having to constantly rewrite SCIM endpoints.
Implementing the IGDM
A possible implementation of the IGDM involves leveraging protocols that are HTTP friendly and lightweight, but flexible enough to support multiple object schemas (like different account types) without constantly rewriting endpoints. As discussed above, older standards like SPML, DSML and LDIF are not appropriate. We will explore implementing IGDM in a SCIM-like protocol.
Why Not Just Use SCIM?
SCIM certainly ticks many of the boxes of a modern identity data transfer protocol; it leverages REST for the endpoints and methods and JSON for lightweight data definition.
But the standard SCIM defines a limited set of resources; User (common user and account object), Group (collection of users) and others you can define. There is no delineation of users from accounts, and the data model is simple so to use it for IGDM would require extensions to the supplied resource types or creation of new ones.
The standard SCIM resources aren’t a good fit for the IGDM, as shown in the following table.
Note 1. – The IGDM Account object can be partially met by the SCIM User resource.
The implication of the SCIM design is that any extended or new resource types involves modifying the endpoints to build/extract the resource contents. If an endpoint is written to process Account objects, then it would need to be modified to handle (for example) AD Account or RACF Account objects. This restricts its use when there will be many resource types (e.g. many account types with different attributes) and also limits interoperability if you change the endpoints.
Also, there is no concept of accesses or target system resources, so these would also need to be defined. Using standard SCIM for the IGDM would be a lot of work.
A SCIM-like Implementation – Light and Flexible
Given that legacy standards like DSML and SPML are considered prescriptive but heavy, and SCIM is considered lightweight but needing extensive work to support the complexity of IGDM, can we develop an implementation that leverages the best of both approaches?
We could build a SCIM-like implementation (REST-based) that implements a small set of IGDM object types, and each could support a mix of fixed and variable content. The IGDM object types are: Person, Account, Access, Permission, Resource and Mapping.
Each of these would have a standard fixed component, like in the current SCIM implementation, for each of the object types. They would also have a variable component that supports the different variations of object type. For example, an Account object would have a fixed portion for all Account objects, plus a variable portion for the different account types, like AD and RACF.
Implementation of the endpoints would need to be coded to handle the object type, like Account, and then pluggable components would provide the logic and schema to support processing specific account types, like AD or RACF. This is shown in the following figure.
With the endpoints coded to support the object types defined in the IGDM (Person, Account, Access, Permission, Resource and Mapping) the endpoint should not need to change. Then the pluggable components, say for AD or RACF, can be added or updated without changing the endpoint.
Being REST-based, this SCIM-like implementation could use the standard REST operations, such as:
- Create: POST https://example.com/{v}/{resource}
- Read: GET https://example.com/{v}/{resource}/{id}
- Replace: PUT https://example.com/{v}/{resource}/{id}
- Delete: DELETE https://example.com/{v}/{resource}/{id}
- Update: PATCH https://example.com/{v}/{resource}/{id}
- Search: GET https://example.com/{v}/{resource}?filter={attribute}{op}{value}&sortBy={attributeName}&sortOrder={ascending|descending}
- Bulk: POST https://example.com/{v}/Bulk
It would also support the other SCIM mechanisms, like use of JSON and authentication.
Implementation Examples
This section describes some sample implementations of standard IGDM object types; Person, Account, Access, Permission and Membership.
The Person object may need to support different Person types (such as employee and contractor) that may share some attributes, but also have unique attributes. These could be based on the SCIM Person schema.
It would have a standard structure, and the flexible blob, as shown in the following example.
Similarly, the Account object type needs to support different account schemas, each with very different attribute sets. An example of this is shown below.
In IGDM we defined different types of Access; AccessGroup = collection of users, AccessRole = collection of permissions, ACLs = M:N mapping of users/groups to permissions/resources, and AccessRules = code/rule used for access evaluation. As with the Person and Account object types, we can implement a single object type (Access) to support these. An example of this is shown below (an AccessGroup with multiple members).
Permissions in IGDM are normally fixed values supplied by a target system. Thus, they would be sent from a target system to the identity management/governance tool, but not pushed back down. The permissions may be single values in a set, or more complex with values specified. The following two examples show this.
The previous examples have shown objects shipped between target systems and identity management/governance tools, and the events may represent search results (such as in a reconciliation) or add/modify/delete operations (i.e. provisioning). However, there is often a need to ship relationships, such as the change to a group membership, in IGDM.
This can be done in the Mapping object type. An example of this, showing an “AssgnmentAndPermit” change, is below.
Thus, we can implement all the IGDM constructs in a SCIM-like implementation leveraging the SCIM mechanisms but adding a pluggable variable structure to support the variations in IGDM data object schemas.
Conclusion
The Identity Governance Data Model (IGDM) describes a rich data model for the passage of identity governance data between identity management/governance tools and target systems with access repositories in an IGA environment.
Legacy identity management models and standards, like DSML and SPML, are data rich, but heavy implementations that have not been widely adopted. SCIM is very popular for lightweight cloud-based implementations but would need significant extension to support a rich model like IGDM.
In this article we have described a SCIM-like implementation to support the IGDM and variability needed to support different implementations of IGDM object types, like ADAccount objects and RACFAccount objects. It also provided sample implementations showing how the fixed and variable components could be used.
This is the last article in the series on the Identity Governance Data Model (IGDM). Is it real? Not yet, but hopefully one day it will.
