Authentication Model

Mixed Providers

	About Mixed Providers
	Solution to Mixed Providers: Use SAS Token Authentication
	Solution to Mixed Providers: Align Authentication
	Solution to Mixed Providers: Store User IDs and Passwords

About Mixed Providers

If the credentials with which users initially log on aren't also valid for the workspace server, access to the standard workspace server isn't seamless. For example, if you use an Active Directory account in an initial logon to a metadata server on Windows, and you attempt to access a standard workspace server on UNIX, you might be prompted for a user ID and password that are valid for the UNIX host.

Note: In general, Web applications and SAS Information Map Studio use the pooled workspace server, not the standard workspace server. So users who use only these applications might not be affected by a mixed provider situation. See Choices in Workspace Server Pooling. [cautionend]

In a mixed providers situation, achieving seamless access to the standard workspace server requires a trade-off between configuration effort, maintenance effort, and degree of segregation for host access from that server to SAS data. The following table outlines the choices.

Choices for Seamless Access In a Mixed Provider Scenario
Priority	Recommendation
Minimize administrative effort.	The preferred approach is to convert the workspace server to use SAS token authentication. You can instead store a single shared password for the workspace server's host.¹
Provide a few levels of host access with minimal administrative effort.	The preferred approach is to define a few servers that use SAS token authentication. Each server runs under a different account. You can instead store a few shared passwords for the workspace server's host.¹
Preserve each user's identity.	The preferred approach is to align authentication so that both servers do use the same provider. You can instead store individual passwords for the workspace server's host.
1 The shared password is stored in a login on a group's Accounts tab. Members of a group can use that group's logins.

The following topics provide details about each approach.

Solution to Mixed Providers: Use SAS Token Authentication

If you configure the workspace server to use SAS token authentication, access is seamless because the workspace server's host operating system is no longer used to validate users. Instead, users are validated by the metadata server through a single-use SAS identity token.

In a mixed providers situation, using SAS token authentication is preferable to using a group login for these reasons:

SAS token authentication enables the requesting user's SAS identity to be used for metadata layer evaluations such as library pre-assignment and permissions and auditing.
SAS token authentication doesn't give users direct access to the server launch credential.
SAS token authentication involves less transmission of reusable credentials (the client doesn't retrieve credentials from the metadata and send those credentials to the workspace server).

See How to Configure SAS Token Authentication.

Solution to Mixed Providers: Align Authentication

If you can enable the metadata server and the standard workspace server to use the same provider, access is seamless through credential caching and reuse.

If the metadata server is on Windows and the workspace server is on UNIX, you might use PAM to extend the UNIX host authentication process to recognize Windows accounts. See Pluggable Authentication Modules (PAM). With this approach, the Windows credentials that users supply in their initial logon to the metadata server can be reused for authentication to the workspace server. User identity is preserved from the workspace server to the host, you don't have to store user passwords in the metadata, and access is seamless. However, this approach has these limitations:

Using PAM isn't compatible with Integrated Windows authentication (IWA) for these reasons:
- Even though the UNIX server now accepts Windows accounts, the UNIX server still can't do IWA. The SAS implementation of IWA is only for servers on Windows.
- Because this approach reuses cached Windows credentials to provide access to the workspace server, you can't use IWA for the metadata server either. When IWA is used to get to the metadata server, only a Windows token is passed so there are no available cached credentials. Instruct users to not select the Integrated Windows authentication option in their connection profiles. Consider adding the -nosspi option to the metadata server's sasv9_usermods.cfg file.
Using PAM to resolve a mixed providers situation requires that you stored two logins for anyone who accesses the standard workspace server. One login contains the user's ID in qualified format (for example, WIN\myID) and the other login contains the same ID in short format (for example, myID). Both logins can be in DefaultAuth. Neither login has to include a password.

If the metadata server is on UNIX (or z/OS) and the workspace server is on Windows, an additional alternative is to make the metadata server itself recognize Windows accounts. See Direct LDAP Authentication.

Note: Direct LDAP isn't supported for the workspace server. The workspace server can use only some form of host authentication or SAS token authentication. [cautionend]

Solution to Mixed Providers: Store User IDs and Passwords

If you store user or group passwords for the workspace server's host, access is seamless through credential retrieval. In this solution, you treat the workspace server as if it were a third-party server such as Oracle. See How to Store Passwords for the Workspace Server.

Top of Page