SAS Viya 3.5 or indeed SAS Viya 3.4 (May 2019 Upgrade) provides options to enable true single sign-on with a third-party SAML or OpenID Connect provider. This requires some manual configuration of the Apache HTTP Server. In this blog we’ll look at some considerations and what you need to configure.
Single Sign-On with either SAML or OpenID Connect will mean that end-users no-longer need to interact with SAS Logon Manager to access the SAS Viya web applications. This configuration will not impact the Mobile application or Command-Line Interfaces. Equally, this configuration will have no impact on SAS Studio 4.4 on SAS Viya 3.4 or SAS Studio 5.2 (Basic) on SAS Viya 3.5.
The configuration we will use to provide Single Sign-On relies on part of the OpenID Connect specification. Since SAS Logon Manager is an OpenID Connect provider to the rest of the SAS web applications this will function for both SAML and OpenID Connect third-party authentication. This configuration will work as-is with SAS Viya 3.5. However, with SAS Viya 3.4 you need to ensure the version you are running has the emailDomain property for the third-party SAML or OpenID Connect provider.
Since the end-user will no-longer interact with SAS Logon Manager, they will no-longer see the standard login form. This means that end-users will not be able to log in with LDAP credentials or the sasboot account. In the configuration, we will provide some options to enable certain clients to still have access to the login form. Alternatively, end-users can directly access the /SASLogon/login URL to access the login form, they will then need to enter the URL for the application they wish to use after logging in.
First and foremost, the SAML or OpenID Connect provider must have an entry in the emailDomain property. For SAML this is under sas.logon.saml.providers.external_saml and for OpenID Connect this is under sas.logon.oauth.providers.external_oauth. The string entered in the emailDomain property does not have to be the actual email domain for the end-users. This can be any string, for example "matchme.com", since it will be provided by the configuration, we perform to the Apache HTTP Server. As such, this configuration will work well where the end-users have many different email domains. Or where the SAS Administrator is not sure what the email domains of the end-users will be.
The Single Sign-On configuration uses a login_hint parameter. The login_hint parameter is part of the OpenID Connect specification and supported by SASLogon. This query string parameter is passed in the authorize request, which is /SASLogon/oauth/authorize. SAS Logon expects to receive an email domain in the hint, and this value is compared against a list of email domains configured for each SAML or OpenID Connect identity provider. If there is a match, the user is redirected automatically to that provider, bypassing the login page.
To add the login_hint parameter to the authorize request a change must be made to the Apache HTTP Server. We will add a rewrite rule to the configuration to set the login_hint parameter on the requests to /SASLogon/oauth/authorize. In most cases the SAS Viya environment will be accessed over HTTPS. This means the changes we need to make should be made in the SSL configuration file. For RedHat Enterprise Linux this would be the /etc/httpd/conf.d/ssl.conf file. The new content will be added to the end of the file before the closing </VirtualHost> tag.
For deployments that are using HTTP, this should be placed in a new .conf file. The Apache HTTP Server processes the .conf files in alphabetical order and this one needs to occur before the proxy configuration in proxy.conf so it should be named accordingly, for example login_hint.conf. Putting the redirect rule in both places is fine too. The Apache HTTP Server must be restarted after making any changes to the configuration.
To enable the login_hint parameter for all authorize requests made to SAS Logon Manager you can use the following content:
# SSO for SAS Viya set login_hint parameter
RewriteEngine On
RewriteCond "%{QUERY_STRING}" !login_hint
RewriteRule "SASLogon/oauth/authorize" "/SASLogon/oauth/authorize?login_hint=matchme.com" [QSA,PT]
The RewriteCond statement ensures the rule is only applied when the query string, the part of the URL following a question mark, does not contain an existing login_hint. The RewriteRule then takes the request for SASLogon/oauth/authorize and appends the login_hint query parameter. Where the value of the login_hint matches the emailDomain entered in either the SAML or OpenID Connect configuration.
When the replacement URI contains a query string, the default behavior of RewriteRule is to discard the existing query string and replace it with the newly generated one. Using the [QSA] flag causes the query strings to be combined. The target (or substitution string) in a RewriteRule is assumed to be a file path, by default. The use of the [PT] flag causes it to be treated as a URI instead. That is to say, the use of the [PT] flag causes the result of the RewriteRule to be passed back through URL mapping, so that location-based mappings, such as Alias, Redirect, or ScriptAlias, for example, might have a chance to take effect. This is important for your SAS Viya environment since the URL must be redirected from the Apache HTTP Server to an instance of the SAS Logon Manager.
The example above, will add the login_hint to all authorize requests. This means that the SAS Logon Manager form will not be displayed for any users. Which means that the sasboot account cannot be used to access the environment. However, we can change the configuration slightly to enable the SAS Logon Manager form when accessed from a specific IP Address:
# SSO for SAS Viya set login_hint parameter except for specifc IP
RewriteEngine On
RewriteCond "%{QUERY_STRING}" !login_hint
RewriteCond expr "! -R '10.96.1.166'"
RewriteRule "SASLogon/oauth/authorize" "/SASLogon/oauth/authorize?login_hint=matchme.com" [QSA,PT]
The RewriteCond statements are combined using AND syntax. So, the RewriteRule will only apply when both conditions are true. This means in the example above that the request must not already contain the login_hint AND does not (!) come from the IP address 10.96.1.166, then the RewriteRule will apply. The "-R" in the second RewriteCond means the same as "%{REMOTE_ADDR} -ipmatch ...", but is more efficient according to the documentation.
So, we can provide Single Sign-On to all our end-users, but still allow our administrator on 10.96.1.166 access to the SAS Logon Manager form. But what if we want to still make the SAS Logon Manager form available to more than a single IP address? We could add more and more RewriteCond statements and add the [OR] flag to change the logic to OR from AND. However, this would soon become confusing and difficult to manage. Instead we can change the RewriteCond statement to use CIDR notation:
# SSO for SAS Viya set login_hint parameter except for specific IP Range
RewriteEngine On
RewriteCond "%{QUERY_STRING}" !login_hint
RewriteCond expr "! -R '10.96.1.0/24'"
RewriteRule "SASLogon/oauth/authorize" "/SASLogon/oauth/authorize?login_hint=matchme.com" [QSA,PT]
Now the second condition states the request must not come from any IP address in the range 10.96.1.0 – 10.96.1.255. So Single Sign-On will operate for any request that do not come from this range of IP addresses. These IP addresses will see the standard SAS Logon Manager form as normal.
Finally, as another set of examples for how you might want to add conditions to the RewriteRule, what about changing the behavior based on the browser rather than the IP address. To exclude the Microsoft Edge Browser:
# SSO for SAS Viya set login_hint parameter except for MS Edge browsers
RewriteEngine On
RewriteCond "%{QUERY_STRING}" !login_hint
RewriteCond "%{HTTP_USER_AGENT}" "!.*Edg.*"
RewriteRule "SASLogon/oauth/authorize" "/SASLogon/oauth/authorize?login_hint=matchme.com" [QSA,PT]
With these two condition statements anyone not using Microsoft Edge will get Single Sign-On. While accessing the SAS Viya environment in Microsoft Edge will result in the SAS Logon Manager form being displayed. Equally, the same could be done for the Google Chrome browser:
# SSO for SAS Viya set login_hint parameter except for Chrome Browsers
RewriteEngine On
RewriteCond "%{QUERY_STRING}" !login_hint
RewriteCond "%{HTTP_USER_AGENT}" "!.*Chrome.*"
RewriteRule "SASLogon/oauth/authorize" "/SASLogon/oauth/authorize?login_hint=matchme.com" [QSA,PT]
In this post we’ve demonstrated how you can easily enable Single Sign-On with either a third-party SAML or OpenID Connect provider. We’ve also demonstrated how you can simply extend the configuration to disable Single Sign-On for specific users, based either on IP address or browser type. You could even combine these example rules to enable one group of users to have Single Sign-On with SAML and another group of users with OpenID Connect.
Update: June 2024
It was pointed out to me that it might be necessary to restart the SAS Studio V operating system process to pick-up these changes.
Thank you, for the great article. Which SAML version is supported?
Hello,
Thank you for taking the time to comment: it is SAML version 2.0
When using SAML to logon, can we still use kerberos constrained delegation so that compute servers and cas code runs under the identity of the user? How can that be done?
Hello @CarlZeigler,
This can be done by leveraging the concept of "protocol transition" which is part of Kerberos Constrained Delegation. However, for this to work the username provided by the SAML assertions must be exactly the same as the User Principal Name (UPN) for the end-user. Also both the users and the SAS Service Principal Names (SPN) must be in the same Kerberos realm.
With this in-place when the SAS Logon Manager code attempts the S4U2SELF request it will use the username (UPN) provided by the SAML assertions and correctly obtain the ticket as the end-user.
Thank you for your time.
Stuart
Now I need to get SAS 9.4M7 doing the same thing.
Is there any recent documentation on ways to configure SAS 9.4 to use SAML for the web services login?
what I have found so far refers to earlier versions of Shibboleth than what we have...
With SAS 9.4 M7 the situation is slightly different. The integration for SAML or OpenID Connect is not directly within SAS Logon Manager. Instead SAS supports SAS Web Server Authentication and then it is up to you to choose and implement how users are authenticated to the SAS Web Server. As the documentation states: You can use any of the Apache modules (for example, Shibboleth) for third-party authentication. So, unfortunately SAS does not provide specific documentation for the different Apache modules you might use. So long as you are able to get the Apache authentication working with the documentation from Shibboleth, you should then be able to follow the steps in the SAS 9.4 M7 documentation to complete the configuration.
Thank you for your time.
Stuart
@StuartRogers What about M5? Thanks
Hello,
Our Viya 3.5 on Azure is based on U/P authn and LDAP bind to on-prem Oracle 11g OVD/OID via ExpressRoute. We also have another instance of 3.5 on-prem that is integrated with AD (U/P or Kerberos). Our new on-prem IAM suite is based on OAIM 12c and OUD. We also have 9.4 M5 on-prem. What is the recommended OAuth/OIDC setup and OIDC providers for these deployments, having in mind we'll transition to 4.x in foreseeable future?
Thanks,
Bran
Hello @kopbran
To start I just want to clarify a few terms:
SAS Viya 3.5 either on-prem or deployed in a cloud infrastructure supports both OpenID Connect (OIDC) and SAML. SAS 9.4 M1(and later) also supports "SAS Web Server Authentication", this is only supported for the web applications and does not impact the desktop clients such as SAS Enterprise Guide and SAS Management Console. The SAS 9.4 SAS Web Server Authentication would support either OIDC or SAML. Then SAS Viya (since it's 2020.1 release) also supports OIDC and SAML.
So you should be able to use your new OIAM/OUD to provide LDAP to all three SAS environments. This would provide the user information for SAS Viya and populate the SAS 9.4 Metadata Server. You could then leverage the username/password authentication for the SAS 9.4 desktop applications. You could look at SAS Web Server Authentication for SAS 9.4 web applications leveraging OIDC. You could also then use OIDC for SAS Viya, both your existing SAS Viya 3.5 and the next release as you transition.
One caveat would be to question the use of Kerberos with Active Directory. You'll need to review why Kerberos was chosen; was it just to provide Single Sign-On to SAS Viya 3.5, or was it chosen to provide Kerberos delegation through SAS Viya 3.5 and out to your data sources.
Thank you for your time.
Stuart
Thank you for this info!
I have a question for you: if customer wants to implement MFA then it is my understanding they can configure SAS Logon Manager to use SAML or OIDC and it is up to the Identity Provider to implement MFA, right?
If so, I am not sure how to match the userids in the Identity Provider with the users extracted from AD by the Identities service. Is there a mechanism to sync AD user to the Identity Provider's list of users?
Thanks,
Eyal
Yes it would be up to the SAML or OIDC provider to implement Multi-Factor Authentication (MFA).
Importing or loading the Active Directory users into the Identity Provider will also be down to the chosen Identity Provider. Something like RedHat's Keycloak has an LDAP interface that would allow users to be loaded, similar interfaces exist for OneLogin's PingFederate. Something like Microsoft Entra ID would require sync'ing from on-premises AD to Microsoft Entra ID. So you can see it would be totally dependent on that third-party Identity Provider.
Thank you for your time.
Stuart
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 16. Read more here about why you should contribute and what is in it for you!
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.