SAS Viya with Azure AD OID

1 Like

Yes, that title is correct – I didn’t miss the "C" for OpenID Connect from the title. In this blog I want to look at using the Azure AD objectID or OID for both authentication with OpenID Connect and SCIM provisioning of identity information. First, we will discuss why you might want to consider using the Azure AD objectID and some of the considerations for the different SAS Viya versions. Then we will look at what you’d need to setup for both authentication and identity information to use the Azure AD objectID.

Microsoft’s documentation on ID Tokens with OpenID Connect specifically has a section on "Using claims to reliably identify a user" which has the following:

When identifying a user (say, looking them up in a database, or deciding what permissions they have), it's critical to use information that will remain constant and unique across time. Legacy applications sometimes use fields like the email address, a phone number, or the UPN (User Principal Name). All of these can change over time, and can also be reused over time. For example, when an employee changes their name, or an employee is given an email address that matches that of a previous, no longer present employee. Therefore, it is critical that your application not use human-readable data to identify a user - human readable generally means someone will read it, and want to change it. Instead, use the claims provided by the OIDC standard, or the extension claims provided by Microsoft - the sub and oid claims.

The same section also notes:

The sub claim in the Microsoft identity platform is "pair-wise" - it is unique based on a combination of the token recipient, tenant, and user. Therefore, two apps that request ID tokens for a given user will receive different sub claims, but the same oid claims for that user.

The definitions of the sub and oid claims are:

sub - The principal about which the token asserts information, such as the user of an app. This value is immutable and cannot be reassigned or reused. The subject is a pairwise identifier - it is unique to a particular application ID. If a single user signs into two different apps using two different client IDs, those apps will receive two different values for the subject claim. This may or may not be wanted depending on your architecture and privacy requirements.
oid - The immutable identifier for an object in the Microsoft identity system, in this case, a user account. This ID uniquely identifies the user across applications - two different applications signing in the same user will receive the same value in the oid claim. The Microsoft Graph will return this ID as the id property for a given user account. Because the oid allows multiple apps to correlate users, the profile scope is required to receive this claim. Note that if a single user exists in multiple tenants, the user will contain a different object ID in each tenant - they're considered different accounts, even though the user logs into each account with the same credentials. The oid claim is a GUID and cannot be reused.

So, we can see from Microsoft’s own documentation that we should really be using the oid or objectID to identify end-users. We should not be using email, preferred_username, or upn since these are values that could be changed. For example, if an end-user changes their name then their email, preferred_username, and upn would all change to reflect their new name. Also, oid will be consistent for multiple applications in the same Azure AD tenant; allowing for Viya 2020.1 (and later) to cache and re-use the ID Token. The oid, or objectId, for a user in Azure AD will look like "eb212b2a-aaae-4f4a-9de8-1b1b8ea78bab".

The use of the oid is also important if guest users will be present in the Azure AD tenant. Guest users are end-users from other Azure AD tenants that are "invited" to access applications in the current Azure AD tenant. For example, a SAS customer using their own Azure AD tenant might "invite" SAS Consultants or Partners to access their SAS Viya environment to undertake a consulting engagement. Without leveraging the oid a consistent representation of the guest users cannot be guaranteed. In some cases, we have seen guest users without an email attribute or mixed case issues with the upn and preferred_username attributes. No such issues are present when using the oid.

So far, we have considered OpenID Connect and the attribute selection from the ID Token. But, remember the SAS Viya username attribute, that we will map to oid, must match the value held in the Identities microservice. For SCIM push we can configure Azure AD to send the objectId property as the username to SAS Viya. This will ensure the values for username in the Identities microservice will match the value returned by SAS Logon Manager from processing the ID Token.

Finally, what about groups? As with any object in Azure AD the groups contained there have an objectId. However, when we use SCIM to push group information to SAS Viya we only use the displayName and members attributes of the group in Azure AD. Therefore, it does not make sense to use the objectId for groups. It would make it very difficult for administrators to manage permissions if the group names in SAS Viya looked like "bffaa736-20d8-4e73-9f0f-3cd3d160d476" instead of "SAS Viya Users".

Consideration for using oid

Using oid, or objectId, for authentication and identity with SAS Viya does require some consideration being given to how that value is used within SAS Viya. SAS Viya will leverage that value as the username for the end-user. When the end-user is logged into applications, they will still see their display name. When SAS administrators look at users and groups, define permissions, and otherwise use the SAS Viya visual applications they will also see the display name rather than the username.

However, in some cases the username does become important. Mainly when running processes as the end-user. For example, a SAS Compute Server process will run as the objectId. With SAS Viya 3.5 this means that the objectId must be recognized by the underlying operating system. So, the Name Server Switch (NSS) must be able to translate the objectId into a Linux UID.

This is not such a concern with SAS Viya 2020.1 (and later) since the Identities microservice will automatically generate a UID for the objectId. The same considerations will apply for SAS Cloud Analytic Services if sessions are configured to run as the end-user. This will not be a concern with SAS Viya 3.5 if the processes are run using a service account.

Also, for both SAS Compute Server and SAS Cloud Analytic Services using the objectId can make reviewing the logs more complex. The objectId will be used in the logging messages. If you expect to monitor the CAS logs to see what users are doing you will need to be aware that instead of a human readable name you will now see the objectId.

Authentication Configuration

The configuration for OpenID Connect to leverage the oid as the username will require some slight changes on both the SAS Viya side and Azure Active Directory side. From Microsoft’s documentation the oid property is only available from the profile claim.

In SAS Viya under the sas.logon.oauth.providers settings we need the following:

The property attributeMappings.user_name set to oid
The property scopes set to the string openid,profile

The other configuration properties can be configured as normal for OpenID Connect with Azure AD. The standard configuration properties settings are covered in the documentation; SAS Viya 3.5 is covered here and for SAS Viya 2020.1 (and later) this is covered here.

Within Azure Active Directory the enterprise application registration for OpenID Connect authentication with SAS Viya will require additional API permissions. We require that SAS Viya has access to the user’s profile to be able to access the oid property. This permission can be defined on the API permissions pane within the Microsoft Azure Portal for the enterprise application. You would complete the following:

Select Add a permission
Select Microsoft Graph
Select Delegated permissions
Expand OpenId permissions
Select the checkbox against profile
Select Add permission

This should look something like the following:

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

These settings for both Azure Active Directory and SAS Viya will enable OpenID Connect authentication using the oid.

Identity Configuration

The other half of the configuration deals with the Identity information. Since we are using SCIM to push the identity information from Azure AD into SAS Viya there will be nothing to change on the SAS Viya side. The standard SCIM configuration for SAS Viya remains the same as we have discussed before. The only change will be in the attribute mapping within the enterprise application definition in Azure Active Directory.

Specifically, for the Provision Azure Active Directory Users settings for Attribute Mappings we need to set the source attribute to objectId for the target attribute userName. Within the Microsoft Azure Portal this would look like the following:

The other configuration for Azure AD SCIM would be the same as normal, which we have discussed before.

With this complete the users will now be pushed to SAS Viya using the objectId attribute as their unique identifier. For example, a sample user viewed in SAS Environment Manager would now look like the following:

Conclusion

In this blog we have presented some arguments for why you might consider using the oid or objectId as the unique identifier for your end-users when using OpenID Connect and SCIM with Azure Active Directory. We have highlighted some concerns with such an option and running processes as end-users in SAS Viya 3.5. Equally, we have shown that those concerns do not occur with SAS Viya 2020.1 (and later). Finally, we have detailed the configuration for both authentication and identity that is required to use oid or objectId.

Find more articles from SAS Global Enablement and Learning here.