Authentication Model

Authentication to the Metadata Server

	How SAS Identity is Determined
	Depictions of the Authentication Process
	Example: Metadata Server on UNIX
	Example: Metadata Server on Windows

How SAS Identity is Determined

When a user launches a SAS client, the following process occurs:

verification phase

ensures that the user is who he or she claims to be. For example, this credential-based host authentication method might be used:

The client prompts the user for an ID and password.
The user enters credentials that are known to the metadata server's host.
The client sends the credentials to the metadata server.
The metadata server passes the credentials to its host for authentication.
If the host determines that the user has a valid account, the host returns the authenticated user ID to the metadata server.

SAS identity phase

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 Unique Names and IDs.
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). See User ID Formats.

Depictions of the Authentication Process

The following figures introduce authentication methods for the metadata server. For details about any of the following configurations, see Authentication Mechanisms. 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) These approaches are documented in Authentication Mechanisms.

Alternate Configurations

[Alternate Configurations]

Note: This topic is about authentication of users. For information about how some servers connect to the metadata server, see Trusted Peer Connections and Trusted User Connections. [cautionend]

Example: Metadata Server on UNIX

The following annotated template shows how a UNIX site might provide access to the metadata server. Here are some points about this example:

The UNIX computer that hosts the metadata server recognizes LDAP accounts.
This site can't use Integrated Windows authentication (IWA) because the SAS implementation of IWA is available only if the metadata server is on Windows. When users at this site launch SAS desktop clients, they provide the user ID and password for their LDAP accounts.
This site chose to not use Web authentication. When users at this site access a SAS Web application, they provide the user ID and password for their LDAP accounts. Access from one SAS Web application to another is seamless.

Example: Metadata Server on UNIX

[Example: Metadata Server on UNIX]

Note: In the template, the internal account branch is shaded because internal accounts are intended only for metadata administrators and some service identities. The direct LDAP branch is shaded because direct use of an LDAP provider (such as Active Directory) is not a first choice mechanism. [cautionend]

Example: Metadata Server on Windows

The following annotated template shows how a Windows site might provide access to the metadata server. Here are some points about this example:

Integrated Windows authentication (IWA) provides silent launch from SAS desktop clients for each user who chooses to use this feature. Users who don't select the IWA setting in their connection profiles are instead authenticated using credential-based authentication.
Web applications can't use the SAS implementation of IWA. To provide silent launch for these applications, this site configured Web authentication. Everyone who has authenticated at the site's Web perimeter accesses SAS Web applications without interactively providing credentials. Unlike IWA, Web authentication doesn't require (or allow) individual users to opt in or out.
Notice that the user's login contains a qualified user ID. The user ID in any Windows login must be properly qualified. Someone who has a missing or improperly specified user ID in his or her login has no individual SAS identity and is a PUBLIC-only identity.
The figure suggests that someone who uses both Web and desktop applications needs two logins, one in DefaultAuth and one in the web authentication domain. If the same user IDs are valid in both contexts, having a Web login is not a strict requirement (unless the Web applications must provide seamless access to a standard, unpooled workspace server).

Example: Metadata Server on Windows

[Example: Metadata Server on Windows]

Top of Page