This article is the second in a series of three looking at a proposed common Identity Governance Data Model (IGDM). This second article validates the model against some common complex applications.
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 validate the data model against the access models used by many enterprise applications. A later article will suggest an implementation.
Introduction
The previous article in this thread presented 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 was developed by analyzing the access models used by many enterprise applications, such as IBM Security Access Manager (ISAM), IBM z/OS RACF, Microsoft Active Directory (AD) with Office365 and Sharepoint, Microsoft SQL Server, Oracle Database, SAP, Amazon Web Services (AWS) and salesforce.com. This represents a mix of on-premise and cloud enterprise applications with complex access models.
This article will present how some of these enterprise application access models fit into the proposed IGDM as a form of validation of the data model.
Validating the IGDM
We will explore the access model or a range of enterprise applications to show how they can fit in the IGDM. The applications explored are; IBM Security Access Manager (ISAM), z/OS RACF, SAP and Amazon Web Services (AWS).
ISAM and the IGDM
The IBM Security Access Manager (ISAM) access model can be summarized as follows:
- ISAM Users are accounts, and there are groups of account
- ISAM uses Access Control Lists (ACLs) to map users and/or groups to sets of resources with associated access levels. For example, Group PowerUsers may access the Accounting branch of the web objectspace (and objects under it) with Read and Traverse permission
- ISAM secures Protected Objects, like web pages or branches of the web page structure
- ISAM has an extensive set of access levels and supports the creation of custom ones
- ISAM has Protected Object Policies for time-of-day and other restrictions on access
- ISAM has Access Rules stored as XSL blob and evaluated at run time
The ISAM access model will map to the following (highlighted in orange) objects and relationships in the IGDM.
The IGDM objects and their mapping to ISAM access model objects is shown in the following table (IdM = IGDM).
The ISAM access model fits nicely in the IGDM.
z/OS RACF and the IGDM
The z/OS Resource Access Control Facility (RACF) is one of the Enterprise Security Managers (ESMs) used on z/OS mainframes. It provides a very rich but complex access model – there are over fifty rules evaluated when determining whether and how a user can access a resource.
Whilst this is nowhere near a complete representation of RACF, the following constructs are common in RACF environments:
- RACF User Profiles are accounts, user objects have default access (tied to attributes) and user profiles can have multiple user segments (attribute sets)
- RACF Group Profiles group users, can be in a hierarchy for administration and can have default access associated with a group
- RACF defines Resource Profiles; Datasets and other Resources. Resources can have default access.
- Users are assigned to Groups (via the Connect command) and there may be some default permissions on the connection
- Access is granted via Resource Access Lists (defined via the Permit command) and can have standard or conditional access lists (conditional has scoping, e.g. can only be run via a specified program)
- Resources can be defined in access lists as discrete or generic (i.e. with wildcarding)
- Permission list will include access authority (e.g. NONE, READ, UPDATE etc.). They could also include a set of conditional/WHEN clauses
This is a simple, but representative, view of the RACF constructs.
The RACF access model will map to the following (highlighted in orange) objects and relationships in the IGDM.
The IGDM objects and their mapping to RACF access model objects is shown in the following table (IdM = IGDM).
At this level of detail, the RACF access model fits with the IGDM. There may be more esoteric RACF constructs that don’t fit the model, but this will address many customer deployments of RACF.
SAP and the IGDM
SAP represents a suite of products that been developed or acquired by SAP SE over the last thirty years. However, when we talk about SAP, we are normally referring to the core SAP modules that share the common ABAP/Netweaver framework.
The SAP access model can be summarized as follows:
- SAP accounts are called Users, and have a user name and other attributes
- Users are mapped to Roles or Profiles. The Roles can be composite or single, the profiles can be composite or manual. Composite roles contain single roles and a single role may be in multiple composite roles. Composite profiles contain manual profiles and a manual
- Profile may be in multiple composite profiles.
- Roles and Profiles contain Authorizations, which may be transactions codes (T-CODES) or other Authorization objects. These can contain multiple fields/values to further restrict access. For example, a user may be able to run transaction ABCD but only for company 124 and in read-only mode. Thus, a role/profile may represent a complex set of access objects.
- Groups in SAP are used for bulk administration and are not tied to access.
The SAP access model will map to the following (highlighted in orange) objects and relationships in the IGDM.
The IGDM objects and their mapping to SAP access model objects is shown in the following table (IdM = IGDM).
The complexity of SAP Authorizations can be handled in the Resource + Resource Policy objects, with the Permission object handling the allowable fields and values. The rest is simple Account – Access Role – Resource mapping.
AWS and the IGDM
Amazon Web Services (AWS) can use its own accounts and access object and can also leverage external services like LDAP. The term “Account” in AWS refers to an account with AWS – it may represent an individual but will normally refer to a company who has an account to run services in AWS and is not directly related to the access model.
The AWS access model can be summarized as follows:
- An AWS user account is called a User, which includes login credentials, and there can be groups of users
- User Permissions, via attached policies control ability to perform tasks using AWS Resources
- AWS Roles are a special item. Roles are used for applications to interact with services or for delegated remote access (e.g. via federation), not user-based management. They are collections of permissions, but are not associated directly with users or groups
- IAM policies grant/deny permission to one or more Amazon EC2 actions, and the polices are mapped to one or more users or groups
- AWS also has resource-based policies
- AWS can also use Access Control Lists (ACLs) – mapping of multiple identities to resource access at different levels
A sample AWS IAM policy is shown below.
The AWS access model will map to the following (highlighted in orange) objects and relationships in the IGDM.
The IGDM objects and their mapping to AWS access model objects is shown in the following table (IdM = IGDM).
Excluding the objects not directly related to users, the AWS access model fits in the IGDM.
This concludes the validation of the IGDM by looking at the access models of various enterprise systems.
Conclusion
The Identity Governance Data Model (IGDM) was defined by analyzing the access models of various enterprise applications such as IBM Security Access Manager (ISAM), IBM z/OS RACF, Microsoft Active Directory (AD) with Office365 and Sharepoint, Microsoft SQL Server, Oracle Database, SAP, Amazon Web Services (AWS) and salesforce.com. This represents a mix of on-premise and cloud enterprise applications with complex access models.
In this article we have described the access models of ISAM, z/OS RACF, SAP and AWS and how they map into the proposed IGDM, to show how the IGDM can represent different target system access models.
The next article in the thread will look at how the IGDM could be implemented in a SCIM-like mechanism.
One thought on “IGDM Part 2 – Validating the Proposed Identity Governance Data Model”