How Logins Are Used

Summary of How Logins Are Used

Purpose	Login Properties1
To enable the metadata server to match an incoming user ID with a particular SAS identity (inbound use).	User ID
To enable clients to seamlessly obtain user credentials for disparate systems (outbound use).	User ID, password, authentication domain
To designate one account as the preferred account for user access to a particular library and to make that account ID and password available to users. If you assign a login to a library, all users who can see that login use that login to access that library. This is a specialized form of outbound use that is sometimes used for a DBMS library.	User ID, password, authentication domain
To designate one host account as the account under which a particular server runs and to make that account's ID and password available to the spawner (service use).	User ID, password
1Indicates which properties are involved. Every login should be assigned to an authentication domain.

The following figure depicts examples of login use.

Example: Use of Logins

Here are some general points about the figure:

The workspace server (using host authentication) isn't depicted because access to that server is not usually through stored credentials.

Note: If you choose to store passwords for the workspace server, the relationships would be comparable to the depiction of the Oracle DBMS, OracleAuth authentication domain, and Oracle logins. For example, you might put the workspace server in WorkspaceAuth and create individual and group logins in that authentication domain.
The OLAP server isn't depicted because it isn't accessed using logins.
The gray shading for the depicted workspace server indicates that this is a specialized configuration. By default the workspace server uses some form of host authentication, not SAS token authentication.

The numbers in the figure correspond to these uses:

Joe's first login is only for inbound use to determine his metadata identity. His password is available (cached in the user context, not stored in the metadata) but isn't used to determine his identity. This login should be in DefaultAuth, but that relationship isn't depicted because it isn't used in determining his metadata identity.
Joe's second login provides seamless access to Oracle using an individual account. This login includes a password and must be in the Oracle server's authentication domain. The ETL group's login is a shared login for the Oracle server. Joe won't use this login because his personal Oracle login has a higher priority.
The SASUSERS login is a designated default login for the Special Library. This login is visible to Joe (through his automatic membership in SASUSERS), so it is used when Joe accesses the Special Library. Assigning a login to a library overrides the usual login priority evaluation (which is based on identity precedence).

Note: In this example, the ServiceOra login must be in the OracleAuth authentication domain. The list of available default logins for a library consists of only those logins that are in the associated server's authentication domain. The shading for the Special Library indicates that this isn't a mainstream use. Most libraries don't have a designated login.

Note: In an alternate usage, the default library login is part of the user definition for a service identity that provides mediated access to the library.
The designated launch credential for each of the depicted processing servers is stored on the SAS General Servers group definition. In this example, the servers all use the same credential. Logins that contain designated launch credentials are usually in the DefaultAuth authentication domain, because these processing servers are usually in DefaultAuth. However, those logins are directly paired with each server, not looked up by authentication domain. Because the authentication domain assignment for these logins isn't used, the figure doesn't depict that assignment.

How Logins Are Used

See Also