Single sign-on in a mixed environment

[jklaverstijn]

Hi all,

we are embarking upon a complicated migration from 9.1.3 to 9.3. We use most of EBI, EDI and SPDS. We plan to have metadata and web tiers on Win64 and server on Linux. I must say upfront that it is not my intention to discuss the platform choice itself in this thread. 😉

My question is about sso. We want to leverage AD for our EG users. It is obvious that the connection to the MDS will be authenticated by AD. But what about the Workspace Server on Linux? Will that start authenticated implicitly based on the trusted relationship between the spawner and the mds? Or do we need this software from Quest installed so that the Linux process can go to AD itself. Personally I would say the first is true, but other people in the project believe otherwise.

I am very much looking forward to your input and discussion on this.

Regards Jan.

[PaulHomes · Accepted solution]

Hi,

Since single sign-on can mean different things to different people, what are you thinking of as single sign-on in your situation?:

A) Same credentials (user id and password) can be used to access SAS Metadata Server on Windows and the SAS Object Spawner / SAS Workspace Server on Linux because they both authentication against the same AD server?

or B) No userid and password are provided to the SAS Metadata Server on Windows and the SAS Object Spawner / SAS Workspace Server on Linux because Integrated Windows Authentication (IWA) will be used?

To implement the first option (A) you could ask your Linux sys admins to configure PAM so the Linux server authenticates against the same AD server used by the Windows machine the Metadata server is running on.  With the same backend authentication provider, the same userid and password would be valid for both the Windows and Linux machines. This is more of a Linux configuration job than a SAS configuration job (though there is a small bit of SAS config to do).  If you make sure the SAS servers are in the same authentication domain then the credentials used to login to the Metadata Server on Windows should be cached for re-use with the Object Spawner on Linux.

To implement the second option (B) using IWA you will need to use Quest software and SAS 9.3 (SAS client support for IWA with UNIX servers is new in SAS 9.3, it was IWA with Windows servers only prior to SAS 9.3)

A third simpler but less flexible option is to configure the Workspace Server running on the Linux server for SAS token authentication.  This avoids having to configure the Linux server to authenticate against AD but does require you to use a shared account for launching standard workspace servers on the Linux server.  This can be an attractive option for some but can also be a problem for others.  With this option you lose the ability to implement fine grained file system security by distinguishing between the various Workspace Server users because the same operating system account is being used for file system access by all Workspace Server processes. If that's not a concern for you then your organization then you might like this option.

As you can see there are variety of different options and the preferred approach can be different for different sites.

A good place to start reading up on this is the SAS(R) 9.3 Intelligence Platform: Security Administration Guide page for authentication with Mixed Providers.

I hope this helps.

Cheers

Paul