Configuring Server Accounts

Overview

SAS Federation Server uses the following accounts for administration, authentication and data authorization:

The System User Account

The system user account is the most privileged account for SAS Federation Server.
Administrator Account

An administrator account is a user account created in Authentication Server, and then granted ADMINISTER privilege on SAS Federation Server.
The Trusted User Account

The trusted user account establishes a trust relationship between the SAS Federation Server and the Authentication Server.
Shared Logins

Shared logins help manage user connections from SAS Federation Server to the data. With shared logins, users can access data without needing individual logins to access the data source.

The System User Account

Introduction

The SYSTEM user is a privileged account which means that it carries more privileges than an administrator account. There is nothing on SAS Federation Server that the system account cannot do because the account has implicit privileges to all user and data objects. The operating system process that invokes and runs SAS Federation Server is automatically a system user. By default, the account used to install SAS Federation Server is registered as a system user account. Other user accounts can also be registered as system users in the dfs_serv_common.xml configuration file.

The system user should identify users who will be administrators of SAS Federation Server, and make them administrators by granting them the ADMINISTER privilege on the server object. Like SYSTEM users, administrators are unconditionally and implicitly granted all privileges on SAS Federation Server. However, if these users are revoked their ADMINISTER privilege, then they become standard users that have privileges granted to and denied from them. A SYSTEM user can never be denied privileges.

If a Data Source Name (DSN) is created by either the system user or an administrator, the DSN is created using the AS ADMINISTRATOR clause, which means that the ADMINISTRATOR role owns the DSN, not the individual creating it. Therefore, if the administrator user is later removed from the system, the DSN will not be deleted with the user.

Use the system user account to define one or more administrators for SAS Federation Server. As a best practice, all configuration and administration should be performed by the administrator.

Configuring the SystemUsers OptionSet

The SystemUsers option set defines the system user accounts for the SAS Federation Server. When system users grant or deny privileges to others, the grantor is reflected in the system tables as the system user ID. Each system user should be a domain-qualified user name.

<SystemUsers> 
   <Option name="Account">domain\uid1</Option>
   <Option name="Account">domain\uid2</Option>
</SystemUsers>

Altering the System User Account

You can add or remove system users by updating configurations in the SystemUsers option set explained above.

Administrator Account

Overview

An administrator account is a user account created in Authentication Server, and then granted ADMINISTER privilege on the SAS Federation Server. Only system users can grant the ADMINISTER privilege.

Administrators have implicit privileges to perform every other action including the following:

create and drop data source names (DSN)
grant and deny privileges to other accounts
create and drop data services, catalogs, and schemas

Setting the ADMINISTER Privilege

To define a user as an administrator for SAS Federation Server, grant the ADMINISTER privilege to their account using the following syntax:

GRANT serverpriv ON servername TO "user-ID"
GRANT administer ON FedServer1 TO "user1"

For further details, reference the GRANT and DENY DDL statements.

The Trusted User Account

Overview

The trusted user account is set up in the Authentication Server and configured in SAS Federation Server using the ALTER SERVER statement or SAS Federation Server Manager. Use this account to establish a trust relationship between the SAS Federation Server and the Authentication Server. The trust relationship is required for certain features to work such as definer's rights views.

A few notes about the Trusted User account:

A trusted user is a user ID that has to be able to authenticate using the authentication method that is deployed for the installation.
As stated above, this account is used only by SAS Federation Server to connect to Authentication Server in certain scenarios like definers rights views. You would never log on using this account.
The trusted user should not be a system or administrative user on Authentication Server or SAS Federation Server.

Using DDL to Configure the Trusted User

Use the ALTER SERVER statement to define the trusted user.

ALTER SERVER {OPTIONS(xset TRUSTED_USER_UID 'user-ID', 
xset TRUSTED_USER_PWD 'password')}

Note: User IDs and passwords must be added or dropped in pairs.

Configure the Trusted User in Federation Server Manager

You can also configure a trusted user account using SAS Federation Server Manager.

To define the trusted user:

Locate the SAS Federation Server object in the tree and select the Action Menu in the upper left corner.
Using the action menu, select Properties to display the server properties dialog box.
Click the Security tab in the Federation Server Properties dialog box.
Set the Trusted user ID and password and click OK.

Shared Logins

Overview

Using Shared Logins, users can access data when they do not or should not need to know the credentials used to access this data. Shared Logins help manage user connections from SAS Federation Server and outside of the database. Only one set of credentials is used to access data for groups of people who will never know the credentials that are being used. Authorization management occurs and is managed at a layer above the database. Using shared logins is optional. If using shared logins to connect to data sources, they must be configured in SAS Federation Server before they will function properly in a DSN.

Shared Login Manager

When using shared logins to authenticate users to a data source, users do not need to know the credentials that they are using because the shared login manager is retrieving credentials for the user that is logged on and providing the credentials to SAS Federation Server so that the server can connect the user to the database through the appropriate data service or DSN.

The shared login account is created in Authentication Server which includes the login to be shared and its domain, consumers of the login, and a login key.
The shared login manager and login key is configured in SAS Federation Server using administrative DDL or SAS Federation Server Manager.

The shared login manager login identifies the credentials used to connect to the Authentication Server and retrieve the shared login. It is required that the shared login manager be a manager of that shared login in Authentication Server. The shared login is not directly readable by consumers of the shared login. It can be read only by managers or the owner. The shared login manager's password is encrypted.

The shared login key identifies which shared logins created in Authentication Server are available to a SAS Federation Server instance. The key defined in SAS Federation Server must match the key that is part of the shared login definition in the Authentication Server.
After the shared login manager account is configured, the account information can be referenced from DSNs in SAS Federation Server. The DSN is configured with a credentials search order of SHARED.

Configure shared logins in SAS Federation Server using the

ALTER
                        SERVER

DDL statement. You can also configure a shared login though SAS Federation Server Manager, using the Security dialog box located in the properties of a Federation Server object.

Shared Login Manager Configuration Using DDL

Use the ALTER SERVER statement to set shared logins and to configure the shared login key. For example,

alter server {options xset sharedloginkey 'DefaultKey'}
alter server {OPTIONS(xset SHAREDLOGINMANAGER 'manager user id',
xset SHAREDLOGINPASSWORD 'manager password')}

Note: User IDs and passwords must be added or dropped in pairs.

Shared Login Configuration Using Federation Server Manager

Locate the Federation Server object in the tree and select the Action Menu in the upper left corner.
From the action menu, select Properties to display the server properties dialog box.
Select the Security tab and configure the shared login with the following information:
- Shared login manager user ID
- Shared login manager password
- Shared login key

After shared logins are configured, they can be referenced to establish connections to data sources. Reference the Configuring Data Source Access topic for additional information.

Best Practices for Setting Shared Logins

Overview

Shared logins are created in the Authentication Server when there is a need to share logins among multiple users. Logins must be owned by users, not groups. Therefore, shared logins are the only mechanism to provide this functionality.

Shared logins consist mainly of the login and domain to share, and the consumers who use that login. The consumers will typically list one or more groups, which is a best practice. A conflict can arise when a particular user is in a consumer group (directly or indirectly) of multiple principal maps for the same domain. The following scenarios explain how shared login conflicts are resolved.

Scenario 1: Application Users

In the following scenario, an application exists which requires the use of a particular set of database credentials to access its protected data. For example, an HR application has data content stored in Oracle and DB2.

To manage credentials:

Identify all the users of the HR application. The users might have different roles or data access privileges, but they all need to access the data. These users (or subgroups) will all be placed in the group HR_USERS.
Create a shared login for each domain. In this case, the administrator would create an HR_ORACLE and HR_DB2 shared login. For both shared logins, the administrator would specify the HR_USERS group as a consumer member of the shared login. Each shared login would contain the appropriate principal and domain for the database.
Specify the GROUP option to qualify the users with the shared login, either in the DSN itself, or on the connection string specifying the DSN. In this case, the GROUP option would be HR_USERS.
Set authorizations on different users and groups to control which set of users can perform which operations, for example SELECT versus UPDATE versus DELETE. All of the users and groups should be members of the HR_USERS group.

At connect time, the HR_USERS group is used to identify the correct shared login for each underlying database connection. If the connecting user were a consuming member of another shared login, the GROUP value would properly identify which one to use.

Algorithm When Using the GROUP Option

Shared logins are initially considered candidates for outbound credentials selection if the domain and shared login key match. If the domain is empty, shared logins for any domain initially qualify. This also applies to the shared login key, which is configured as part of SAS Federation Server.

If the GROUP connection string option is specified (which is derived from the consumer group in the DSN configuration), then only maps where the group is a direct or indirect consumer will be considered a candidate for outbound credentials selection. The basic algorithm selects a map based on the closeness of the specified group to the map.

Candidate Map Processing

If the user is not a direct or indirect member of the shared login consumer group, the map is not a candidate; otherwise,
If the GROUP is not a direct or indirect consumer of the map, the map is not a candidate; otherwise,
The distance from the GROUP to the map is computed by following the group member-of relationship up to the group that is the direct consumer. The candidate map is retained only if the distance is less than or equal to the current minimum distance to the map. The current minimum distance is updated.
After all candidate maps have been processed,
1. if exactly one has been retained, use the associated credentials; or
2. if two or more were retained, check the closest two and use the credentials associated with the closest of the two (error if the distances are the same unresolved conflict); or
3. if no maps have been retained, use no credentials.

Scenario 2: Organized Consuming Users

In the following scenario, the administrator has organized the users based on company organization or another classification.

The administrator wants to use this relationship so users qualify for a particular shared login, for example:

The administrator wants to grant access to Oracle account EXECUTIVE_USER to his most privileged users, identified by the MARKETING_EXECUTIVE group.
The administrator wants to grant access to Oracle account MARKETING_USER to members of the marketing division in the company, identified by the MARKETING group.
The administrator wants to grant access to Oracle account STANDARD_USER to all other known users in the system, identified by the USERS group.
The administrator created groups which reflect the company's organizational chart. The MARKETING group reflects all members of the marketing organization, with the MARKETING_EXECUTIVE group included as a member of the MARKETING group.

The administrator creates shared logins for the EXECUTIVE_USER, MARKETING_USER and STANDARD_USER Oracle accounts. Next, he assigns MARKETING_EXECUTIVE, MARKETING and USERS consuming groups, respectively, to these shared logins.

Then, the shared login chosen would be as follows:

For members of the MARKETING_EXECUTIVE group, they would be closest to the shared login identified by that group, even though they were likewise members of the MARKETING and USERS groups. Therefore, this set of users would consume the EXECUTIVE_USER Oracle account.
For members of the MARKETING group, they would be closest to the Shared Login identified by that group, even though they were likewise members of the USERS group. Therefore, this set of users would consume the MARKETING_USER Oracle account.
All other known users would qualify only for the shared login identified by the USERS group. Therefore, this set of users would consume the STANDARD_USER Oracle account.

In this scenario, the administrator would not use the GROUP option, since the option accepts only a single value, and no single value works for all users. The administrator would omit the GROUP option and allow a closeness algorithm to identify which shared login to use.

Algorithm When No GROUP Option Is Specified

If the GROUP connection string option is not specified, then all maps where the user is a direct or indirect consumer will be considered a candidate for outbound credentials selection. The basic algorithm selects a map based on the closeness of the specified user to the map, or USERS if the user is not a consumer, and finally PUBLIC if USERS is not either. If the user is PUBLIC, selection is done based on PUBLIC alone.

Candidate Map Processing for a User

If the user is not a direct or indirect consumer of the map, the map is not a candidate; otherwise,
The distance from the user to the map is computed by following the group member-of relationship up to the group that is the direct consumer. The candidate map is retained if the distance is less than or equal to the current minimum distance to the map. The current minimum distance is updated.
After all candidate maps have been processed,
1. if exactly one has been retained, use the associated credentials; or
2. if two or more were retained, check the closest two and use the credentials associated with the closest of the two (error if the distances are the same unresolved conflict); or
3. if maps have not been retained, use no credentials.

Candidate Map Processing for USERS

If USERS is a direct consumer of the map, then the candidate map is retained.
If a candidate map has been retained already, return an error (unresolved conflict).
After all candidate maps have been processed, if exactly one has been retained, return OK and the associated credentials; or

Continue on to Candidate Map Processing for PUBLIC.

Candidate Map Processing for PUBLIC

If USERS is a direct consumer of the map, then the candidate map is retained.
If a candidate map has been retained already, return an error (unresolved conflict).
After all candidate maps have been processed, if exactly one has been retained, return OK and the associated credentials; or

Return OK but empty credentials if no candidate maps retained.

Path Length Computation Details

If USERS or PUBLIC is a member of another group, and that group is a map consumer, direct or indirect, the path length is not incremented when traversing from the user to the map. For the purposes of map selection, this effectively makes placing either of these two groups in another group a shorthand way to place all users in that group.