SAS Viya 2024.11 OIDC and SAML Simplify Group Search

1 Like

LDAP searches for group membership information can be resource intensive. This can be made worse when multiple users log in simultaneously. With the SAS Viya 2024.11 Stable Release an alternative has been introduced when you use either OpenID Connect or SAML along with LDAP for the Identities microservice. This alternative allows group membership information to be included in the authentication claims from the Identity Provider, such as Microsoft Entra ID, and processed by SAS Logon Manager during log in.

Why is this important?

Issues with the LDAP searches for group membership information can result in slow log ins for your users. This might not be noticeable when testing with a limited number of users, but as the number of concurrent users increases the extra processing during log in might become unacceptable.

Providing your users with a smooth, simple, and straightforward log in experience will help to increase the adoption of your SAS Viya environment.

Who does this impact?

Obviously, issues with the LDAP searches for group membership information will only impact environments where LDAP is used with the Identities microservice to provide user information. If you are using SCIM provisioning this will not impact your environment.

The new feature introduced with the SAS Viya 2024.11 Stable release only provides an alternative if you are using either OpenID Connect or SAML for authentication to SAS Logon Manager. It does not impact environments using LDAP or Kerberos for authentication to SAS Logon Manager.

For environments using LDAP or Kerberos for authentication to SAS Logon Manager, you might consider altering the group membership search attributes instead. You could review what group membership information is required in the SAS Viya environment. Then adjust the search terms to limit the LDAP group information made available to SAS Viya.

How does it work?

The new feature introduced with the SAS Viya 2024.11 Stable release, relies on the third-party OpenID Connect or SAML Identity Provider including information about group membership in the authentication claims. Then SAS Logon Manager can be configured to interpret the groups claim that your Identity Provider sends. Which means that SAS Logon Manager does not need to fetch the LDAP group information from the Identities microservice.

The Identities microservice will still regularly populate its cache with LDAP group information. The cached information will then still be available to other parts of the SAS Viya environment. For example, to populate screens within SAS Environment Manager.

The new feature just means that the Identities microservice is not generating a possibly large number of LDAP queries for group membership information each time a user logs into SAS Viya.

How do I configure this?

There are two parts to the configuration; you must configure the OpenID Connect or SAML Identity Provider to include the group information, then you configure SAS Viya to use this information. SAS documentation covers the second part; the SAS Viya configuration which involves setting attributeMappings.external_groups and groupMappingMode. These are described in the following sections of the SAS documentation:

The configuration property attributeMappings.external_groups is available under either sas.logon.oauth.providers or sas.logon.saml.providers. It has no default value and is an optional setting. This specifies the attribute claim to use for group membership information. The configuration property groupMappingMode is also optional but has a default value of AS_SCOPES and should only be changed if directed by SAS Technical Support to change it. It is also available under either sas.logon.oauth.providers or sas.logon.saml.providers.

Example Configuration with Microsoft Entra ID using OpenID Connect

Finally, we’ll walk through the complete configuration when using OpenID Connect authentication with Microsoft Entra ID. Our SAS Viya environment is configured with an LDAP provider for the Identities microservice, in this case leveraging Microsoft Entra ID Domain Services.

First, we need to configure the App Registration in Microsoft Entra ID to include the group information in the ID Token provided to SAS Logon Manager. Here we will discuss making the changes to the App Registration using the Azure Portal, you will need to log into the Azure Portal with a user who has sufficient rights to edit details of the App Registration.

On the App Registration page complete the following to include the group information in the ID Token:

Expand Manage
Select Token configuration
Select Add groups claim
The following types of groups can be included in the ID Token:
1. Security groups
2. Directory roles
3. All groups (includes 3 group types: security groups, directory roles, and distribution lists)
4. Groups assigned to the application (recommended for large enterprise companies to avoid exceeding the limit on the number of groups a token can emit)
For the ID, Access, and SAML Tokens you can customize the token properties by type. You should select the option that matches what you have configured in the LDAP configuration for the Identities microservice, most probably sAMAccountName.

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

At this point we should discuss that how you create groups in Microsoft Entra ID impacts the availability of these different fields for the group information. As covered in the Microsoft documentation, sAMAccountName and on-premises GroupSID attributes are available only on group objects synced from Active Directory. Specifically, you must be running Microsoft Entra Connect version 1.2.70 or later. Earlier versions of Microsoft Entra Connect than 1.2.70 will synchronize the group objects from Active Directory, but they won't include the required group name attributes.

In addition, there is another option if you have assigned a group to the application. Remember you need to have a Premium subscription for Microsoft Entra ID to be able to assign a group to an application. With a group assigned to the application you can also use the cloud-only group display names as the text to include in the token.

You can only add cloud-group names of assigned groups to an application. The restriction to groups assigned to the application is because a group name is not unique, and display names can only be emitted for groups explicitly assigned to the application to reduce the security risks. Otherwise, any user could create a group with duplicate name and gain access in the application side.

Currently, in the Azure Portal to assign the cloud-only group display names you need to edit the manifest for the application.

In the portal, select Identity > Applications > App registrations > Select Application > Manifest
Enable group membership claims by changing groupMembershipClaims to ApplicationGroup
Set optional claims for group name configuration in the optionalClaims section of the manifest:
Select Save for the manifest

Another consideration with assigning groups to the application is that the groups you assign will need to match the groups you are providing to SAS Viya through the LDAP configuration for the Identities microservice. Depending on the number of groups in your environment this could prove to be challenging.

Rather that diving straight into configuring SAS Viya to use the additional claim we should validate the contents of the token first. We can follow the steps in this post:

https://s4erka.wordpress.com/2021/03/26/azure-ad-application-to-test-oauth2-0/ to validate the contents of the token. We need to complete the following steps:

Register https://jwt.ms as a Redirect URI for our test application
Allow ID tokens for Implicit and hybrid flows

These can both be set on the Authentication page of our test application in the Azure Portal.

Then we can construct a URL to access our test application based on the following template (should be one line, broke into lines here to readability):

https://login.microsoftonline.com/{{TENANT_ID}}/oauth2/v2.0/authorize
?client_id={{APP_ID}}&nonce=defaultNonce
&redirect_uri=https%3A%2F%2Fjwt.ms
&scope=openid+profile+User.read+offline_access
&response_type=id_token

For example:

https://login.microsoftonline.com/######-53d9-44b7-8e88-#########/oauth2/v2.0/authorize?client_id=########-25db-4891-9a1d-10f2fe######&nonce=defaultNonce&redirect_uri=https%3A%2F%2Fjwt.ms&scope=openid+profile+User.read+offline_access&response_type=id_token

Browsing to this URL and authenticating as one of our users in Microsoft Entra ID will redirect us to JWT.ms with our token:

We can see that in the ID Token generated by Microsoft Entra ID we now have the group membership information in the groups claim. At this point you can remove the steps to allow testing with https://jwt.ms and move onto configuring SAS Viya.

To configure SAS Viya to use the group claim information we need to update the OpenID Connect configuration as per the SAS documentation. From looking at the Microsoft Entra ID token we know the claim is "groups", so we just need to set attributeMappings.external_groups to that same string "groups". In SAS Environment Manager this would look like the following:

Finally, the easiest way to validate the SAS Viya configuration is to authenticate with the SAS Viya CLI and then inspect the Access Token generated by SAS Logon Manager. If we use "auth loginCode" with the SAS Viya CLI we can log in with OpenID Connect. Then when we inspect the Access Token in .sas/credentials.json we will see the group membership information in the authorities claim:

Conveniently for my test environment, these groups are different from the LDAP groups. So, if I look at the gatedemo001 user in SAS Environment Manager where only the LDAP groups are displayed I see:

Clearly, for my test environment SAS Logon Manager must be getting the group membership information from the Microsoft Entra ID token since the Identities microservice with its LDAP configuration does not know about the groups listed in the SAS Logon Manager generated Access Token.

In your SAS Viya environment, you are unlikely to have such a simple way to prove the groups are provided by the OIDC token. You could, however, review the Identities microservice logging information as a user authenticates. You will then see that there are no LDAP queries to fetch the group membership information.

Conclusion

As we have discussed the new feature introduced with the SAS Viya 2024.11 Stable release provides the opportunity to improve the performance of login operations for environments configured with an LDAP provider for Identities and either OpenID Connect or SAML for SAS Logon Manager. Removing the requirement for additional LDAP searches for the group membership information can have a significant impact on the log in times for high concurrency environments.

Stuart Rogers

Find more articles from SAS Global Enablement and Learning here.

rma1 · ‎12-20-2024

Thanks @StuartRogers for this detailed new feature, a much needed addition to the authentication gameplay with Viya !

In the case of SAML Authentication to SAS Logon, a next step would be to have an option to disable the back-end LDAP queries between the Identitities Micro-service and the LDAP Directory server when you choose to pre-populate the user/group informations cache asynchronously using the Viya CLI identities plugins (link) In the modern Enterprise Information Systems, with 12 factor app, API Restful Http instead of connection based protocols and SSO authentication methods replacing direct form based query, it becomes really difficult to justify the need for a direct exposure of LDAP sensitive informations to application interfaces like SAS. Security rules now generaly prohibit synchronous LDAP queries for general application purpose like cache Group info provisioning. Being able to interpret the group scope part of the SAML (IDP) response token, for instance, is often a pre-requisite for new in-house developments.