Previous Page | Next Page

Authentication Mechanisms

SAS Internal Authentication

Internal Authentication
Summary Participating SAS servers validate incoming user IDs that have a special suffix (@saspw) against a list of accounts that exist only in the metadata.
  • Primarily used for connections to the metadata server.

  • Also supported for direct connections to the OLAP server.1

  • Minimizes the need to create external accounts for service identities.

  • Facilitates intermittent use of an administrative role by enabling a user to have a second metadata identity without having a second external account. See Add Administrators.

  • Provides independence from the rest of your computing environment. For example, internal accounts don't have to follow your general password change requirements, can't be used to access resources beyond the SAS metadata, and aren't affected by changes in machine names or in your authentication configurations.

  • Internal accounts aren't intended for regular users (they are intended for only metadata administrators and some service identities).

  • Someone who has only an internal account can't seamlessly access the workspace server. See Credential Gaps.

  • An internal account can't participate in Integrated Windows authentication or Web authentication.

  • You can't use an internal account to delete, unregister, add, or initialize a foundation repository.

  • You can't run a server under an internal account. For example, the SAS General Server User (sassrv) must be a host account.

Use Always available
1 This isn't a common use. In the SQL procedure, a connection to the OLAP server can be made using an internal account.

Internal accounts exist only in the metadata and are created in the User Manager plug-in in SAS Management Console. The following displays depict the General tab and Accounts tab for an administrator named Joe. Notice that Joe's internal user ID is Joe@saspw. The user ID for an internal account is always in the format name@saspw. The name comes from the Name field on the user's General tab.

[untitled graphic]

The following figure depicts the internal authentication process:

Internal Authentication

[Internal Authentication]

The numbers in the preceding figure correspond to these actions:

  1. At a logon prompt, Joe enters his internal credentials. The client sends those credentials to the metadata server for verification.

  2. The metadata server recognizes that the ID is for an internal account (because the ID has the @saspw suffix), so the metadata server checks the credentials against its list of internal accounts.

  3. After validating the ID and password, the metadata server accepts the client connection. The connection is under the identity of the SAS user who owns the account.

    Note:   Joe can have logins in addition to his internal account, but he doesn't need a login to establish his SAS identity.  [cautionend]

Here are some tips for working with internal accounts:

Because internal accounts exist only in the metadata, they don't automatically follow the policies of other authentication providers. Here are the initial policies for internal accounts:

You can set all of these policies globally (at the server-level). You can also selectively override many of these policies on a per-account basis. See How to Change Internal Account Policies.

See Also

How to Configure SAS Internal Authentication

Authentication to the Metadata Server

Previous Page | Next Page | Top of Page