Authentication to the Metadata Server

How SAS Identity Is Determined

When a user launches a SAS client, the following process occurs:
  1. In the verification phase, the system ensures that the user is who he or she claims to be. For example, this credential-based host authentication method might be used:
    1. The client prompts the user for an ID and password.
    2. The user enters credentials that are known to the metadata server's host.
    3. The client sends the credentials to the metadata server.
    4. The metadata server passes the credentials to its host for authentication.
    5. If the host determines that the user has a valid account, the host returns the authenticated user ID to the metadata server.
  2. In the SAS identity phase, the system resolves the authenticated user ID to a particular SAS identity. In this phase, SAS examines its copies of user IDs in an attempt to find one that matches the authenticated user ID. One of the following outcomes occurs:
    • A matching user ID is found, so a connection is established under the owning identity. The owning identity is the user or group whose definition includes a login with the matching user ID.
      Note: The metadata server's integrity constraints ensure that there won't be more than one owning identity. See Uniqueness Requirements.
      Note: Not all applications allow a group identity to log on.
    • No matching user ID is found, so a connection is established under the generic PUBLIC identity. In the metadata layer, the user is a PUBLIC-only user.
      Note: The matching process expects the SAS copy of the user ID to be qualified (if it is a Windows user ID).
      Note: Not all applications allow a PUBLIC-only user to log on. See PUBLIC Access and Anonymous Access.

Authentication Process and Methods

The following figures introduce the metadata server's authentication process and methods. In the following figures, notice these points:
  • Only the verification phase varies; the SAS identity phase is always the same. With any approach, you need a well-formed user definition for each user who isn't a PUBLIC-only identity.
  • Except where internal accounts are used, the process always involves two sets of identity information, one in an external provider and another in the metadata.
The following figure depicts the basic process.
Metadata Server: Host Authentication (Credential-Based)
Metadata Server: Host Authentication (Credential-Based)
The following figure depicts a special case where a metadata administrator named Joe uses an internal account.
Metadata Server: Internal Authentication
Metadata Server: Internal Authentication
The following figure introduces alternate approaches that can help you use accounts that already exist in your environment or provide single sign-on (silent launch of clients).
Alternate Configurations
Alternate Configurations