Mixed Providers

Solution to Mixed Providers: Align Authentication

Solution to Mixed Providers: Use SAS Token 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.

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
Preserve each user's identity.	Align authentication so that both servers do use the same provider.
Minimize administrative effort.	Convert the workspace server to use SAS token authentication.

The following topics provide details about each approach.

Solution to Mixed Providers: Align Authentication

If you can enable the metadata server and the standard workspace server to use the same provider, access to the workspace server is seamless. Here are some examples:

If the metadata server is on Windows and the workspace server is on UNIX, you might extend the UNIX host authentication process to recognize Windows accounts (using a technology such as 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.

Note: If you chose to use IWA in this scenario, you should configure both servers to support that authentication method. If you configure only the metadata server to support IWA, then access to the workspace server is not seamless, because there are no cached credentials available for reuse.

Note: This approach usually requires that you store 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. An exception to this requirement is if the user names on UNIX are domain qualified (in that case, only the domain qualified user ID is stored in metadata).
If the metadata server is on UNIX (or z/OS) and the workspace server is on Windows, an additional alternative is to configure direct LDAP, so the metadata server itself recognizes Windows accounts.

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.

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. If you need to provide a few distinct levels of host-layer access, you can define a few servers, with each server using SAS token authentication and running under a distinct launch credential.

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).

Solution to Mixed Providers: Store User IDs and Passwords

Note: As explained in the preceding topic, storing credentials is not a first choice solution to a mixed providers situation.

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.

Mixed Providers

About Mixed Providers

Solution to Mixed Providers: Align Authentication

Solution to Mixed Providers: Use SAS Token Authentication

Solution to Mixed Providers: Store User IDs and Passwords

See Also