System for Cross-domain Identity Management (SCIM) is a standard for automating the exchange of user identity information between identity domains, or IT systems. SCIM can be used with SAS Viya to push identity information into the Identities microservice, rather than pulling identity information from an LDAP provider. When using SCIM the Identities microservice is the SCIM server and the Identity Provider is the SCIM client. In this article we will examine the requirements for using SCIM and some considerations for the use of SCIM. In future posts we will examine in detail the configuration of both the SAS Viya environment and the Identity Provider.
Both the latest release of SAS Viya 3.5 and SAS Viya 2020.1 (and later) support the use of SCIM. Specifically, SAS Viya only supports SCIM version 2. SCIM 2.0 is not backward compatible with SCIM 1.1 or the depreciated SCIM 1.0.
SAS Viya currently only supports Azure Active Directory or OKTA as SCIM clients. Obviously, Azure Active Directory is a cloud-based Identity Provider. OKTA is also a cloud-based Identity Provider. However, while OKTA does provide an on-premise provisioning agent this agent only supports SCIM 1.1 and so is not supported by SAS Viya.
LDAP and SCIM cannot be used together in a single SAS Viya environment. LDAP must be disabled to use SCIM. Since LDAP is disabled SAS Logon Manager will no-longer be able to authenticate a username & password connection. So SAML or OpenID Connect must be configured for SAS Logon Manager if using SCIM.
Kerberos authentication does not make sense with SCIM. For Kerberos authentication you require a KDC and in most situations the KDC will run alongside an LDAP server. The Kerberos User Principal Name must match the username within the Identities microservice. As such, when using Kerberos authentication, it only makes sense to use LDAP as an Identity Provider.
There is nothing within the SAS Viya configuration that prevents using multiple SCIM clients with a single SAS Viya environment. However, there is equally nothing that will prevent, one SCIM client overwriting a user or group created with another SCIM client. As such, the use of multiple SCIM clients should be considered carefully and alternative mechanisms employed to prevent clashes.
First and foremost, the Identities microservice is the SCIM server. This means that the SCIM clients (either Azure Active Directory or OKTA) must be able to connect to the SCIM server. Let’s examine this requirement in more detail. This means that:
Next the SCIM client must authenticate to the SCIM server. The Identities microservice supports authentication using an OAuth 2.0 Bearer token. This means the SCIM client must be registered with SAS Logon Manager and a long lifetime token generated with the client credentials. The token must have a long lifetime to avoid having to update the SCIM client configuration often.
The SCIM client must be authorized to access the SCIM endpoints of the Identities microservice. An authorization rule must be created to allow the SCIM client to access /identities/scim/v2/**. We will provide more details of authentication and authorization later.
The standard SCIM core schema defined by RFC 7643 does not include UID and GID information. Therefore, SAS Viya must leverage some other process to be able to run processes as end-users. This will be different between SAS Viya 2020.1 (and later) and SAS Viya 3.5, which we will address next.
SAS Viya 2020.1 (and later) does not assume a tight integration between operating system and end-users. In the default configuration the Identities microservice will generate UID/GID information for end-users, when such information is not returned from an LDAP Provider. This UID/GID information is then used by the SAS Compute Server, SAS Connect Spawner, and possibly the SAS Cloud Analytic Services controller to launch end-user processes.
The Identities microservice generates the UID/GID information by hashing the unique identifiers for users and groups. This SHA-256 has is then mapped onto a numerical space to generate the UID/GID. Since the hash is mapped onto a smaller numerical space it is possible, although rare, to get collisions. The documentation contains instructions for dealing with collisions.
For an individual end-user the UID and GID will be the same value when the Identities microservice generates them . The UID/GID values will also be the same across multiple environments such as DEV, TEST, and PROD. Also, these are only generated when requested and will not be known beforehand. This can introduce complexity for attempting to provide operating system level permissions to shared storage.
Username & password connections to SAS Viya 2020.1 (and later) are not supported when using SCIM. This will impact both the SAS Viya CLI and direct connections to SAS Cloud Analytic Services. The SAS Viya 2020.1 (and later) CLI supports authenticating with an authorization code; which enables the end-user to authenticate with SAS Logon Manager in a browser to obtain an authorization code for the SAS Viya CLI.
Equivalently, direct connections to SAS Cloud Analytic Services support authentication with an ID Token obtained from SAS Logon Manager. This ID Token will need to be obtained separately. For example, Jupyter Hub could be integrated with SAS Logon Manager, and the ID Token obtained when authenticating leveraged for the direct connection to CAS, as discussed in this article.
Finally, shared accounts for CAS and SAS Compute Server, or SAS Compute Server service accounts will not work in SAS Viya 2020.1 (and later) configured for SCIM.
SAS Viya 3.5 assumes a much tighter integration between the operating system and the end-users. For example, by default launching a SAS Compute Server session assumes that the username from the internal OAuth token is known to the operating system. Translating and mapping the SCIM end-users into valid operating system end-users makes leveraging SCIM with SAS Viya 3.5 much more complex.
For mainly reporting environments only leveraging SAS Visual Analytic and SAS Cloud Analytic Services this won’t be such an issue, since there is no requirement to run processes as end-users. But environment leveraging SAS Studio 5.2 Enterprise or other solutions using the SAS Compute Server will be problematic.
Equally direct connections to SAS Cloud Analytic Services or the SAS Viya CLI will be problematic since the username & password will not be valid with SAS Logon Manager. As with SAS Viya 2020.1 (and later) both the SAS Viya CLI and CAS can leverage separate authentication in a browser with SAS Logon Manager, to obtain either an authorization code or ID Token. Only the latest version of the SAS Viya CLI supports authentication with the authorization code, so this might need to be updated.
So, in this article we have looked at what is involved in configuring SCIM with SAS Viya. We have addressed the requirements and some of the considerations for using SCIM. In the next post we will examine the SAS Viya configuration in detail. Then in future posts we will explore the configuration of the SCIM clients, either Azure Active Directory or OKTA.
Registration is open! SAS is returning to Vegas for an AI and analytics experience like no other! Whether you're an executive, manager, end user or SAS partner, SAS Innovate is designed for everyone on your team. Register for just $495 by 12/31/2023.
If you are interested in speaking, there is still time to submit a session idea. More details are posted on the website.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.