SAS Viya 2020.1.4 (and later) Kerberos Unconstrained Delegation Process Flow

[#1]

Following on from looking at the overview of Kerberos delegation introduced with the 2020.1.4 release of SAS Viya, this time we will examine the process flow of authentication. In this case we will examine Kerberos Unconstrained Delegation, next time we will examine Kerberos Constrained Delegation. In this article we will look at three different use-cases: launching a SAS Compute Server through SAS Studio, launching a CAS session from SAS Visual Analytics, and directly connecting to SAS Cloud Analytic Services from SAS 9.4 Maintenance 5 or higher.

Kerberos Unconstrained Delegation: 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 a 401 HTTP response code.
3. The 401 HTTP response code triggers the browser to attempt Kerberos authentication and a request is submitted to the KDC for the service ticket. This request leverages the existing Ticket-Granting Ticket held on the client. Since the HTTP Service Principal is trusted for delegation to any service both the Service Ticket and delegated TGT are returned.
4. The browser submits the Service Ticket and delegated TGT as a response to the 401 HTTP response code to SAS Logon Manager.
5. SAS Logon Manager uses the long-term key for the HTTP Service Principal, obtained from the Kerberos keytab, to decrypt the Service Ticket and extract the authenticator information. This includes the end-user’s UPN and authenticates the end-user to SAS Logon Manager.
6. SAS Logon Manager stores the delegated TGT with the Credentials microservice. SAS Logon Manager connects with its own client credentials to the Credentials microservice. Further access to the delegated TGT is controlled by access controls; only by presenting the end-user’s ACCESS Token can the delegated TGT be retrieved.
7. The Credentials microservice stores the delegated TGT within the database, which could be Crunchy Data PostgreSQL or Azure PostgreSQL. The Credentials microservice encrypts the data before it is written to the database.
8. SAS Logon Manager strips the realm from the UPN and submits the username to the Identities microservice to obtain the group information.
9. The Identities microservice queries the group information from the LDAP provider.
10. The Identities microservice responds to SAS Logon Manager with the group information.
11. SAS Logon Manager redirects the end-user back to the calling web application, SAS Studio, with an authorization code.
12. The browser follows the redirection and submits the authorization code to SAS Studio.
13. 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.
14. SAS Studio uses the end-user’s ACCESS Token to request a SAS Compute Server session from the Launcher microservice.
15. The Launcher microservice uses the end-user’s ACCESS Token to request the user attributes (UID, GID, and secondary GID) from the Identities microservice.
16. 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.
17. 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).
18. SAS Logon Manager fetches the stored delegated TGT from the Credentials microservice using the end-user’s ACCESS Token.
19. SAS Logon Manager uses the stored delegated TGT to initialize a security context with the sas-krb5-proxy SPN and requests a service ticket for the sas-krb5-proxy SPN from the KDC. Since the sas-krb5-proxy Service Principal is trusted for delegation to any service both the Service Ticket and delegated TGT are returned.
20. SAS Logon Manager sends a Kerberos HTTP response to the sas-krb5-proxy sidecar.
21. The sas-krb5-proxy sidecar uses the long-term key for the principal from the Kerberos keytab to accept the Kerberos HTTP response from SAS Logon Manager. Decrypting the Service Ticket enables the sas-krb5-proxy to access the delegated TGT. The sas-krb5-proxy streams the delegated TGT back to the SAS Compute Server container within the same pod. The SAS Compute Server container writes the delegated TGT out to a Kerberos ticket cache in /tmp with a default name format.

Kerberos Unconstrained Delegation: SAS Cloud Analytic Services

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 a 401 HTTP response code.
3. The 401 HTTP response code triggers the browser to attempt Kerberos authentication and a request is submitted to the KDC for the service ticket. This request leverages the existing Ticket-Granting Ticket held on the client. Since the HTTP Service Principal is trusted for delegation to any service both the Service Ticket and delegated TGT are returned.
4. The browser submits the Service Ticket and delegated TGT as a response to the 401 HTTP response code to SAS Logon Manager.
5. SAS Logon Manager uses the long-term key for the HTTP Service Principal, obtained from the Kerberos keytab, to decrypt the Service Ticket and extract the authenticator information. This includes the end-user’s UPN and authenticates the end-user to SAS Logon Manager.
6. SAS Logon Manager stores the delegated TGT with the Credentials microservice. SAS Logon Manager connects with its own client credentials to the Credentials microservice. Further access to the delegated TGT is controlled by access controls; only by presenting the end-user’s ACCESS Token can the delegated TGT be retrieved.
7. The Credentials microservice stores the delegated TGT within the database, which could be Crunchy Data PostgreSQL or Azure PostgreSQL. The Credentials microservice encrypts the data before it is written to the database.
8. SAS Logon Manager strips the realm from the UPN and submits the username to the Identities microservice to obtain the group information.
9. The Identities microservice queries the group information from the LDAP provider.
10. The Identities microservice responds to SAS Logon Manager with the group information.
11. SAS Logon Manager redirects the end-user back to the calling web application, SAS Visual Analytics, with an authorization code.
12. The browser follows the redirection and submits the authorization code to SAS Visual Analytics.
13. 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.
14. SAS Visual Analytics uses the end-user’s ACCESS Token to request a SAS Cloud Analytic Services session from the CAS Controller.
15. The CAS Controller uses the end-user’s ACCESS Token to request the user attributes (UID, GID, and secondary GID) from the Identities microservice.
16. 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.
17. SAS Logon Manager fetches the stored delegated TGT from the Credentials microservice using the end-user’s ACCESS Token.
18. SAS Logon Manager uses the stored delegated TGT to initialize a security context with the sas-krb5-proxy SPN and requests a service ticket for the sas-krb5-proxy SPN from the KDC. Since the sas-krb5-proxy Service Principal is trusted for delegation to any service both the Service Ticket and delegated TGT are returned.
19. SAS Logon Manager sends a Kerberos HTTP response to the sas-krb5-proxy sidecar.
20. The sas-krb5-proxy sidecar uses the long-term key for the principal from the Kerberos keytab to accept the Kerberos HTTP response from SAS Logon Manager. Decrypting the Service Ticket enables the sas-krb5-proxy to access the delegated TGT. The sas-krb5-proxy streams the delegated 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 Unconstrained Delegation: SAS Cloud Analytic Services – Direct Connection

In this use-case the end-user in SAS 9.4 Maintenance 5 or higher has authenticated through SAS 9.4 using Kerberos constrained delegation and then connection to SAS Cloud Analytic Services.

The steps are as follows:

1. CAS Client (SAS 9.4 M5 and higher, or third-party programming language) makes a direct connection to SAS Cloud Analytic Services. Since the CAS Client is not provided with a username/password, an authinfo file, or existing ACCESS Token the CAS Client initializes a Kerberos connection to CAS. The initialization of the Kerberos connection requires a Service Ticket.
2. CAS Client triggers OS request for a Service Ticket for CAS from the KDC leveraging the existing Ticket-Granting Ticket (TGT) of the end-user. Since the principal is trusted for delegation to any service a delegated Ticket-Granting Ticket (TGT) is also returned by the KDC.
3. The CAS Client submits the Service Ticket as part of the Kerberos authentication request to CAS.
4. CAS uses the long-term key of the service principal, provided in the Kerberos keytab to decrypt the service ticket. This authenticates the end-user to CAS using Kerberos.
5. CAS uses the delegated TGT to request a Service Ticket from the KDC for a Kerberos connection to SAS Logon Manager. Since the service principal is trusted for delegation to any service a delegated TGT is also returned by the KDC.
6. CAS uses Kerberos to authenticate to SAS Logon Manager.
7. SAS Logon Manager uses the long-term key for the HTTP Service Principal, obtained from the Kerberos keytab, to decrypt the Service Ticket and extract the authenticator information. This includes the end-user’s UPN and authenticates the end-user to SAS Logon Manager.
8. SAS Logon Manager stores the delegated TGT with the Credentials microservice. SAS Logon Manager connects with its own client credentials to the Credentials microservice. Further access to the delegated TGT is controlled by access controls; only by presenting the end-user’s ACCESS Token can the delegated TGT be retrieved.
9. The Credentials microservice stores the delegated TGT within the database, which could be Crunchy Data PostgreSQL or Azure PostgreSQL. The Credentials microservice encrypts the data before it is written to the database.
10. SAS Logon Manager strips the realm from the UPN and submits the username to the Identities microservice to obtain the group information.
11. The Identities microservice queries the group information from the LDAP provider.
12. The Identities microservice responds to SAS Logon Manager with the group information.
13. SAS Logon Manager responds to CAS with the ACCESS Token for the end-user.
14. CAS uses the ACCESS Token for the end-user to request the user attributes (UID, GID, and secondary GIDs) from the Identities microservice. CAS uses the user attributes to write out the Kerberos ticket cache using the default name format and launches the CAS session for the end-user.

Conclusion

In the first two use-cases we can see the important role of the SAS Kerberos Proxy sidecar container. This is responsible for making the Kerberos credentials available to either the SAS Compute Server session or the SAS Cloud Analytic Services session. Unlike previous releases Kerberos is not used to authenticate the end-user to the SAS Compute Server or to SAS Cloud Analytic Services. Instead the Viya ACCESS Token generated by authenticating to SAS Logon Manager is used. We can see that this will greatly simplify the prerequisites the customer will need to setup in advance since we will only have a single Kerberos principal to be concerned with.

The direct connection to SAS Cloud Analytic Services behaves more like previous releases. But we must set the CASSPN option in the client code to HTTP@{{Viya4SPNHost}} to specify the different SPN for connecting to CAS. For example, this can be set with the following:

options set=CASSPN='HTTP@{{Viya4SPNHost}}'; 

Then the processing that CAS carries out is no different for constrained or unconstrained delegation.

Find more articles from SAS Global Enablement and Learning here.