Credential Management
|
|
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.
|
|
|
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.
|
|
|
Provides access to
servers using individual or shared accounts.
|
|
|
-
Involves passing user IDs and passwords
across the network.
-
Can involve maintaining SAS copies
of external passwords.
|
|
|
|
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 metadata definition
has logins that include passwords, those credentials are added to
the list.
-
If the user belongs to any groups
whose metadata definition has logins that include passwords, those
credentials are added to the list.
Note: Credentials from a user or
group's metadata definition 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:
Example: Contents of a User Context
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 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.
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.
Note: In SAS Management Console,
this information is displayed on the
Options tab
of each of the server's connection objects
.
-
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.
-
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.
-
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.
-
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).