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.
What is Supported?
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.
SCIM Requirements
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:
- You must have an external DNS name that can be resolved on the public internet that points to the SAS Viya environment. The SCIM client must be able to resolve this DNS name and the SCIM clients are not part of your own network.
- The SCIM client will only connect over a secure connection. This means that HTTPS must be used for the connection to the Identities microservice. The external SCIM client must be able to trust the certificate presented by the SCIM server. This means the certificate must be purchased from a specific list of commercial Certificate Authorities. For Azure Active Directory the supported Certificate Authorities are listed here.
- The SCIM client must be able to connect to the Identities microservice, which will require firewall rules to allow access into the SAS Viya environment. Both Azure Active Directory and OKTA run across a wide number of different IP addresses. You can obtain the list of Azure Active Directory IP addresses as well as the OKTA IP addresses.
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.
SCIM Considerations for SAS Viya 2020.1 (and later)
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.
SCIM Considerations for SAS Viya 3.5
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.
Conclusion
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.
