Petya Petrova - Fotolia
Users typically access resources within their home environment based on their own credentials, but there are times when enterprise users require access to resources hosted within another unrelated environment, such as a partner organization or a hosted model. This is where System for Cross-Identity Management comes into play.
SCIM is an open standard based on RFC 7644 that can automate cross-domain user account provisioning. It addresses a niche identity management requirement where user accounts from one enterprise must be available within another domain.
SCIM vs. SAML, OIDC
As Security Assertion Markup Language (SAML) and Open ID Connect (OIDC) become more prevalent for enabling single sign-on, admins may wonder why they should use SCIM. First, it's important to look at the differences between SAML/OIDC and SCIM.
SAML enables authentication via SSO based on user credentials housed in the home enterprise system. SAML works well for SaaS applications with browser-based access. For example, if users are accessing a SaaS-based human resource information system (HRIS), they can use enterprise login credentials for authentication. With SAML, the user login is redirected to the enterprise system in real time to confirm validity.
Similarly, OIDC addresses user authentication. It's likely to be a major product moving forward because it's easier to implement. The format for OIDC is JSON, whereas SAML is based on XML.
SAML/OIDC is the means of authentication, including SSO. But what about use cases in which users from one domain must access resources in another unrelated domain? That's where admins can use SCIM to provision, modify and deprovision user accounts, as well as related attributes, from one domain and automatically populate within another domain. Admins can also use SCIM within an organization to automatically populate user IDs for non-domain-based repositories, such as an authentication database. The key word here is automatically.
An admin's first reaction may be that there's no way that he or she would transfer user identity data to another party, but identity management and identity integration providers are doing this every day to address enterprise needs based on SCIM 2.0 standards. SCIM is much more secure than manually creating and maintaining external user accounts. For example, identity integration vendors such as Aquera boast customers in the security-conscious healthcare and banking industries that use their cloud services to put SCIM facades on apps lacking SCIM support.
Azure AD provides functionality for provisioning user identities from one enterprise to another, but it may not be feasible. In addition to many organizations not fully embracing Azure AD yet, they may expressly prohibit any type of external access to Azure AD.
Using SCIM with Citrix FAS
Let's look at a potential use case for SCIM focused on Citrix Federated Authentication Service (FAS) shadow accounts. SAML authentication for Citrix Cloud has just reached the private tech preview milestone. The scenario presented here has not been thoroughly vetted yet and is discussed here as a potential option.
Shadow accounts are required to enable users from one company to access resources within an unrelated Citrix environment. A shadow account is a second user account that is created within the partner domain. For example, an admin would need to create a user account firstname.lastname@example.org within the domain of company.com for Terry to use FAS. This process is called directory synchronization, or DirSync. It sounds easy, but manually creating, modifying and deleting shadow accounts is a maintenance nightmare.
Here's where SCIM may make sense. Using SCIM technology, the account email@example.com and specifically selected user attributes, such as group membership, could be populated within company.com. Partner.com maintains control as to exactly which data is passed to company.com, and there is no need to transfer user passwords because FAS generates a virtual smart card to serve as the password for users.
As a result, new user shadow accounts are created, group membership and associated permissions are updated when the user takes on a new role, and user accounts are deleted when the employee leaves -- automatically -- thus removing manual effort and potential security risks. SCIM updates are performed near real time, so if Terry is promoted to a managerial role that enables access to additional applications based on group membership, the shadow account within company.com would likewise be updated shortly thereafter.