SAS Viya 2021.2.5 Kerberos Hybrid Authentication Process Flows

[#1]

As we discussed previously when we discussed the Kerberos scenarios SAS Viya supports Kerberos Hybrid Authentication. This time we will examine in more detail the process flow of authentication for the Kerberos Hybrid Authentication modes. Remember we defined two modes: Kerberos Hybrid Authentication with User Credentials and Kerberos Hybrid Authentication with Protocol Transition. The key part of Kerberos Hybrid Authentication is that we do not need to use Kerberos for SAS Logon Manager. Instead, we can use any supported authentication mechanism with SAS Logon Manager, for example this could be LDAP, OpenID Connect, or SAML. In this post we will look at two use-cases for each mode: launching a SAS Compute Server through SAS Studio and launching a CAS session from SAS Visual Analytics.

Kerberos Hybrid Authentication with User Credentials

With this mode the SAS Kerberos Proxy will retrieve user credentials, a username and password, from the credentials microservice. The user credentials are stored in the KerberosAuth authentication domain. Our end-users could store their own set of credentials in the KerberosAuth authentication domain, or as an administrator we could store one set of credentials to be used by a group of users.

Launching SAS Compute Server

In this use-case an end-user logs into SAS Studio.

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

The steps are as follows:

1. End-user accesses SAS Studio for the first time and is redirected to SAS Logon Manager.
2. The browser follows the redirect to SAS Logon Manager. As the end-user has no current session with SAS Logon Manager it responds with the non-Kerberos authentication flow. This could be the standard login form, or automatic redirection to the third-party OIDC or SAML Identity provider.
3. Possibly the end-user authenticates with the third-party OIDC or SAML Identity provider.
4. The browser submits the non-Kerberos authentication to SAS Logon Manager; either submitting a LDAP credential, OIDC Authorization Code, or SAML Assertions.
5. SAS Logon Manager processes the submitted credentials.
6. SAS Logon Manager submits the username to the Identities microservice to obtain the group information.
7. The Identities microservice queries the group information from the LDAP provider or its internal database for identity information pushed from a SCIM client.
8. The Identities microservice responds to SAS Logon Manager with the group information.
9. SAS Logon Manager redirects the end-user back to the calling web application, SAS Studio, with an authorization code.
10. The browser follows the redirection and submits the authorization code to SAS Studio.
11. SAS Studio exchanges the authorization code for an ACCESS Token from SAS Logon Manager, which includes the end-users group information. SAS Studio authenticates with its client credentials to SAS Logon Manager for the exchange.
12. SAS Studio uses the end-user’s ACCESS Token to request a SAS Compute Server session from the Launcher microservice.
13. The Launcher microservice uses the end-user’s ACCESS Token to request the user attributes (UID, GID, and secondary GID) from the Identities microservice.
14. The Launcher microservice includes the end-user’s ACCESS Token and user attributes in the request to Kubernetes to launch the SAS Compute Server pod.
15. The SAS Compute Server pod includes the sas-krb5-proxy sidecar container. The SAS Compute Server makes a HTTP request to the sas-krb5-proxy sidecar on localhost (127.0.0.1) which uses the end-user’s ACCESS Token. The sas-krb5-proxy sidecar then makes a request to SAS Logon Manager for the delegated Kerberos TGT again using the end-user’s ACCESS Token, including the sas-krb5-proxy Service Principal Name (SPN).
16. SAS Logon Manager responds with a 404 not found
17. The sas-krb5-proxy sidecar makes a request to the credentials microservice using the end-user’s ACCESS Token requesting a username/password from the KerberosAuth authentication domain.
18. The credentials microservice reads the encrypted username/password from the database.
19. The credentials microservice responds with the username/password that were previously stored in the KerberosAuth authentication domain either for the individual end-user or for a group the end-user is a member of.
20. The sas-krb5-proxy uses the username/password to initialize a Kerberos credential (TGT) from the KDC.
21. The sas-krb5-proxy streams the TGT back to the SAS Compute Server container within the same pod. The SAS Compute Server container writes the TGT out to Kerberos ticket cache in /tmp with the default name format.

 

Accessing SAS Cloud Analytic Services from SAS Visual Analytics

In this use-case an end-user accesses SAS Visual Analytics which launches a SAS Cloud Analytic Services session.

The steps are as follows:

1. End-user accesses SAS Visual Analytics for the first time and is redirected to SAS Logon Manager.
2. The browser follows the redirect to SAS Logon Manager. As the end-user has no current session with SAS Logon Manager it responds with the non-Kerberos authentication flow. This could be the standard login form, or automatic redirection to the third-party OIDC or SAML Identity provider.
3. Possibly the end-user authenticates with the third-party OIDC or SAML Identity provider.
4. The browser submits the non-Kerberos authentication to SAS Logon Manager; either submitting a LDAP credential, OIDC Authorization Code, or SAML Assertions.
5. SAS Logon Manager processes the submitted credentials.
6. SAS Logon Manager submits the username to the Identities microservice to obtain the group information.
7. The Identities microservice queries the group information from the LDAP provider or its internal database for identity information pushed from a SCIM client.
8. The Identities microservice responds to SAS Logon Manager with the group information.
9. SAS Logon Manager redirects the end-user back to the calling web application, SAS Visual Analytics, with an authorization code.
10. The browser follows the redirection and submits the authorization code to SAS Visual Analytics.
11. SAS Visual Analytics exchanges the authorization code for an ACCESS Token from SAS Logon Manager, which includes the end-users group information. SAS Visual Analytics authenticates with its client credentials to SAS Logon Manager for the exchange.
12. SAS Visual Analytics uses the end-user’s ACCESS Token to request a SAS Cloud Analytic Services session from the CAS Controller.
13. The CAS Controller uses the end-user’s ACCESS Token to request the user attributes (UID, GID, and secondary GID) from the Identities microservice.
14. The SAS Cloud Analytic Services pod includes the sas-krb5-proxy sidecar container. CAS makes a HTTP request to the sas-krb5-proxy sidecar on localhost (127.0.0.1) which uses the end-user’s ACCESS Token. The sas-krb5-proxy sidecar then makes a request to SAS Logon Manager for the delegated Kerberos TGT again using the end-user’s ACCESS Token.
15. SAS Logon Manager responds with a 404 not found
16. The sas-krb5-proxy sidecar makes a request to the credentials microservice using the end-user’s ACCESS Token requesting a username/password from the kerberosAuth authentication domain.
17. The credentials microservice reads the encrypted username/password from the database.
18. The credentials microservice responds with the username/password that were previously stored in the kerberosAuth authentication domain either for the individual end-user or for a group the end-user is a member of.
19. The sas-krb5-proxy uses the username/password to initialize a Kerberos credential (TGT) from the KDC.
20. The sas-krb5-proxy streams the TGT back to the CAS container within the same pod. The CAS container writes the delegated TGT out to a Kerberos ticket cache in /tmp with a default name format.

 

Kerberos Hybrid Authentication with Protocol Transition

Next, we will examine the authentication flow with Kerberos Hybrid Authentication with Protocol Transition. In this mode no user credentials need to be stored within the SAS Viya environment. Instead, the SAS Kerberos Proxy leverages Kerberos Constrained Delegation to obtain the credentials on behalf of the end-user. Remember, to use Kerberos Hybrid Authentication with Protocol Transition we need to ensure the username returned from the initial authentication matches the username in our Kerberos Key Distribution Center (KDC). This initial authentication, to SAS Logon Manager, could leverage LDAP credentials, OpenID Connect, or SAML.

 

Launching SAS Compute Server

In this use-case an end-user logs into SAS Studio.

The steps are as follows:

1. End-user accesses SAS Studio for the first time and is redirected to SAS Logon Manager.
2. The browser follows the redirect to SAS Logon Manager. As the end-user has no current session with SAS Logon Manager it responds with the non-Kerberos authentication flow. This could be the standard login form, or automatic redirection to the third-party OIDC or SAML Identity provider.
3. Possibly the end-user authenticates with the third-party OIDC or SAML Identity provider.
4. The browser submits the non-Kerberos authentication to SAS Logon Manager; either submitting a LDAP credential, OIDC Authorization Code, or SAML Assertions.
5. SAS Logon Manager processes the submitted credentials.
6. SAS Logon Manager submits the username to the Identities microservice to obtain the group information.
7. The Identities microservice queries the group information from the LDAP provider or its internal database for identity information pushed from a SCIM client.
8. The Identities microservice responds to SAS Logon Manager with the group information.
9. SAS Logon Manager redirects the end-user back to the calling web application, SAS Studio, with an authorization code.
10. The browser follows the redirection and submits the authorization code to SAS Studio.
11. SAS Studio exchanges the authorization code for an ACCESS Token from SAS Logon Manager, which includes the end-users group information. SAS Studio authenticates with its client credentials to SAS Logon Manager for the exchange.
12. SAS Studio uses the end-user’s ACCESS Token to request a SAS Compute Server session from the Launcher microservice.
13. The Launcher microservice uses the end-user’s ACCESS Token to request the user attributes (UID, GID, and secondary GID) from the Identities microservice.
14. The Launcher microservice includes the end-user’s ACCESS Token and user attributes in the request to Kubernetes to launch the SAS Compute Server pod.
15. The SAS Compute Server pod includes the sas-krb5-proxy sidecar container. The SAS Compute Server makes a HTTP request to the sas-krb5-proxy sidecar on localhost (127.0.0.1) which uses the end-user’s ACCESS Token. The sas-krb5-proxy sidecar then makes a S4U2SELF request to the KDC to obtain a Service Ticket for the sas-krb5-proxy Service Principal Name (SPN) as the end-user. As part of the S4U2SELF request the sas-krb5-proxy may initialize a TGT for the HTTP principal using the long-term key for the principal from the Kerberos keytab.
16. Since the HTTP principal is configured for TrustedToAuthForDelegation the KDC responds with the Service Ticket and delegated credentials. The sas-krb5-proxy uses the long-term key for the principal from the Kerberos keytab to decrypt the response, obtaining the delegated credentials. The sas-krb5-proxy streams the delegated credentials back to the SAS Compute Server container within the same pod. The SAS Compute Server container writes the delegated credentials out to a Kerberos ticket cache in /tmp with a default name format.

 

Accessing SAS Cloud Analytic Services from SAS Visual Analytics

In this use-case an end-user accesses SAS Visual Analytics which launches a SAS Cloud Analytic Services session.

The steps are as follows:

1. End-user accesses SAS Visual Analytics for the first time and is redirected to SAS Logon Manager.
2. The browser follows the redirect to SAS Logon Manager. As the end-user has no current session with SAS Logon Manager it responds with the non-Kerberos authentication flow. This could be the standard login form, or automatic redirection to the third-party OIDC or SAML Identity provider.
3. Possibly the end-user authenticates with the third-party OIDC or SAML Identity provider.
4. The browser submits the non-Kerberos authentication to SAS Logon Manager; either submitting a LDAP credential, OIDC Authorization Code, or SAML Assertions.
5. SAS Logon Manager processes the submitted credentials.
6. SAS Logon Manager submits the username to the Identities microservice to obtain the group information.
7. The Identities microservice queries the group information from the LDAP provider or its internal database for identity information pushed from a SCIM client.
8. The Identities microservice responds to SAS Logon Manager with the group information.
9. SAS Logon Manager redirects the end-user back to the calling web application, SAS Visual Analytics, with an authorization code.
10. The browser follows the redirection and submits the authorization code to SAS Visual Analytics.
11. SAS Visual Analytics exchanges the authorization code for an ACCESS Token from SAS Logon Manager, which includes the end-users group information. SAS Visual Analytics authenticates with its client credentials to SAS Logon Manager for the exchange.
12. SAS Visual Analytics uses the end-user’s ACCESS Token to request a SAS Cloud Analytic Services session from the CAS Controller.
13. The CAS Controller uses the end-user’s ACCESS Token to request the user attributes (UID, GID, and secondary GID) from the Identities microservice.
14. The SAS Cloud Analytic Services pod includes the sas-krb5-proxy sidecar container. CAS makes a HTTP request to the sas-krb5-proxy sidecar on localhost (127.0.0.1) which uses the end-user’s ACCESS Token. The sas-krb5-proxy sidecar then makes a S4U2SELF request to the KDC to obtain a Service Ticket for the sas-krb5-proxy Service Principal Name (SPN) as the end-user. As part of the S4U2SELF request the sas-krb5-proxy may initialize a TGT for the HTTP principal using the long-term key for the principal from the Kerberos keytab.
15. Since the HTTP principal is configured for TrustedToAuthForDelegation the KDC responds with the Service Ticket and delegated credentials. The sas-krb5-proxy uses the long-term key for the principal from the Kerberos keytab to decrypt the response, obtaining the delegated credentials. The sas-krb5-proxy streams the delegated credentials back to the CAS container within the same pod. The CAS container writes the delegated credentials out to a Kerberos ticket cache in /tmp with a default name format.

 

Conclusion

You can clearly see the important role played by the SAS Kerberos Proxy sidecar container in these Kerberos Hybrid Authentication modes, for both use-cases we examined. Essentially, up until the SAS Kerberos Proxy obtains the Kerberos credentials the authentication processing for the SAS Viya environment is the same as normal. As we will see in the next post, when we look at the configuration, the way we leverage the SAS Kerberos Proxy will simplify the configuration we need to complete.

Find more articles from SAS Global Enablement and Learning here.

[timmat]

Hi @StuartRogers,

First of all, thank you very much for such a useful article! The flow diagrams and narrative really make clear what is going on inside.

I am currently trying to troubleshoot a hybrid kerberos w/ protocol transition problem and have been trying to find the forthcoming configuration post you mention at the end of this article. I have built my kustomization by referring to previous GEL Kerberos articles but these have all been for much earlier versions of Viya and I'm aware how rapidly Viya is changing and improving. Did you post the follow-up article? I've had a look for all GEL-tagged posts and can't see anything which fits.

If it's not too much trouble I will outline my scenario in case you have any thoughts?

I'm deploying Viya 2023.3-LTS on OpenShift 4.10 w/ k8s 1.24.6. I've included the relevant snippets of my kustomization.yaml below. I believe I've obeyed the kustomization-entries-ordering requirements for any elements which are position sensitive.

resources:
kerberos/http
kerberos/sas-servers
kerberos/cas-servers
transformers:
cas-enable-host.yaml
kerberos/sas-servers/sas-kerberos-job-tls.yaml
kerberos/sas-servers/sas-kerberos-deployment-tls.yaml
kerberos/sas-servers/sas-kerberos-tls-transformer.yaml
kerberos/sas-servers/sas-kerberos-direct.yaml (I understand from your posts I no longer need this so will remove on the next respin)
configMapGenerator:
- name: sas-cas-config
  behavior: merge
  literals:
  - CASCLOUDNATIVE=0

I followed the steps for Unconstrained Delegation from your earlier article (https://communities.sas.com/t5/SAS-Communities-Library/SAS-Viya-2020-1-4-and-later-Kerberos-Delegati...) to create my configMap settings. 

Identities is configured to use LDAP to AD and I'm using userPrincipalName (switched from sAMAccountName because I wanted to avoiding relying on krb5.conf/default_realm to handle name extension to Kerberos principal) as the key user attribute.

I've registered the HTTP SPN in AD (configured with the proper AES enctypes, set for unconstrained delegation, the SPN has an FQDN which resolves via a wildcard A record to the IP of my ingress) and provided the keytab/krb5.conf in the necessary configMaps above (http, cas-servers, sas-servers).

My krb5.conf seems fully-formed: from a shell in the same environment I can set KRB5_TRACE and watch kinit/klist/kvno work successfully (my krb5.conf has debug logging enabled) for the HTTP SPN.

I've applied SCCs as appropriate, and when Viya runs as LDAP-only it is ok so I'm pretty sure my base platform is good.

None of the clients are domain-joined to the AD I'm using for Identities/Kerberos; users logon to sas-logon via LDAP using uPN which is authN via LDAP and this is successful. When trying to start a SAS Studio session things go wrong. sas-launcher instantiates the sas-compute-server-nnnn pod which completes its initContainers, but in the sas-krb5-proxy container the log reports a series of errors, and compute and doesn't finish connecting back to Studio.

{"level":"info","version":1,"source":"sas-run-tool","messageKey":"sonder-log-icu.run.tool.waiting.for.service.finish.log","properties":{"logger":"tools/run","caller":"impl/executor.go:263"},"timeStamp":"2023-08-02T18:51:30.389086+00:00","message":"Service successfully launched. Waiting for service to finish."}
Info: 2023/08/02 18:51:30 main: running with effective configuration: {"addrString":"127.0.0.1:55901","libPath":"/usr/lib64/libgssapi_krb5.so.2","credPath":"/tmp/","spn":"HTTP/viya.apps.ocp.DOMAIN.NAME","credentialsAuthDomain":"KerberosAuth"}
Info: 2023/08/02 18:51:30 main: SASLogonURL: https://sas-logon-app/SASLogon/kerberos/ticketService?spn=HTTP/viya.apps.ocp.DOMAIN.NAME
Info: 2023/08/02 18:51:30 main: loading RootCAs from: SSL_CERT_FILE=/security/trustedcerts.pem
Info: 2023/08/02 18:51:30 GSSAPI Trace: Loading "/usr/lib64/libgssapi_krb5.so.2"
Info: 2023/08/02 18:51:30 GSSAPI Trace: krb.Load() succeeded:
Debug: 2023/08/02 18:51:30 GSSAPI Debug: In AcquireCredWithKinit()
Debug: 2023/08/02 18:51:30 krbAuth: Authenticator.found spn from credential HTTP/viya.apps.ocp.DOMAIN.NAME@CORRECT.KERB.REALM.NAME
Info: 2023/08/02 18:51:30 main: Starting HTTP server on 127.0.0.1:55901
Debug: 2023/08/02 18:51:30 WriteCcacheHandler(1): found credential of type *oauth.UserData
Debug: 2023/08/02 18:51:30 WriteCcacheHandler(1): parameters from query:
Debug: 2023/08/02 18:51:30 negotiateFromSasLogon: forwarding Oauth credentials to https://sas-logon-app/SASLogon/kerberos/ticketService?spn=HTTP/viya.apps.ocp.DOMAIN.NAME
Debug: 2023/08/02 18:51:30 negotiateFromSasLogon: SASLogon returned content types: [text/html;charset=UTF-8]
Debug: 2023/08/02 18:51:30 basicFromCredentialsService: checking KerberosAuth authDomain for credentials
Debug: 2023/08/02 18:51:30 basicFromCredentialsService: sending to https://sas-credentials/credentials/domains/KerberosAuth/secrets
Error: 2023/08/02 18:51:30 WriteCcacheHandler(2): failed to proxy oauth credentials to SASLogon
2023/08/02 18:51:30 http: superfluous response.WriteHeader call from gitlab.sas.com/convoy/krb5-proxy/middleware/auth.(*cleanAuthenticateHeadersWriter).WriteHeader (auth.go:130)
Warn: 2023/08/02 18:51:30 WriteCcacheHandler(2): No kerberos credential found in WriteCcacheHandler function.

Aside from the JSON data at the beginning, this stanza repeats ~10 times. 

The parts which stand out to me are:

1. The Oauth mentions: I'm not using this as I do LDAP for authN in sas-logon-manager,

2. Checking KerberosAuth auth domain: I didn't think this would be a factor unless I was using stored user credentials, which I'm not.

It feels to me that I've ended up with a configuration which is trying to do Kerberos Hybrid Auth with User Credentials, rather than KHA with Protocol Transition.

I suspect that my config is a bit outdated as it's based on your posts for Viya 2020.x so tomorrow I am going to refresh my kustomization in light of your other posts about the changes in 2023.03, but if there is anything obvious you can spot I would very much appreciate your help 🙂 

[StuartRogers]

@timmat I would encourage you to open a Technical Support track where they will be able to work through the details with you in a better format than the comments here allow for.

For Kerberos Hybrid Authentication with Protocol Transition you must have Kerberos Constrained Delegation configured.  This means that the principal must be correctly configured for constrained delegation and that in the configmaps.yaml you must have: 

- SAS_CONSTRAINED_DELEG_ENABLED="true"

 included in the literals section.

Then you need to consider the User Principal Name that will be used by the SAS Kerberos Proxy sidecar to obtain the credentials.  You mention using LDAP to initially authenticate.  This means the sidecar will construct the UPN based on the LDAP Distinguished Name for your user.

Thank you for your time.

Stuart

[EyalGonen]

Hi @StuartRogers 

I got a question from a prospect about hybrid SAS Viya (assume latest stable release) authentication in the sense that end-users authenticate regularly, LDAP with credentials for example, but SAS admins need to authenticate additionally with MFA. How can it be setup to force MFA only for SAS admins and not for SAS end-users?

I was thinking about utilizing two different IdPs for this purpose (one for end-users and one for admins) but not sure this makes any sense.

Can you advise?

Thanks