Stuart Rogers

2月 152018

In this article, I will set out clear principles for how SAS Viya 3.3 will interoperate with Kerberos. My aim is to present some overview concepts for how we can use Kerberos authentication with SAS Viya 3.3. We will look at both SAS Viya 3.3 clients and SAS 9.4M5 clents. In future blog posts, we’ll examine some of these use cases in more detail.

With SAS Viya 3.3 clients we have different use cases for how we can use Kerberos with the environment. In the first case, we use Kerberos delegation throughout the environment.

Use Case 1 – SAS Viya 3.3

The diagram below illustrates the use case where Kerberos delegation is used into, within, and out from the environment.

How SAS Viya 3.3 will interoperate with Kerberos

In this diagram, we show the end-user relying on Kerberos or Integrated Windows Authentication to log onto the SAS Logon Manager as part of their access to the visual interfaces. SAS Logon Manager is provided with a Kerberos keytab and HTTP principal to enable the Kerberos connection. In addition, the HTTP principal is flagged as “trusted for delegation” so that the credentials sent by the client include the delegated or forwardable Ticket-Granting Ticket (TGT). The configuration of SAS Logon Manager with SAS Viya 3.3 includes a new option to store this delegated credential. The delegated credential is stored in the credentials microservice, and secured so that only the end-user to which the credential belongs can access it.

When the end-user accesses SAS CAS from the visual interfaces the initial authentication takes place with the standard internal OAuth token. However, since the end-user stored a delegated credential when accessing the SAS Logon Manager an additional Origin attribute is set on the token of “Kerberos.” The internal OAuth token also contains the groups the end-user is a member of within the Claims. Since we want this end-user to run the SAS CAS session as themselves they must have been added to a custom group with the ID=CASHostAccountRequired. When the SAS CAS Controller receives the OAuth token with the additional Kerberos Origin, it requests the visual interface to make a second Kerberized connection. So, the visual interface retrieves the delegated credential from the credentials microservice and uses this to request a Service Ticket to connect to SAS CAS.

SAS CAS has been provided with a Kerberos keytab and a sascas principal to enable the Kerberos connection. Since the sascas principal is flagged as “trusted for delegation,” the credentials sent by the visual interfaces include a delegated or forwardable Ticket-Granting Ticket (TGT). SAS CAS validates the Service Ticket, which in turn authenticates the end-user. The SAS CAS Controller then launches the session as the end-user and constructs a Kerberos ticket cache containing the delegated TGT. Now, within their SAS CAS session the end-user can connect to the Secured Hadoop environment as themselves since the SAS CAS session has access to a TGT for the end-user.

This means in this first use case all access to, within, and out from the SAS Viya 3.3 environment leverages strong Kerberos authentication. This is our “gold-standard” for authenticating the end-user to each part of the environment.

But, it is strictly dependent on the end-user being a member of the custom group with ID=CASHostAccountRequired, and the two principals (HTTP and sascas) being trusted for delegation. Without both the Kerberos delegation will not take place.

Use Case 1a – SAS Viya 3.3

The diagram below illustrates a slight deviation on the first use case.

Here, either through choice or by omission, the end-user is not a member of the custom group with the ID=CASHostAccountRequired. Now even though the end-user connects with Kerberos and irrespective of the configuration of SAS Logon Manager to store delegated credentials the second connection using Kerberos is not made to SAS CAS. Now the SAS CAS session runs as the account that launched the SAS CAS controller, cas by default. Since, the session is not running as the end-user and SAS CAS did not receive a Kerberos connection, the Kerberos ticket cache that is generated for the session does not contain the credentials of the end-user. Instead, the Kerberos keytab and principal supplied to SAS CAS are used to establish the credentials in the Kerberos ticket cache.

This means that even though Kerberos was used to connect to SAS Logon Manager the connection to the Secured Hadoop environment is as the sascas principal and not the end-user.

The same situation could be arrived at if the HTTP principal for SAS Logon Manager is not trusted for delegation.

Use Case 1b – SAS Viya 3.3

A final deviation to the initial use case is shown in the following diagram.

In this case the end-user connects to SAS Logon Manager with any other form of authentication. This could be the default LDAP authentication, external OAuth, or external SAML authentication. Just as in use case 1a, this means that the connection to SAS CAS from the visual interfaces only uses the internal OAuth token. Again, since no delegated credentials are used to connect to SAS CAS the session is run as the account that launched the SAS CAS controller. Also, the ticket cache created by the SAS Cloud Analytic Service Controller contains the credentials from the Kerberos keytab, i.e. the sascas principal. This means that access to the Secured Hadoop environment is as the sascas principal and not the end-user.

Use Case 2 – SAS Viya 3.3

Our second use case covers those users entering the environment via the programming interfaces, for example SAS Studio. In this case, the end-users have entered a username and password, a credential set, into SAS Studio. This credential set is used to start their individual SAS Workspace Session and to connect to SAS CAS from the SAS Workspace Server. This is illustrated in the following figure.

Since the end-users are providing their username and password to SAS CAS it behaves differently. SAS CAS uses its own Pluggable Authentication Modules (PAM) configuration to validate the end-user’s credentials and hence launch the SAS CAS session process running as the end-user. However, in addition the SAS CAS Controller also uses the username and password to obtain an OAuth token from SAS Logon Manager and then can obtain any access control information from the SAS Viya 3.3 microservices. Obtaining the OAuth token from the SAS Logon Manager ensures any restrictions or global caslibs defined in the visual interfaces are observed in the programming interfaces.

With the SAS CAS session running as the end-user and any access controls validated, the SAS CAS session can access the Secured Hadoop cluster. Now since the SAS CAS session was launched using the PAM configuration, the Kerberos credentials used to access Hadoop will be those of the end-user. This means the PAM configuration on the machines hosting SAS CAS must be linked to Kerberos. This PAM configuration then ensures the Kerberos Ticket-Granting Ticket is available to the CAS Session as is it launched.

Next, we consider three further use cases where the client is SAS 9.4 maintenance 5. Remember that SAS 9.4 maintenance 5 can make a direct connection to SAS CAS without requiring SAS/CONNECT. The use cases we will discuss will illustrate the example with a SAS 9.4 maintenance 5 web application, such as SAS Studio. However, the statements and basic flows remain the same if the SAS 9.4 maintenance 5 client is a desktop application like SAS Enterprise Guide.

Use Case 3 – SAS 9.4 maintenance 5

First, let’s consider the case where our SAS 9.4 maintenance 5 end-user enters their username and password to access the SAS 9.4 environment. This is illustrated in the following diagram.

In this case, since the SAS 9.4 Workspace Server is launched using a username and password, these are cached on the launch of the process. This enables the SAS 9.4 Workspace Server to use these cached credentials when connecting to SAS CAS. However, the same process occurs if instead of the cached credentials being provided by the launching process, they are provided by another mechanism. These credentials could be provided from SAS 9.4 Metadata Server or from an authinfo file in the user’s home directory on the SAS 9.4 environment. In any case, the process on the SAS Cloud Analytic Server Controller is the same.

The username and password used to connect are validated through the PAM stack on the SAS CAS Controller, as well as being used to generate an internal OAuth token from the SAS Viya 3.3 Logon Manager. The PAM stack, just as in the SAS Viya 3.3 programming interface use case 2 above, is responsible for initializing the Kerberos credentials for the end-user. These Kerberos credentials are placed into a Kerberos Ticket cache which makes them available to the SAS CAS session for the connection to the Secured Hadoop environment. Therefore, all the different sessions within SAS 9.4, SAS Viya 3.3, and the Secured Hadoop environment run as the end-user.

Use Case 4 – SAS 9.4 maintenance 5

Now what about the case where the SAS 9.4 maintenance 5 environment is configured for Kerberos authentication throughout. The case where we have Kerberos delegation configured in SAS 9.4 is shown here.

Here the SAS 9.4 Workspace Server is launched with Kerberos credentials, the Service Principal for the SAS 9.4 Object Spawner will need to be trusted for delegation. This means that a Kerberos credential for the end-user is available to the SAS 9.4 Workspace Server. The SAS 9.4 Workspace Server can use this end-user Kerberos credential to request a Service Ticket for the connection to SAS CAS. SAS CAS is provided with a Kerberos keytab and principal it can use to validate this Service Ticket. Validating the Service Ticket authenticates the SAS 9.4 end-user to SAS CAS. The principal for SAS CAS must also be trusted for delegation. We need the SAS CAS session to have access to the Kerberos credentials of the SAS 9.4 end-user.

These Kerberos credentials made available to the SAS CAS are used for two purposes. First, they are used to make a Kerberized connection to the SAS Viya Logon Manager, this is to obtain the SAS Viya internal OAuth token. Therefore, the SAS Viya Logon Manager must be configured to accept Kerberos connections. Second, the Kerberos credentials of the SAS 9.4 end-user are used to connect to the Secure Hadoop environment.

In this case since all the various principals are trusted for delegation, our SAS 9.4 end-user can perform multiple authentication hops using Kerberos with each component. This means that through the use of Kerberos authentication the SAS 9.4 end-user is authenticated into SAS CAS and out to the Secure Hadoop environment.

Use Case 5 – SAS 9.4 maintenance 5

Finally, what about cases where the SAS 9.4 maintenance 5 session is not running as the end-user but as a launch credential; this is illustrated here.

The SAS 9.4 session in this case could be a SAS Stored Process Server, Pooled Workspace Server, or a SAS Workspace server leveraging a launch credential such as sassrv. The key point being that now the SAS 9.4 session is not running as the end-user and has no access to the end-user credentials. In this case we can still connect to SAS CAS and from there out to the Secured Hadoop environment. However, this requires some additional configuration. This setup will leverage One-Time-Passwords generated by the SAS 9.4 Metadata Server, so the SAS 9.4 Metadata Server must be made aware of the SAS CAS. This is done by adding a SAS 9.4 metadata definition for the SAS CAS. Our connection from SAS 9.4 must then be “metadata aware,” achieved by using authdomain=_sasmeta_ on the connection.

Equally, the SAS Viya 3.3 side of the environment must be able to validate the One-Time-Password used to connect to SAS CAS. When SAS CAS receives the One-Time-Password on the connection, it is sent to the SAS Viya Logon Manager for validation and to obtain a SAS Viya internal OAuth token. We need to add some configuration to the SAS Viya Logon Manager to enable this to validate the One-Time-Password. We configured the SAS Viya Logon Manager with the details of where the SAS 9.4 Web Infrastructure Platform is running. The SAS Viya Logon Manager passes the One-Time-Password to the SAS 9.4 Web Infrastructure Platform to validate the One-Time-Password. After the One-Time-Password is validated a SAS Viya internal OAuth token is generated and passed back to SAS CAS.

Since SAS CAS does not have access to the end-user credentials, the session that is created will be run using the account used to launch the controller process, cas by default. Since the end-user credentials are not available, the Kerberos credentials that are initialized for the session are from the Kerberos keytab provided to SAS CAS. Then the connection to the Secured Hadoop environment will be made using those Kerberos credentials of the principal assigned to the SAS CAS.


We have presented several use cases above. The table below can be used to summarize and differentiate the use cases based on key factors.

SAS Viya 3.3 - Some Kerberos principles was published on SAS Users.

1月 172018

In this article, I want to give you an overview of the authentication options available with SAS Viya 3.3. SAS Viya 3.3, released in the second week of December 2017, and the second release with the new microservices architecture, presents more options for authentication than the previous releases. In future posts, we will delve in to more detail for a select option.

Types of Deployment

Before we look at the options for authentication we need to define some terms to help us describe the type of environment. The first of these is the type of deployment. With SAS Viya 3.3 we can have two different types of deployment:

  1. Full Deployment
  2. Programming Only

As the name suggests, the full deployment is a deployment of all the different components that make up the ordered SAS Viya 3.3 product or solution. This includes the SAS Viya runtime engine, CAS (Cloud Analytic Services), the microservices, stateful services, and foundation components used by SAS® Studio.

The programming only deployment more closely resembles the deployment we saw in an earlier release; so, this includes CAS and all the parts for SAS Studio to function. A programming only deployment does not include the microservices and stateful services. The only interaction with CAS is via SAS Studio and the code end-users run within this.

Types of Interfaces

Following on from the type of deployment, we can classify the end-user interfaces used to access SAS Viya 3.3.  The interface could be a visual interface or a programming interface. For a visual interface, we group all the SAS Viya 3.3 web applications, excluding SAS Studio. For a programming interface we mean SAS Studio. Equally within programming interface, when we say a programming interface accesses CAS we could also mean the Python, Lua, R or Java interfaces.

Similarly, as of the fifth maintenance release of SAS 9.4 we can interact directly with CAS. Previously, this interaction was based around the use of SAS/CONNECT® and remote submitting code to the SAS Viya programming interface. With SAS 9.4 M5, we can now directly connect to CAS from the SAS foundation. So, a third type of interface for us to consider is the SAS 9.4 M5 client.

Visual Interfaces Authentication

As we know with SAS Viya 3.3, the way the end-user authenticates to the visual interfaces is via the SAS® Logon Manager. The SAS Logon Manager is accessed via the HTTP Proxy. The following picture summarizes the options for authenticated to the SAS Logon Manager in SAS Viya 3.3.

SAS Viya 3.3 authentication options

The first thing to point out and something to always remember is the following:

The identities microservice always must connect to an LDAP provider to obtain user and group information.

This LDAP provider could be Microsoft Active Directory or any other LDAP provider such as OpenLDAP.

So, what are our options for authenticating the users accessing SAS Logon Manager? We have five options with the SAS Viya 3.3:

1.      LDAP Provider (the default option)
2.      Kerberos or Integrated Windows Authentication
3.      OAuth/OpenID Connect
4.      SAML
5.      Multi-factor Authentication (New with SAS Viya 3.3)

Option 1 is the default authentication mechanism enabled out-of-the-box for SAS Viya 3.3 is the LDAP Provider. The same connection details used by the identities microservice are used by SAS Logon Manager to authenticate the credentials the end-user enters in the logon form. From a security perspective, we need to be concerned about what network connections these end-user credentials will be sent over. First, we have the network connection between the browser and the HTTP proxy, which is secured by default with HTTPS in SAS Viya 3.3. Then we have the network connection between SAS Logon and the LDAP Provider, here we can support LDAPS to encapsulate the LDAP connection in standard TLS encryption.

Option 2, as shown in the diagram, is to configure SAS Logon Manager for Kerberos authentication. This provides the end-user with Single Sign-On from their desktop where the browser is running. This is sometimes referred to as Integrated Windows Authentication (IWA). This will enable the end-user to access the SAS Viya 3.3 visual interfaces without being prompted to enter any credentials. However, it is important to remember that the identities microservice will still be connecting to the LDAP provider. The Kerberos authentication option completely replaces the option to use the default LDAP provider for the SAS Logon Manager. Introduced with SAS Viya 3.3 is the option to delegate the credentials from SAS Logon Manager through to CAS; more on this option below.

Option 3 enables the SAS Logon Manager to be integrated with an alternative OAuth/OpenID Connect provider. This provider could be something internal to the customer’s wider environment or could be external to the customer, such as Google Auth of Facebook. When the OAuth/OpenID Connect option is configured this does not completely replace the default LDAP provider. Instead when the end-user accesses the SAS Logon Manager they are presented with a link to authenticate using OAuth/OpenID Connect and the standard login form using the LDAP provider. The end-user can then select which to use. This option can provide single sign-on from the OAuth/OpenID Connect provider;for example, sign into your Google account and access the SAS Viya 3.3 visual interfaces without further prompting for credentials. Custom code can be added to the SAS Logon Manager login form that automatically links to the external OAuth/OpenID Connect provider. This makes the single sign-on more seamless, since there is no need to select the link.

Option 4 supports configuring the SAS Logon Manager to be integrated with an external SAML Identity Provider. This SAML Identity Provider could be internal or external to the customer’s wider environment. If it is internal it could be something like Oracle Access Manager or Active Directory Federation Services, whilst if its external it could be something like Again, like option 3, the use of SAML does not completely replace the default LDAP provider. End-users accessing the SAS Logon Manager will be able to choose SAML authentication or the default LDAP provider. Also, this option provides single sign-on with the third-party SAML provider. Custom code can be added to the SAS Logon Manager login form that automatically links to the external SAML provider, making the single sign-on more seamless, since there is no need to select the link.

Option 5 supports the use of Multi-factor authentication with SAS Logon Manager. This is a new option (with SAS Viya 3.3) and requires the configuration of a third-party Pluggable Authentication Module (PAM). This PAM module is the part of the system that integrates with the multi-factor authentication provider such as Symantec’s VIP. The PAM module authenticates the end-user by causing the third-party to push an out-of-band validation request to the end-user. Normally, this would be a push message to a smart phone application, approving the request forms the additional factor in the authentication of the end-user. When an end-user enters their username and password in the SAS Logon Manager form they are checked against the PAM provider. This means this option replaces the LDAP provider, just as with Kerberos.

For all five options listed above, the connection to CAS is performed using internal OAuth tokens generated by the SAS Logon Manager. In most cases the actual session started by the CAS Controller will now run on the operating system as the same user who launched the CAS operating system service. This account defaults to the name cas.

The exception to this is Option 2: Kerberos with delegation. In this case while an OAuth token is generated and initially used to connect to CAS  a second authentication takes place with the delegated Kerberos credentials. This means that the CAS session is started as the end-user and not the user who launched the CAS operating system service.

Programming Interfaces Authentication

Now we’ve looked at the visual interfaces for SAS Viya 3.3, what about the programming interfaces or SAS Studio? Unlike SAS 9.4, SAS Studio with SAS Viya 3.3 is not integrated with the SAS Logon Manager. The following diagram illustrates the case with SAS Studio.

SAS Viya 3.3 authentication options

SAS Studio in the full deployment is integrated with the HTTP Proxy, so with SAS Viya 3.3 end-users do not directly connect to the SAS Studio web application. However, the username and password entered into SAS Studio are not passed to the SAS Logon Manager to authenticate. Instead the SAS® Object Spawner uses the PAM configuration on the host to validate the username and password. This could be a local account on the host or, depending on the PAM configuration, an account in an LDAP Provider. This authentication is sufficient to start the SAS® Workspace Server where the code entered in SAS Studio will be run.

When the SAS Workspace Server connects to CAS it uses the username and password that were used to start the SAS Workspace Server. The CAS Controller uses its own PAM configuration to validate the end-user’s credentials and launch the session process running as the end-user.

Since CAS is integrated into the visual components, and the username and password are passed from the SAS Workspace Server, the CAS Controller uses them to obtain an internal OAuth token from the SAS Logon Manager. This means that the username and password must be valid in the provider configured for the SAS Logon Manager otherwise CAS will not be able to obtain an OAuth token and the session launch will fail.

Therefore, it makes sense in such a deployment for all the three components:

1.      PAM for SAS Studio (sasauth*)
2.      PAM for CAS (cas)
3.      SAS Logon Manager

to all use the same LDAP Provider. If these three components are not sending the username and password entered in SAS Studio to the same place we are likely to see errors when trying to connect.

Programming Only Deployment

For a programming only deployment, we have SAS Studio and CAS but we don’t have any microservices or stateful services. So here all authentication is via the PAM configuration for SAS Studio and CAS. Since CAS knows there are no microservices, it does not attempt to obtain an internal OAuth token from the SAS Logon Manager, the same type of setup we had for SAS Viya 3.1.

SAS 9.4 Maintenance 5 Integration

There are three main ways in which SAS 9.4 Maintenance 5 can integrate with CAS. First, if the SAS 9.4 M5 session has access to a Kerberos credential for the end-user, then Kerberos can be used for the authentication. For example, if Kerberos is used by the end-user to access the SAS 9.4 M5 client, such as a web application or SAS Enterprise Guide, the authentication can be delegated all the way through to CAS. Kerberos will then be used to authenticate to SAS Viya Logon Manager and obtain an OAuth token.

Second, if the SAS 9.4 M5 session has access to the end-user’s username and password; either from the cached credentials used to launch the session, an authinfo file, or from SAS 9.4 Metadata, then these credentials can be used to authenticate to CAS. The username and password will be used to launch the CAS and obtain an OAuth token from SAS Viya Logon Manager. This will be like the programming approach we detailed above.

Finally, for SAS 9.4 Maintenance 5 sessions which are not running as the end-user, we also have a solution. These sessions could be SAS® Stored Process or Pooled Workspace Server sessions, or even a SAS token launched workspace server. For these sessions, we can leverage the SAS® 9.4 Metadata Server to generate a one-time-password. This is the same way in which the SAS Stored Process itself is accessed. To be able to leverage the One-Time-Password with CAS, additional configuration is required in SAS Viya Logon Manager. SAS Viya Logon Manager must be configured with the details of the location of the URL for the SAS® 9.4 Web Infrastructure Platform. The services in the SAS 9.4 Web Infrastructure Platform will be used to validate the One-Time-Password. All this means that CAS can be accessed from a SAS 9.4 Metadata aware connection where end-user Operating System credentials are not available.


I hope that this overview has provided some context to the different types of authentication happening within and to a SAS Viya 3.3 deployment. Understanding the types of authentication available will be important for helping customers to select the best options for them. In future blog posts, we’ll look at the different new options in more detail.

SAS Viya 3.3 authentication options was published on SAS Users.

7月 312015

SecurityEncryption and SAS is a wide ranging topic – so wide it gets its own book and features strongly in both the SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition and SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Third Edition. In this blog we’ll take a high level look at what is involved in using HTTPS encryption in-transit within a SAS deployment.

This blog will provide an overview of considerations when designing for security requirements that include encryption and will be the first in a series of blog discussions around encryption.

Why use encryption?

Many customers both from a business and IT perspective are becoming more concerned about encryption. For some, this concern comes from industry regulation (think here of the banking sector). For many others, the sheer number of news stories about data breaches and the costs to business are raising the priority of encryption. We are definitely moving towards a world where the default is to encrypt.

This greater focus on security in general can be seen here at SAS as well. We have the Security Assurance page on and the associated SAS® Software Security Framework. We also have a place for security bulletins on

One aspect of security that is becoming more and more common for SAS customers is the use of encryption for data in-transit. Customers’ are either externalizing resources, making them available to the wider internet, moving towards cloud based deployment models, or even becoming more concerned over network security within their own organizations.


Does that mean it’s in a van? Nope – what we mean when we say data in-transit is that it is data passing from one process to another. The end points might be on the same host or on different hosts. For encryption, we split the topic into two areas: data being transmitted or in-transit, and data sitting in a file or database, so at-rest. Whilst many principles of encryption apply to either data in-transit or at-rest, most methods of applying encryption are different depending on whether the data is at-rest or in-transit.

The most common use of encryption for data in-transit is to wrap encryption around traditional HTTP transmissions. The move away from using HTTP as a default and defaulting to secure HTTP (HTTPS) can be seen in many areas of the World Wide Web. We expect our webmail or banking systems to encrypt the traffic from the browser to the server by using HTTPS, but this is now starting to extend through to many other sites as concerns over confidentiality spread. Google, Facebook, and even Wikipedia now use HTTPS as the default rather than HTTP.


The expectation is that you can use HTTPS to replace HTTP connections. So, let’s highlight the use of HTTPS within a typical SAS deployment.


Most SAS administrators and security professionals will expect several items on this diagram. Obviously, if a customer is asking for HTTPS we would expect to see the SAS Web Server called out along with the browser based clients. Some of the other SAS components that need to communicate over HTTPS might not be so obvious.

  • The SAS Environment Manager Server includes a web application server that can be configured for HTTPS on the default port of 7443.
  • The SAS Web Application Server instances can also be configured for HTTPS instead of the default HTTP. There might be multiple instances of the SAS Web Application Server deployed to support scalability and redundancy of the SAS web applications. With multiple instances, the proven practice is to configure the connections for each instance in the same way, either with HTTP or HTTPS.
  • Clients such as SAS Management Console can make connections to the SAS Content Server and will need to communicate over HTTPS if the SAS Web Server is configured for HTTPS.
  • The analytical clients like SAS Enterprise Miner & SAS Forecast Studio make all their connections to the server tier via the middle-tier and are built to enable HTTPS communication, but this must be configured.
  • The SAS Application Servers, such as Workspace Servers are also clients of the middle-tier for actions such as publishing to WebDAV, interacting with the LASR Authorization Service and components like the SAS Information Retrieval Studio.

What this illustrates is that just the requirement of having encryption for the SAS Middle-Tier i.e. HTTPS connections to the SAS Web Server can be quite complex, and requires understanding the interactions of the different components.

Setting up complete use of HTTPS requires a mixture of automatic and manual configuration. More details of these configuration steps can be found in the SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Third Edition. The options for how to configure the components to use HTTPS vary, and need to be managed carefully. The SAS Deployment Wizard is able to configure HTTPS with the SAS Web Server and SAS Environment Manager Server but does not configure the SAS Web Application Server.

Where does it end?

Important questions for the use of HTTPS with the middle-tier include: Just where does it end? How far do you want the encryption to go? Is it important to encrypt everything or just to encrypt the traffic to and from the SAS Web Server? The diagram below illustrates encrypting all the way through the middle-tier.


One issue which can impact on how far you carry the encryption is that of secure cookies. If you have a requirement to secure the cookies used in the environment, then you need to configure HTTPS for all the connections to and from SAS Web Server and SAS Web Application Server.

Who do you trust?

In addition to working out which components you need to configure for HTTPS, you also need to think about trust. The client, even if that client is a SAS Workspace session, needs to be able to trust the certificate presented by a server. Trust in the case of HTTPS means that the client must be able to “know” or “trust” who validated or signed the server certificate. When the client trusts the validator, it can then trust that the server is who it claims to be. So the client is able to trust that the bank is really the bank and not someone pretending to be the bank.

If you’ve gone with site-signed, self-signed, or even some third-party signed certificates, how do you tell the clients to trust them? You are not going to see a pop-up message from a remote Workspace session asking you if you are sure you want to trust the certificate, in the way a browser prompts the user as shown here:


Separate configuration steps need to be taken to make this trust automatic. This is an area where administrators can run into problems when implementing HTTPS. The issues of trust are important enough to warrant their own posting, so look out for my next blog where we’ll discuss trust in more detail.


Hopefully, this blog posting has given you a high level feeling for the considerations that can be involved in deploying some encryption technologies in your environment. Remember this blog only touched on the subject of TLS with the SAS Middle-Tier. Encryption for other parts of a SAS environment are provided with SAS/SECURE which is included with all SAS deployments (unless prohibited by import/export restrictions). I encourage you to review the Encryption in SAS® 9.4, Fifth Edition book and start to explore what is required for installing and configuring TLS and certificates. More implementation details can be found in in both the SAS(R) 9.4 Intelligence Platform: Security Administration Guide, Second Edition and SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Third Edition.

Look out for my next blog where we’ll look at issues around trust in a little more detail.

tags: encryption, SAS Administrators, security

SAS 9.4: Transport Layer Security (HTTPS) and SAS was published on SAS Users.

10月 152014

hadoop-HPAIn this post we dig deeper into the fourth recommended practice for securing the SAS-Hadoop environment through Kerberos authentication:

When configuring SAS and Hadoop jointly in a high-performance environment, ensure that all SAS servers are recognized by Kerberos.

Before explaining the complex steps in connecting to secure Hadoop within a SAS High-Performance Analytics environment such as SAS Visual Analytics, let’s start by reviewing a simpler connection from a standard SAS session through SAS/ACCESS for Hadoop.

Making connections in a standard SAS session

Hadoop_standard_thumbnailHere's a behind-the-scenes look at the steps involved in the connection. Click on the thumbnail to view the full diagram. This graphic depicts an environment where the SAS Servers are configured to authenticate the users with the same back-end directory server as the Hadoop instance. The setup is relatively straight-forward.

Let’s say a SAS user (we’ll call this user Mary) logs into her machine, and the standard Windows logon procedure obtains the Ticket-Granting Ticket (TGT) from the main corporate Active Directory. This step happens on all domain machines: Kerberos is tied into the standard deployment of Active Directory. Also, this step is completely isolated from Mary’s access to SAS.

At some later point in the day (perhaps after grabbing her morning cup of coffee!), Mary may open SAS Enterprise Guide. As we know, starting the SAS session makes a connection to the SAS Metadata Server, and her credentials (username and password) in the connection profile are authenticated by the Metadata Server. As we noted in previous posts, the SAS servers have been configured to use the same directory server as Hadoop, so this authentication step uses Pluggable Authentication Modules (PAM) to validate our user.

Next, SAS Enterprise Guide initiates Mary’s Workspace Session by connecting to the Object Spawner. The Object Spawner runs a shell script ( as “Mary” and spawns the Workspace Session. In this step, as her credentials are authenticated, the PAM stack on the server obtains a Ticket-Granting Ticket (TGT) for Mary. This TGT is going to be placed in her Ticket Cache, ready to be made use of later.

To Mary, all of this has happened as SAS Enterprise Guide was opened. She has not been required to perform any special actions to get to this stage. All the “magic” has been taking place behind the curtain.

So Mary can submit her SAS code to connect to Hadoop using the standard LIBNAME statement with the required options. (Remember username and password are not valid when connecting using Kerberos. They specify the Kerberos security principals instead.) Also as discussed last time, the step for connecting to Hadoop in a SAS session can be moved behind the curtain by ensuring the principals are in the configuration file used to make the connection to Hadoop. The Hadoop client libraries then use the TGT to request the Service Tickets for HIVE and/or HDFS, and SAS makes the connection to Hadoop using the Service Tickets. Our SAS user Mary is authenticated on the Hadoop side by validating the Service Tickets provided in the connection.

How connections are made in a SAS High-Performance Analytics session

Hadoop_HPA_thumbnailSo, this is the setup in a standard SAS session. What now happens if the environment uses something like SAS High-Performance Analytics or SAS Visual Analytics to make the connection to the secured Hadoop environment? Let’s look at the steps involved if our SAS user Mary wants to make a connection to SAS Visual Analytics. Click on the thumbnail to view a larger graphic showing these steps. Wow – that looks a bit more complicated under the covers! We’ll start with understanding how the connections are made and then look at some of the configuration options.

So, the starting points in this process are the same as before. We have the same steps occurring up to making the connection to Hadoop (step 7 in the diagram.) At this point, we’ll want to explore a little more detail about the connection that is made by the LIBNAME statement in Mary’s SAS code.

What wasn’t necessary to know when connecting with a standard SAS session is the fact that the XML configuration file is actually written to a temporary location in HDFS when Mary connects to Hadoop from SAS. This XML file will be used later by the distributed processes in the SAS High-Performance Analytics environment.

After submitting the LIBNAME statement to connect to Hadoop, Mary must now submits a PROC LASR or HP PROC statement to access the high-performance environment. Submitting these procedures initiates the SSH connection from the Workspace Session to the SASHigh-Performance Analytics Environment. Since Mary needs her SAS High Performance Analytics session to be Kerberos-aware, the SSH connection must be made using Kerberos. At this point, the SSH client uses the TGT to obtain a Service Ticket for HOST on the HPA General or LASR Root Node. SAS then uses the SSH client to start the HPA General and passes details of how to connect to HDFS.

The SSH Daemon (a server process running on the HPA General) generates a TGT for Mary on the HPA General as part of authenticating her credentials. This TGT on the HPA General is then used to request Service Tickets for all the worker nodes, and the parallel SSH connections are made to initialize the HPA Captains. With the HPA processes now running, the HPA General initiates the connection to Hadoop using the TGT—this time to request service tickets for HDFS and HIVE.

The HPA General connects to HDFS to retrieve the XML file placed there by the LIBNAME statement. Our SAS user Mary is authenticated using the Service Ticket for HDFS. The HPA General now submits a Map Reduce job. This Map Reduce job initiates the SAS Embedded Process (EP) running on the Hadoop nodes. The SAS Embedded Process connects first to the HPA General and then makes connections to the assigned HPA Captains using UNIX sockets. This process is not authenticated since the two sets of processes were already authenticated.

The SAS Embedded Process runs as a standard MapReduce job and has corresponding MapReduce tasks running on each node of the Hadoop environment. The MapReduce tasks connect as necessary to HDFS and HIVE using the standard Hadoop internal tokens. These tokens are used by the tasks of a MapReduce job rather than Kerberos tickets. More details about these internals of the Hadoop system can be found in the Hortonworks Technical Report:  Adding Security to Apache Hadoop. Each SAS Embedded Process then passes the data back and forth in parallel as required by the HPA processes.

Configuration requirements for SAS High-Performance Analytics

So while the diagram looks complicated, I believe we can distill this down into the following two requirements:

  1. The SAS Workspace Server must still have access to the users TGT.
  2. HPA General or LASR Root Node must have access to the users TGT.

The simplest method of ensuring that both the SAS Workspace Server and the HPA General or LASR Root Node have access to the user’s TGT is to configure SSH to use Kerberos and to ensure the following options are set.

GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Setting these options on all SAS High-Performance Analytics Environment machines should ensure all SSH connections made using Kerberos will have a valid TGT obtained for each open session. Remember for SSH to use Kerberos, the HOST Service Principal must be registered in the Kerberos Key Distribution Center and the HOST keytab must be available on each machine (normally stored in /etc/krb5.keytab).

If you have questions about configuring SAS High-Performance Analytics to access a Kerberos-authenticated Hadoop environment or have other suggestion, please share them in the comment area below.

tags: Hadoop, Kerberos, SAS Administrators, security
10月 092014

hadoop-config1understanding the fundamentals of Kerberos authentication and how we can simplify processes by placing SAS and Hadoop in the same realm. For SAS applications to interact with a secure Hadoop environment, we must address the third key practice:

Ensure Kerberos prerequisites are met when installing and configuring SAS applications that interact with Hadoop.

The prerequisites must be met during installation and deployment of SAS software, specifically SAS/ACCESS Interface to Hadoop for SAS 9.4.

1) Make the correct versions of the Hadoop JAR files available to SAS.

If you’ve installed other SAS/ACCESS products before, you’ll find installing SAS/ACCESS Interface for Hadoop is different. For other SAS/ACCESS products, you generally install the RDBMS client application and then make parts of this client available via the LD_LIBRARY_PATH environment variable.

With SAS/ACCESS to Hadoop, the client is essentially a collection of JAR files. When you access Hadoop through SAS/ACCESS to Hadoop, these JAR files are loaded into memory. The SAS Foundation interacts with Java through the jproxy process, which loads the Hadoop JAR files.

You will find the instructions for copying the required Hadoop JAR files and setting the SAS_HADOOP_JAR_PATH environment variable in the following product documentation:

2) Make the appropriate configuration files available to SAS.

The configuration for the Hadoop client is provided via XML files. The cluster configuration is updated when Kerberos is enabled for the Hadoop cluster and you must remember to update the cluster configuration files when this is enabled.  The XML files contain properties specific to security, and the files required depend on the version of MapReduce being used in the Hadoop cluster. When Kerberos is enabled, it’s required that these XML configuration files contain all the appropriate options for SAS and Hadoop to properly connect.

  • If you are using MapReduce 1, you need the Hadoop core, Hadoop HDFS, and MapReduce configuration files.
  • If you are using MapReduce 2, you need the Hadoop core, Hadoop HDFS, MapReduce 2, and YARN configuration files.

The files are placed in a directory available to SAS Foundation and this location is set via the SAS_HADOOP_CONFIG_PATH environment variable.  The SAS® 9.4 Hadoop Configuration Guide for Base SAS® and SAS/ACCESS® describes how to make the cluster configuration files available to SAS Foundation.

3) Make the user’s Kerberos credentials available to SAS.

The SAS process will need to have access to the user’s Kerberos credentials for it to make a successful connection to the Hadoop cluster.  There are two different ways this can be achieved, but essentially SAS requires access to the user’s Kerberos Ticket-Granting-Ticket (TGT) via the Kerberos Ticket Cache.

Enable users to enter a kinit command interactively from the SAS server. My previous post Understanding Hadoop security described the steps required for a Hadoop user to access a Hadoop client:

  • launch a remote connection to a server
  • run a kinit command
  • then run the Hadoop client.

The same steps apply when you are accessing the client through SAS/ACCESS to Hadoop. You can make a remote SSH connection to the server where SAS is installed. Once logged into the system, you run the command kinit, which initiates your Kerberos credentials and prompts for your Kerberos password. This step obtains your TGT and places it in the Kerberos Ticket Cache. Once completed, you can start a SAS session and run SAS code containing SAS/ACCESSS to Hadoop statements. This method provides access to the secure Hadoop environment, and SAS will interact with Kerberos to provide the strong authentication of the user.

However, in reality, how many SAS users run their SAS code by first making a remote SSH connection to the server where SAS is installed? Clearly, the SAS clients such as SAS Enterprise Guide or the new SAS Studio do not function in this way: these are proper client-server applications. SAS software does not directly interact with Kerberos. Instead, SAS relies on the underlying operating system and APIs to make those connections. If you’re running a client-server application, the interactive shell environment isn’t available, and users cannot run the kinit command. SAS clients need the operating system to perform the kinit step for users automatically. This requirement means that the operating system itself must be integrated with Kerberos, providing the user’s Kerberos password to obtain a Kerberos-Ticket-Granting Ticket (TGT).

Integrate the operating system of the SAS server into the Kerberos realm for Hadoop. Integrating the operating system with Kerberos does not necessarily mean that the user accounts are stored in a directory server. You can configure Kerberos for authentication with local accounts. However, the user accounts must exist with all the same settings (UID, GID, etc.) on all of the hosts in the environment. This requirement includes the SAS server and the hosts used in the Hadoop environment.

Managing all these local user accounts across multiple machines will be considerable management overhead for the environment. As such, it makes sense to use a directory server such as LDAP to store the user details in one place. Then the operating system can be configured to use Kerberos for authentication and LDAP for user properties.

If SAS is running on Linux, you’d expect to use a PAM (Pluggable Authentication Module) configuration to perform this step, and the PAM should be configured to use Kerberos for authentication. This results in a TGT being generated as a user’s session is initialized.

The server where SAS code will be run must also be configured to use PAM, either through the SAS Deployment Wizard during the initial deployment or manually after the deployment is complete.  Both methods update the sasauth.conf file in the <SAS_HOME>/SASFoundation/9.4/utilities/bin and set the value of methods to “pam”.

This step is not sufficient for SAS to use PAM.  You must also make entries in the PAM configuration that describe what authentication services are used when sasauth performs an authentication.  Specifically, the “account” and “auth” module types are required.  The PAM configuration of the host is locked down to the root user, and you will need the support of your IT organization to complete this step. More details are found in the Configuration Guide for SAS 9.4 Foundation for UNIX Environments.

With this configuration in place, a Kerberos Ticket-Granting-Ticket should be generated as the user’s session is started by the SAS Object Spawner. The TGT will be automatically available for the client-server applications. On most Linux systems, this Kerberos TGT will be placed in the user’s Kerberos Ticket Cache, which is a file located, by default, in /tmp. The ticket cache normally has a name /tmp/krb5cc_<uid>_<rand>, where the last section of the filename is a set of random characters allowing for a user to log in multiple times and have separate Kerberos Ticket Caches.

Given that SAS does not know in advance what the full filename will be, the PAM configuration should define an environment variable KRB5CCNAME which points to the correct Kerberos Ticket Cache.  SAS and other processes use the environment variable to access the Kerberos Ticket Cache. Running the following code in a SAS session will print in the SAS log the value of the KRB5CCNAME environment variable:

%let krb5env=%sysget(KRB5CCNAME);
%put &KRB5ENV;

Which should put something like the following in the SAS log:

43         %let krb5env=%sysget(KRB5CCNAME);
44         %put &KRB5ENV;

Now that the Kerberos Ticket-Granting-Ticket is available to the SAS session running on the server, the end user is able to submit code using SAS/ACCESS to Hadoop statements that access a secure Hadoop environment.

In my next blog in the series, we will look at what happens when we connect to a secure Hadoop environment from a distributed High Performance Analytics Environment.

More information


tags: authentication, configuration, Hadoop, Kerberos, SAS Administrators, security
10月 012014

hadoop-topo1So, with the simple introduction in Understanding Hadoop security, configuring Kerberos with Hadoop alone looks relatively straightforward. Your Hadoop environment sits in isolation within a separate, independent Kerberos realm with its own Kerberos Key Distribution Center. End users can happily type commands as they log into a machine hosting the Hadoop clients. From the host machine they can run processing against the Hadoop services.

But how does SAS fit into this picture? Where will the SAS servers and clients be located in relation to the Hadoop Kerberos realm? This post provides more insight into second of the four key practices for securing a SAS-Hadoop environment:

Simplify Kerberos setup by placing SAS and Hadoop within the same topological realm.

After reading this next blog post, a coworker told me botanists have a term that fits this concept perfectly: monoecious, from the Greek meaning “one household”. Some trees like hollies and ginkos have male and female flowers on separate plants, but for most plants, the connections of life are made much simpler by being monoecious, by ensuring the important elements are in close proximity. Here’s why that works for SAS-Hadoop-Kerberos too!

What happens if SAS and Hadoop are in different realms

It’s unlikely that many SAS and Hadoop environments will be installed at the same time.  Often one or more already exists. If you have an SAS existing environment in your corporate realm and you’ve just followed the instructions from your Hadoop provider for configuring Kerberos, you’ll probably have the setup in Figure 1.  SAS server and user authentication will happen in the corporate realm, while access to the Hadoop realm is governed by the Kerberos Key Definition Center and will happen in the Hadoop realm.

However, the major thing missing from the customer’s environment is reflected in the green arrow at the top. In the diagram below, the Corporate Domain and the new Hadoop Realm contain the trust relationships. A domain administrator must create these trusts by mapping users between the two realms.    Without one-way trust, SAS is not going to be able to interact with Hadoop at all. This topology will be one of the more complex arrangements. SAS administrators and their IT departments will need to set up all the required domain trusts represented by that little green arrow.

Once trusts are established, there are additional steps to ensure back-end Kerberos authentication for SAS processes running in the Corporate Realm. Ideally, to access Hadoop Services while running SAS processes, the operating system should be configured to perform the kinit step to obtain the correct Ticket Granting Ticket (TGT). Unless the operating system is given this capability, the SAS processes will be unable to request the Service Ticket and so will be unable to authenticate.

The simplest option for SAS administrators is to perform this step on the host running the SAS process as part of the session initialization. In this instance, the SAS session will be launched normally. For example, within an Enterprise Guide session, the end-user still enter a valid user name and password into the connection profile. This action sets up a back-end Kerberos authentication between the SAS process and the Hadoop Services.


Placing SAS and Hadoop in the same realm

Now an alternative to setting up the domain trusts above would be to move the SAS Servers and SAS High Performance Analytics nodes into the same “household” as the Hadoop Key Distribution Center, as shown here in Figure 2. In this configuration, the end-user logs into the corporate realm and launches a SAS session by entering a user name and password into a SAS client. The same credentials used to start SAS Enterprise Guide, for example, are also valid in the Hadoop realm.

Authentication now takes place in the joint SAS-Hadoop realm without additional mapping required. The SAS servers and SAS High-Performance Analytics nodes can interact with the same Kerberos Key Distribution Center as the Hadoop services because all the components are within the same Kerberos realm.

This topology will greatly simplify the Kerberos setup for the SAS components. The Kerberos authentication within the Hadoop Realm will be straightforward, and the only complexity will be if the customer has a requirement for end-to-end Kerberos authentication in which the SAS session itself is launched using Kerberos and Kerberos authentication from the user’s desktop through to the Hadoop services.



Where to find more information

SAS provides architecture documents that offer guidelines for ensuring your SAS-Hadoop environment is not only secure, but also offers faster response times.

tags: authentication, Hadoop, Kerberos, SAS Administrators, security
9月 242014

Hadoop_logoA challenge for you – do a Google search for “Hadoop Security” and see what types of results you get. You’ll find a number of vendor-specific pages talking about a range of projects and products attempting to address the issue of Hadoop security. What you’ll soon learn is that security is quickly becoming a big issue for all organizations trying to use Hadoop.

Many of you may already be planning or involved in Hadoop deployments involving SAS software. As a result, technical architects at SAS often get questions around security, particularly around end-point security capabilities. While there are many options for end-point and user security in the technology industry, the Hadoop Open Source Community is currently leading with a third-party authentication protocol called Kerberos.

Four key practices for securing a SAS-Hadoop environment

To access to a fully operational and secure Hadoop environment, it is critical to understand the requirements, preparation and process around Kerberos enablement with key SAS products. There are four overall practices that help ensure your SAS-Hadoop connection is secure and that SAS performs well within the environment. Today’s post is the first in a series that will cover the details of each of these practices:

  1. Understand the fundamentals of Kerberos authentication and the best practices promoted by key Hadoop providers.
  2. Simplify Kerberos setup by placing SAS and Hadoop within the same topological realm.
  3. Ensure Kerberos prerequisites are met when installing and configuring SAS applications that interact with Hadoop.
  4. When configuring SAS and Hadoop jointly in a high-performance environment, ensure that all SAS servers are recognized by Kerberos.

What is Kerberos?

Kerberos authentication protocol works via TCP/IP networks and acts as a trusted arbitration service, enabling:

  • a user account to access a machine
  • one machine to access different machines, data and data applications on the network.

Put in the simplest terms, Kerberos can be viewed as a ticket for a special event that is valid for that event only or for a certain time period. When the event is over or the time period elapses, you need a new ticket to obtain access.

How difficult is Hadoop and Kerberos configuration?

Creating a Kerberos Key Distribution Center is the first step in securing the Hadoop environment. At the end of this blog post, I’ve listed sources for standard instructions from the top vendors of Hadoop. Following their instructions will result in creating a new Key Distribution Center, or KDC, that is used to authenticate both users and server processes specifically for the Hadoop environment.

For example, with Cloudera 4.5, the management tools include all the required scripts to configure Cloudera to use Kerberos. Simply running these scripts after registering an administrator principal will result in Cloudera using Kerberos. This process can be completed in minutes after the Kerberos Key Distribution Center has been installed and configured.

How does Kerberos authenticate end-users?

A non-secure Hadoop configuration relies on client-side libraries to send the client-side credentials as determined from the client-side operating system as part of the protocol. While users are not fully authenticated, this method is sufficient for many deployments that rely on physical security. Authorization checks through ACLs and file permissions are still performed against the client-supplied user ID.

Once Kerberos is configured, Kerberos authentication is used to validate the client-side credentials. This means the client must request a Service Ticket valid for the Hadoop environment and submit this Service Ticket as part of the client connection. Kerberos provides strong authentication where tickets are exchanged between client and server and validation is provided by a trusted third party in the form of the Kerberos Key Distribution Center.

Step 1. The end user obtains a Ticket Granting Ticket (TGT) through a client interface.

Step 2. Once the TGT is obtained, the end-user client application requests a Hadoop Service Ticket. These two steps don’t always occur in this sequence because there are different mechanisms that can be used to obtain the TGT. Some implementations will require users to run a kinit command after accessing the machine running the Hadoop clients. Other implementations will integrate the Kerberos configuration in the host operating system setup. In this case, simply logging into the machine running the Hadoop clients will generate the TGT.

Step 3. Once the user has a Ticket Granting Ticket, the client requests the Service Ticket (ST) corresponding to the Hadoop Service the user is accessing. The ST is then sent as part of the connection to the Hadoop Service.

Step 4. The corresponding Hadoop Service must then authenticate the user by decrypting the ST using the Service Key exchanged with the Kerberos Key Distribution Center. If this decryption is successful the end user is authenticated to the Hadoop Service.

Step 5. Results are returned from the Hadoop service.


Where to find more information about Hadoop and Kerberos

Providers such as Cloudera and Hortonworks have general guidelines around the role of Kerberos Authentication within their product offerings. You can access their suggested best practices via some of the key technology pages on their websites:

tags: Hadoop, Kerberos, SAS Administrators, SAS Professional Services, security