Identity Lifecycle Management (ILM), is a crucial component of enterprise Identity and Access Management (IAM) architecture, it also sometimes referred to as joiner-mover-leaver process. The goal of ILM is to minimize security risks by avoiding over-provisioning and under-provisioning of access rights. This is more important for companies that heavily depend on third party (3p) SaaS applications and allows personal devices (concept known as bring your own devices or BYOD) to access them. If provisioning access takes too long, the productivity of the employee is impacted, and if deprovisioning of access also takes too long, damage beyond repair can be done by the same employee knowingly or not. This article explains why Single Sign On (SSO) cannot solve all of it, and provides details about a companion, System for Cross-domain Identity Management (SCIM) to complete the picture.
Identity Lifecycle Management
To build a robust ILM system, various departments within the company work together, starting with Human Resources (HR). Onboarding of an employee starts with HR, then supported by the Information Security team until the employee's termination via a set of tools and procedures. Companies, irrespective of size, establish processes to hire, manage internal transfers and terminate employees. These vary from one to another based on size, from entirely manual and ticketing steps to automated workflows. At smaller to medium sized companies, processes involve direct interaction between teams, one informs another about a new hire, requests hardware and network credentials, and similarly notifies when an account should be removed upon termination. Larger companies with dedicated technology teams, ILM process is typically semi or fully automated. They are often supported by HR IT onboarding systems that create accounts, trigger notifications for hardware and credential creation, and support termination, access revocation through similar systems.
Single Sign On
We enforce Single Sign On (SSO), it will take care of automating access to applications, correct? Wrong. SSO is an important piece of the IAM ecosystem, but it alone does not automate access management. It is much evident during employee offboarding without a stronger ILM process to complement SSO. Many that work in technology, particularly those that are not familiar with all the ins and outs of IAM processes, assume that SSO automatically handles access revocation when an employee leaves. However, the effectiveness of SSO in this context depends on several factors. Companies with strict SSO policies prohibiting access to applications from non-employer-managed devices and can immediately disable access upon employment termination may have better control. If the company allows BYOD, revoking access becomes more challenging without an automated mechanism. In cases where SaaS applications create their own user sessions and do not frequently verify the state with an SSO provider (through OAuth refresh tokens for example), will continue to honor the session. Some third-party SaaS applications also offer SSO bypass ability, allowing users to log in with application-specific credentials, circumventing SSO-based controls.
Welcome to SCIM
For comprehensive access management, especially in environments supporting BYOD model, automated access revocation processes are critical. SCIM, or System for Cross-domain Identity Management, is a standard designed to manage user identity information across multiple domains and applications, cloud or otherwise. SCIM's design and development are guided by several RFCs, including 7643, 7644, and 7642. SCIM 2.0, the latest version of the protocol supports more attributes, operations and strict security requirements such as mandatory TLS 1.2.
SCIM automates the process of approving and revoking user accounts in applications that support the protocol no matter where they are deployed. By using standardized protocols like REST and data formats such as JSON, SCIM enables seamless and secure communication of identity data between both identity (IdP) and service providers (SP). This reduces the burden on IT departments, minimizes human errors, and enhances security by ensuring that access is promptly updated or revoked as needed.
Getting into technical details, SCIM supports two important endpoints: /users and /groups. Users endpoint is used for managing users and attributes such as email via various operations (create, patch, delete, etc.,). Groups allow membership updates which can be used for authorization policies on the SP. Customers can create integration to these endpoints with their entitlement management systems (e.g., an IdP managed group membership) and sync the changes automatically. This not only helps with deprovisioning of users when they leave but also helps with internal role changes. Most of the Identity as a Service (IDaaS) solutions available on the market support SSO and SCIM as part of the same application setup process making it easy to implement.
Conclusion
Per one of the well-known IDaaS with largest collection of SaaS integrations that I am aware of, less than 25% of the apps that support SSO via SAML and OIDC also support SCIM. I would like to conclude this article with requests to SPs and enterprise IAM teams to increase SCIM adoption. SPs should go beyond SSO and must consider supporting SCIM as part of their product (free of charge!) for their customers. IAM teams must enable SCIM for existing SPs if supported and push the remaining to support.
Opinions expressed in this article are solely the Author's own and do not express the views or opinions of the Author's employer.