SAS Viya 3.5 OpenID Connect with Ping Identity
SAS Viya has supported integration with a third-party OpenID Connect provider since SAS Viya 3.3. In this article I want to look at configuring SAS Viya 3.5 to use Ping Identity as the third-party OpenID Connect provider. Ping Identity offer both PingFederate which is an on-prem solution and PingOne is a cloud-based solution. With both PingFederate and PingOne either SAML or OpenID Connect can be used for authentication, for the purposes of this article I will focus on OpenID Connect.
What is Ping Identity
Ping Identity is a major Identity and Access Management (IAM) provider with solutions that work in any on-premises, cloud and hybrid environment. As they state on their website:
At Ping Identity, we champion the unique identity of enterprises to simplify how they provide secure and seamless digital experiences for their workforce and customers. We help prevent security breaches, increase productivity and provide personalized experiences. With a world-class network of partners, our singular focus is on enterprise customers and their success.
PingFederate is the on-premises solution which is described as:
PingFederate is an enterprise federation server that enables user authentication and single sign-on. It serves as a global authentication authority that allows employees, customers and partners to securely access all the applications they need from any device. PingFederate easily integrates with applications across the enterprise, third-party authentication sources, diverse user directories and existing IAM systems, all while supporting current and past versions of identity standards like OAuth, OpenID Connect, SAML and WS-Federation.
PingOne is the cloud-based solution that provides Identity as a Service, which is described as:
PingOne is a best-in-class Identity-as-a-Service (IDaaS) offering for organizations that prefer a more hands-free approach to identity and access management (IAM) for their customers and workforce.
PingFederate and PingOne offer both OpenID Connect and SAML to provide Single Sign-On into other applications. Here we are only concerned with one of the options: OpenID Connect.
All the steps documented here were made possible by Ping Identity providing me with a developer account and free trial licenses.
PingFederate Configuration
I found that PingFederate is a very powerful and easily customized package. At times the wealth of different options to configure made it confusing. To simplify the explanation of what was configured I created the diagram below:
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
We will walk through the configuration in the order shown in the diagram from 1-8. All this configuration is completed in the web administration console for PingFederate: https://<<hostname>>:9999/pingfederate/app. Which will result in being able to authenticate our Active Directory users through PingFederate using OpenID Connect. The steps are:
- Either as part of the initial configuration wizard or through the System Settings configure the Data Store to access Active Directory.
- Within the Security Settings create a new private key and Certificate which will be used to sign the OpenID Connect ID token. These are generated by the administration console.
- To keep the SAS configuration as separate as possible from any other applications, define a new SASscope which will hold the username required by SAS Logon Manager. This is completed in Scope Management, under the Authorization Server within the OAuth section of the administration console.
- Create a new SASTokenManagement Access Token Management definition under Token Management. This defines the type of token, signature algorithm, encryption keys, and attributes.
- Create a new Access Token Attribute Mapping under Token Management. This maps the fields returned by the HTML form authenticator (seen on the screen by the end-user as part of the authentication process) to the attributes defined in the SASTokenManagement.
- Create a new OpenID Connect Policy Management as SASPolicy under Token Mapping. This brings together the SASscope, attributes and mappings.
- Create a new IdP Adaptor Mapping under Grant Mappings. This maps the values from the HTML form to the persistent grant. This requires the SASTokenManagement already be defined.
- Create the new client definition for SAS Logon Manager. Here you define the standard redirect URI: https://<<viya.customer.com>>/SASLogon/login/callback/external_oauth, the allowed grant types, link to the SASTokenManagement, and SASPolicy. This also provides the auto-generated Client Secret which will be required to configure SAS Logon Manager.
With all this complete, PingFederate will provide SAS Logon Manager with the end-users sAMAccountName as the preferred_username from Active Directory when the SASscope is requested.
I decided to add the new SASscope since I wanted to separate the additional configuration for SAS Viya from any existing configuration. This should ensure the configuration shown above has no impact on any existing applications integrated with Ping Federate. However, if Ping Federate is already configured to provide the sAMAccountName as the preferred_username this is not necessary. Equally, if no other applications are integrated with Ping Federate, the default scope can be updated instead of creating the new SASscope.
PingOne Configuration
PingOne, as a cloud-based "Identity as a Service" (IaaS) offering, has less configuration options than PingFederate. Again, I’ve created a graphic to show what was configured.
Since we want to authenticate our Active Directory users into SAS Viya using PingOne we need to get those Active Directory users into PingOne. Ping Identity provides an application that is installed on-prem to synchronize the Active Directory content into PingOne, called AD Connect. So, the first step was to follow the Ping Identity documentation to deploy this component onto a Windows Server within the Active Directory domain. This makes the Active Directory users available to PingOne.
The rest of the configuration is completed in the PingOne web administration console: https://admin.pingone.com/web-portal. Under Applications, My Applications, OIDC we select Add Application and complete the following details:
- Select Web App as application type
- Enter the application name, description, and category
- Select Authorization Code and Refresh Token as allowed Grant Types
- Select Add Secret and copy both the Client ID and Client Secret for the SAS Logon Manager configuration
- Enter Start SSO URL as: https://<<viya.customer.com>>/
- Enter Redirect URIs as: https://<<viya.customer.com>>/SASLogon/login/callback/external_oauth
- Map the attribute sub to sAMAccountName
- Select an Active Directory group that should be able to access SAS Viya
In testing, PingOne was only able to provide the sAMAccountName to SAS Logon Manager when it was mapped to the sub attribute. Any attempts to define additional scopes, in the same way I did with PingFederate, did not work. But since the mapping is specific to the SAS Viya client definition it does not impact any other client applications defined in PingOne.
This completes all the configuration required in PingOne.
SAS Viya Configuration
The SAS Viya configuration is completed within SAS Environment Manager. The settings are all contained within the sas.logon.oauth.providers.external_oauth definition. The following table provides the settings that are required for integration with PingFederate:
The <<CLIENT ID>> and <<CLIENT SECRET>> will need to be copied from the PingFederate administrative interface. The authUrl, discoveryUrl, and tokenUrl values will have the standard form shown in the table above, also all these values can be discovered from the https://<<PING_HOST>>:<<PING_PORT>>/.well-known/openid-configuration URL.
The other two specific properties, for PingFederate, control the username that SAS Viya will obtain from the ID Token provided by PingFederate. The attributeMappings.user_name attribute is set to preferred_username which will return the username from the ID Token. However, to ensure that PingFederate includes the preferred_username claim in the ID Token the scopes attribute must be set to "openid,SASscope". If SASscope is not included in the scopes then the preferred_username will not be added to the claims in the ID Token, and so the username will not be available to SAS Viya.
With this configuration complete, you can either wait for the configuration key/values to refresh or SAS Logon Manager can be restarted, for example on RedHat with:
systemctl restart sas-viya-saslogon-default
The following table provides the settings that are required for integration with PingOne:
The <<CLIENT ID>> and <<CLIENT SECRET>> will need to be copied from the PingOne administrative interface. The authUrl, discoveryUrl, and tokenUrl values will have the standard form shown in the table above, also all these values can be discovered from the https://sso.connect.pingidentity.com/<<CLIENT ID>>/.well-known/openid-configuration URL.
The other specific property, for PingOne, controls the username that SAS Viya will obtain from the ID Token provided by PingOne. The attributeMappings.user_name attribute is set to sub which will return the username from the ID Token. This is dependent on the mapping configured in the PingOne administrative interface.
With this configuration complete, you can either wait for the configuration key/values to refresh or SAS Logon Manager can be restarted, for example on RedHat with:
systemctl restart sas-viya-saslogon-default
Then when end-users access the SAS Viya environment the SAS Logon Manager form will now include the link to authenticate with either PingFederate or PingOne. If you want to provide true Single Sign-On where the SAS Logon Manager form is not displayed, you’ll need to follow the steps we’ve discussed before leveraging the login_hint parameter.
Remember, for the end-users to be correctly authenticated to the SAS Viya environment the value returned by PingFederate or PingOne must match the value returned from your LDAP provider as sas.identities.providers.ldap.user.accountID, by default sAMAccountName.
Conclusion
Ping Identity is a popular authentication provider offering both on-premises and Identity as a Service options. With SAS Viya 3.5, customers can configure authentication and single sign-on with Ping Identity using OpenID Connect. Getting the correct configuration setup in PingFederate or PingOne will be key to successfully implementing this authentication mechanism. The setup within SAS Viya 3.5 is straightforward so long as you are aware of and have planned for the correct format of username.
