Continuing my theme of exploring IGA topics and “the Cloud”, I thought it worthwhile looking at SCIM and its adoption since it appeared eight years ago.
The System for Cross-domain Identity Management, or SCIM, is the current rockstar of Identity Governance and Administration (IGA). It’s a lightweight data model utilizing JSON and REST that seems to solve all the SaaS identity management scenarios. But how pervasive is it and does it address all IGA data needs? In this article we will look at SCIM, it’s pervasiveness and how it addresses different IGA use cases.
What Is SCIM?
SCIM (http://www.simplecloud.info) started life as Simple (or Simplified) Cloud Identity Management and was later renamed to the System for Cross-domain Identity Management. Various attempts over the years have tried to provide a universal identity management data model and interchange mechanism. We have seen the Directory Services Markup Language (DSML) and the Service Provisioning Markup Language (SPML). Both failed to take hold in the market, mainly due to the complexity and bloated implementation. The market needed a simple and lightweight model.
SCIM leverages both JavaScript Object Notation (JSON) and Representational State Transfer (REST) – two common cloud-friendly protocols leveraging HTTP. It provides an extensible data model with the core data objects being User (person + account) and Group (groups of users). This is shown in the following figure from the SCIM website.
Like we saw with LDAP with inetOrgPerson and group/groupOfNames, the SCIM User and Group objects are generic representations.
The User object is a generic representation of a person, with attributes such as name, userName, phoneNumbers and emails. The example from the SCIM website shows a sample User object.
The Group object is just a collection of members. The example from the SCIM website shows a sample Group object.
The SCIM User and Group objects are suitable for systems that implement simple access models – basic user (or accounts) and access via groups with groups representing a collection of users. This includes many of the current SaaS applications that only need that level of access control.
But this doesn’t address the need for complex account types or access models (think Microsoft Active Directory or IBM z/OS RACF, and even some SaaS applications). There has also been a draft SCIM Password Management Extension (https://tools.ietf.org/id/draft-hunt-scim-password-mgmt-00.txt).
SCIM is designed to be extensible; other types of resources can be added. As this is data passed between two components (e.g. between an IGA system and a target system), any changes to the standard objects or addition of new resource types requires the modification of the endpoints at either end (different REST URLs, generation/consumption of the data).
SCIM is leveraged by many IGA/IAM solutions, many extending the standard for their own use.
How Pervasive is SCIM?
Whilst use of SCIM for on-premise systems is very limited, it is significant and growing in SaaS, such as G Suite, Microsoft Office365 and salesforce.com.
Analysis of the connectors for Microsoft Azure Active Directory (https://docs.microsoft.com/en-au/azure/active-directory/saas-apps/tutorial-list) shows that about 2/3 (~40/60) use either standard SCIM (v1 or v2) or a variation of SCIM. Of the remaining a small number (~5) implement their own REST-based API and others (~15) have their own APIs (may be Web Services based). Many of the non-SCIM APIs are addressing more than just Users and Groups.
Of the SCIM implementations, most will manage Users and Groups. Some will only manage Users (a constraint of the target systems) and some will manage more than just Users and Groups.
So, whilst the use of SCIM is not universal, it can be considered pervasive in the cloud.
Can SCIM Address all IGA Integration Needs?
As discussed above, the standard SCIM resources are User and Group. The User resource represents a generic user object, similar to what inetOrgPerson does in LDAP. The Group resource is a collection of users, similar to group or groupOfNames in LDAP. If the target system (such as an on-prem system or SaaS system) only needs a simple user representation or user groups to manage access, then SCIM is the perfect fit.
But it will not meet all IGA needs, including the need for access data other than group membership, the need for complex account types, or where the target system does not expose a SCIM interface.
First, the standard access model implemented by many systems consists of; users (accounts), users mapped to groups, and groups mapped to permissions/rights/resources. This provides a simple delineation of management – the system owners/administrators can manage the group to permissions/rights/resources (i.e. the fine-grained access for the system) and security admins or help desk can manage the user accounts and group memberships. But this is not the model used by many systems; some systems allow users to be connected directly to permissions/rights/resources or have multiple layers of access (e.g. groups and roles). For identity management you may need to manage these relationships. From a governance perspective, just having visibility into accounts and group memberships may not give a complete view of a users’ access, particularly when group naming/descriptions have no real bearing on the access they provide.
In this scenario SCIM needs to be extended to provide custom resource types, both data objects (e.g. permissions) and memberships. Extending SCIM includes extending the schemas as well as the endpoints on both ends.
Next, the standard User resource does not support the account complexity required of many systems. For example, Microsoft Active Directory and IBM z/OS RACF accounts have dozens of unique attributes. For example, the IBM AD Identity adapter has around 200 attributes managed on AD accounts (including Lync and Exchange attributes) and the IBM z/OS RACF Identity adapter has over 120 attributes across multiple segments.
You could extend the common SCIM User schema and add on the extra attributes needed for each target system, but that doesn’t scale and could be incredibly cumbersome. Or you could implement a unique account resource type for each different account type, and then implement REST endpoints and the code supporting them for each. For example, looking at AD and RACF you would need https://example.com/{v}/ADAccount and https://exmaple.com/{v}/RACFAccount endpoints for all the Create/Read/Replace/Delete/Update/Search/Bulk operations, and the underlying code to process each.
Finally, many systems just do not implement a SCIM interface. If you were to implement SCIM universally for all your systems, you would need to build some form of adapter layer to interface SCIM with the target system. This may be an unnecessary additional transformation layer (adding another point of potential failure between the IGA system and the target, not to mention additional unnecessary processing).
Conclusion
Whilst SCIM implements its original mantra of lightweight and simple, that comes at a cost. It is getting increased adoption across SaaS applications (2/3 of those managed by Microsoft Azure AD) where these applications need only simple users or users and groups.
However, there are situations where standard SCIM does not cut it; the need for complex access models, the need for complex accounts, and where systems do not provide a SCIM interface. In these cases, SCIM would need to be extended through custom resource definitions and custom endpoints.
SCIM is reasonably well suited to most SaaS applications. It may be that the industry moves to more standard access models. However, it’s unlikely that all legacy on-prem systems will be simplified enough to use standard SCIM or expose SCIM interfaces.
This article originally appeared on 5 Aug 2019 on LinkedIn; https://www.linkedin.com/pulse/scim-solve-all-your-iga-problems-right-david-edwards-iamdavid-/
