Authentication Mechanisms |
Summary | A supporting feature in which clients reuse cached credentials or retrieve stored credentials. Clients use authentication domain assignments to determine which credentials are valid for which servers. The target server validates the client-supplied credentials against its authentication provider. |
Scope | From clients that are already connected to the metadata server to third-party servers, the Scalable Performance Data Server, and, in some cases, the workspace server. |
Benefits | Provides access to servers using individual or shared accounts. |
Limits |
|
Use | Always available |
Credential management techniques populate an in-memory list of credentials for each connected user. Each list is called a user context and includes these entries:
If the user interactively provides credentials when launching a SAS client, those credentials are added to the list, with these exceptions:
If Web authentication is configured, the password from a user's interactive logon to a Web client isn't available to be added to the list.
If the user logs on with Integrated Windows authentication (IWA), the user's password isn't available to be added to the list.
If the user interactively provides credentials at any point in the session, those credentials are added to the list.
If the user's Accounts tab has logins that include passwords, those credentials are added to the list.
If the user belongs to any groups whose Accounts tab has logins that include passwords, those credentials are added to the list.
Note: Credentials from a user or group's Accounts tab are not included in the initial list that is created when a user logs on. Instead, such credentials are added to the list dynamically (when and if they are needed in the course of the user's session).
The following table depicts an example of the contents of a user context:
User ID | Password | Authentication Domain |
---|---|---|
myWinID | ******** | DefaultAuth |
GroupDBMSid | ******** | DBMSauth |
Notice that each entry is assigned to an authentication domain. This enables pairing of credentials with the servers for which they are valid. The entries are created as follows:
The client creates the first entry by caching and inserting the user ID and password that a user submits in an initial logon. This makes the user's DefaultAuth password available for reuse even though that password isn't stored in the metadata. The client automatically assigns the first entry to the DefaultAuth authentication domain except in these circumstances:
The user's connection profile contains a user ID with an @saspw suffix.
Note: Notice that this circumstance describes the user ID in the user's connection profile, not the user ID that the user supplies in the logon dialog box.
The Authentication domain field in the user's connection profile contains a value other than DefaultAuth (and isn't empty).
The user is accessing a Web client at a site that has configured Web authentication (or has specified a different authentication domain in the Web configuration for some other reason).
The client creates the second entry by retrieving information from the metadata (in the preceding example, from the Accounts tab of a group that the user belongs to). Such logins are for outbound use, so they must include a password and an appropriate authentication domain assignment. See How Logins Are Used.
When a user requests access to a server that requires credential-based authentication, the client completes these steps:
Examine the server's metadata to determine which authentication domain the server belongs to. This information is on the Options tab of each of the server's connection objects in SAS Management Console.
Examine the user's context to determine whether it includes any credentials that are assigned to the target server's authentication domain. The process is as follows:
If the context includes a cached entry for the target authentication domain, that entry is used.
If the user context contains a retrieved entry for that authentication domain, that entry is used. If there is more than one retrieved entry for an authentication domain, the entry that is closest to the user is used. See Identity Precedence.
If there is an identity precedence tie among retrieved entries (for example, if a user is a direct member of two groups and both groups have logins in the relevant authentication domain), the same login is used consistently, but you can't control which of the two logins is used.
If the user context contains no entries in the target authentication domain, desktop clients will prompt the user for credentials. Web applications can't prompt.
Note: SAS Web Report Studio has an interactive password management feature. See Providing DBMS Credentials Interactively in the SAS Intelligence Platform: Web Application Administration Guide.
Present the credentials to the target server for authentication against its provider.
Here are some additional tips:
Because the credentials that are added to a user context from an initial logon are not likely to be valid for a third-party DBMS, you usually have to store credentials for such servers. See How to Store Passwords for a Third-Party Server.
Authentication domains have no effect on an initial logon. Authentication domains affect access to secondary servers that perform credential-based authentication.
To prevent attempts to reuse internal credentials for the workspace server (which doesn't accept internal credentials), users who have an internal account should use a dedicated connection profile for that account. In their internal connection profiles, users should leave the Authentication domain field blank (or specify an arbitrary value such as InternalAuth).
Copyright © 2011 by SAS Institute Inc., Cary, NC, USA. All rights reserved.