This article is the first in a series of three looking at a proposed common Identity Governance Data Model (IGDM). This first article proposes the model.
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 describe the proposed data model. Subsequent articles will validate the proposed data model against common target systems and suggest an implementation.
Introduction
Identity Management (the management of user accounts and access) is a mature domain within Identity and Access Management (IAM) having developed over the past twenty years. It covers the standard CRUD operations (create, read, update, delete) for managing target system accounts and access rights.
More recently this has expanded to include governance scenarios, such as access recertification, risk management, role mining and fine-grained permission analysis and reporting. In parallel, the scope of what’s now known as IGA (Identity Governance and Analytics) has grown from the traditional IT-focused on-prem systems to hybrid-cloud and multi-cloud patterns with cloud and on-prem target systems (and access repositories) managed by one or more identity management/governance tools.
As the IGA landscape has grown, so has the need for a common data format for the interchange of IGA data.
Over the years many data standards and transmission protocols have developed, such as LDAP Data Interchange Format (LDIF), Directory Services Markup Language (DSML) and Service Provisioning Markup Language (SPML). These have enjoyed varying degrees of adoption, but none became universal.
The System for Cross-Domain Identity Management (SCIM, aka Simplified Cloud Identity Management) is currently popular. It is a very lightweight implementation which is great for cloud deployment patterns, however the data model, as with many before it, does not address complex access models. It has the concepts of users (including accounts) and groups.
Many enterprise applications and products used today, such as SAP and IBM z/OS RACF, have a very complex access data model. In addition to users/account and groups, there are often multiple levels of resources, permissions, access rights, ACLs etc.
SCIM has two major limitations when working with complex IGA data needs; the data model is very simple meaning extensions are required, and for each extension for a specific need you need to extend the endpoints that send/receive the data. For example, SCIM only supports users and groups. If many different account schemas are needed (e.g. Microsoft AD, SAP, z/OS RACF, salesforce.com, AWS) then custom SCIM user resources are required, and each one will require SCIM endpoints to be coded to support the different SCIM resources.
A final challenge in this ever expanding IGA world is a lack of standard terminology – terms such as user, group and role are overloaded and lead to confusion when working with many systems.
This article proposes an Identity Governance Data Model to address these needs.
The Proposed Identity Governance Data Model
By analyzing the access models of many common enterprise applications, I have been able to come up with a data model that addresses most, if not all, access model needs.
The Proposed Model
The proposed Identity Governance Data Model (IGDM) is shown in the following figure.
The model includes the primary IGA objects of Person, Account and Resource. It also includes other access objects or relationships that may be used by different target systems to control access for the accounts. These will be explored in the following sections.
The idea behind the IGDM is that the one model can be used, but message flows between IGA tools and target systems may only use some of the objects or relationship (as needed by the operation and the target system access repository).
Person and Account Data Objects
The model has person and account data objects:
- Person– the person object with attributes describes a real person, such as an employee, contractor or customer. Person objects are often managed in IGA systems. There may be groupings of Persons to support bulk administration on some systems (the groups are not normally managed by IGA systems).
- Account– the account object represents a set of credentials for a person on a specific target system, including account attributes. Whilst accounts are unique to target systems, account attributes (like userid) may be common across multiple accounts. Some target systems will use attributes as permissions (e.g. z/OS RACF), and some will collect attributes into subsets (like segments in z/OS RACF). Account management is a key component of IGA. There may also be user profiles to define standard or default attributes for types of accounts or users.
These are fairly standard in any IGA implementation but need to be flexible to support different schemas.
Access Data Objects
The model describes different access data objects:
- Access Group– an Access Group is a collection of accounts, possibly with additional attributes associated with the group object (including attribute permissions) and may be in a hierarchy (i.e. groups within groups). Groups will be associated with Access Roles, ACLs or tied directly to Resources.
- Access Role– an Access Role is a collection of permissions, possibly with additional attributes associated with the role object. Access Roles are normally used to assign a common set of permissions to one or more users/groups and applied to resources, and thus can be thought of as the accesses needed for a job role or job function.
- Access Control List– an Access Control List (ACL) is an access construct used by some target systems (such as IBM Security Access Manager, or ISAM) and represents a many-to-many mapping of users/groups to roles/permissions. You could think of Access Groups and Access Roles as limited membership ACLs.
- Access Rules– an Access Rule is some programmatic logic implemented by a target system to evaluate access (e.g. ISAM). The object contains the code/logic and would be understandable by the target system but not necessarily by the IGA tool. However, there may need to be sharing of the access rules for visibility in the IGA tool.
Note the use of “Access” as a prefix for Groups, Roles and Rules in the IGDM. This is deliberate to avoid ambiguity with the use of these objects as compared to “group” and “role” which are overloaded terms.
Resource Data Objects
The model describes the following resource data objects:
- Resource– a resource is a target system object being secured and will be accessed by a user on that system, such as a file or transaction definition. In some target system access models, users (accounts) can be mapped to resources directly (which is considered bad practice in IGA) or via groups (better IGA practice). Some target systems will support wildcarding or generic references in resource definitions (such as z/OS RACF).
- Resource Policies– there may be policies applied to resources, such as time of day restrictions, auditing levels, IP access restrictions (as in ISAM).
- Permissions– a permission may be an access scope or access level. Often target systems will employ a standard, fixed set of permissions (such as NONE, READ, UPDATE… in z/OS RACF) that are applied to a resource definition when assigning to a user/group. For example, John may use the ABCD resource but only at the READ level. There may be allowable values with a specific permission set, and the target system may allow creation of custom permissions (although this is rare as the permissions are often coded into the target system application).
Permissions are often used in conjunction with object relationships (next section).
Relationships in the Data Model
Relationships are used throughout the data model to define mappings between objects. Some of these may be logical, where a relationship is actually held on one of the objects (e.g. an account having a group attribute with a list of access groups). Others are separate objects in their own right, possibly having attributes/permissions directly attached to the relationship model.
From an identity management perspective, change to access may be sent as a change to a relationship even if the target system doesn’t implement the relationship as a separate object. For example, if you have a Microsoft Active Directory (AD) system being managed by an IGA tool, changes to group membership may be sent as an “add the account to this group” message or a “remove this account from this group” message – rather than a complete refresh of the account or data object holding the relationship attribute. Some current identity management systems will send the account object with a group list and may inadvertently wipe un-sync’d changes, or multiple messages from group membership changes may get processed out of order causing some group membership to be incorrectly processed. Sending a single membership change in isolation will solve this problem.
The relationships defined in the data model are shown in the following figure.
Note that there are no explicit relationships defined for Permissions as they are normally attached directly to the other objects and relationships.
This concludes the definition of the proposed Identity Governance Data Model (IGDM).
Conclusion
The Identity Governance Data Model (IGDM) proposed in the body of this article represents an attempt to standardize the structure and definition of Identity Governance and Administration (IGA) data flowing between IGA tools (identity management/governance products) and target system account repositories.
The model provides for some standard definitions and terms to remove the ambiguity that often comes from overloaded IGA terms like group and role.
The model is based on the analysis of many enterprise applications, both on-prem and cloud, and allows for rich access model information to be passed between systems. This prescriptive approach solves the shortcomings of current approaches such as the System for Cross-Domain Identity Management (SCIM) data model.
The next article in this series will validate the data model by applying it to some common enterprise systems. The last article in the series will look at how the model could be implemented in a SCIM-like standard.
