Roles :: SAS(R) 9.3 Intelligence Platform: Security Administration Guide

Role Definitions

Roles control the availability of application features such as certain menu items, plug-ins, and buttons. In the initial configuration, registered users have almost all non-administrative capabilities. In many cases, this is appropriate and sufficient. However, you can choose to alter the initial configuration by using either or both of the following techniques:

To increase or reduce the availability of a role, change the assignment of members to the role.
To redistribute capabilities, change the assignment of capabilities to roles, or create additional roles.

Here are some tips for working with roles:

Before you make changes, make sure you have a complete and current backup.
Capability assignments can be redundant across roles. To prevent someone from having a capability, you must make sure they aren't in any role that provides that capability.
Never change the name of a predefined role.
There are no negative capabilities (capabilities that limit what someone can do). You cannot deny a capability to anyone.
Some roles have implicit capabilities (capabilities that are bound to the role and are not displayed in the user interface). For example, members of the Metadata Server: User Administration role can create new users, but there is no explicit Create Users capability.
Contributing role relationships are monolithic. You cannot deselect a contributed capability. These relationships are also dynamic. A change to the capabilities of one role affects any roles to which the first role contributes its capabilities.
Permission settings on a role definition do not determine what that role can do. Those settings can affect the ability of other identities to update or delete the role definition itself. Special rules automatically protect user, group, and role definitions.

Main Administrative Roles

Introduction to Selected Administrative Roles

Role	Capabilities
Metadata Server: Unrestricted	Members have all explicit capabilities, all metadata server capabilities, and cannot be denied any permissions in the metadata layer. Unrestricted users can use only those logins that are assigned to them (or to groups to which they belong).
Metadata Server: User Administration	Members can create, update, and delete users, groups, roles (other than the unrestricted role), internal accounts, logins, and authentication domains. Restricted user administrators cannot update identities for which they have an explicit or ACT denial of WriteMetadata.
Metadata Server: Operation	Members can administer the metadata server (monitor, stop, pause, resume, quiesce) and its repositories (add, initialize, register, unregister, delete). Only someone who has an external user ID that is listed in the adminUsers.txt file with a preceding asterisk can delete, unregister, add, or initialize a foundation repository. Only an unrestricted user can analyze and repair metadata or perform tasks when the metadata server is paused for administration.
Management Console: Advanced	In SAS Management Console, members can see all of the plug-ins that are under role-based management (in the initial configuration).

Note: The metadata server's adminUsers.txt file provides many of the same privileges that it did in previous releases. However, we recommend that you use roles instead, except as specified in documentation for a particular task.

Note: The method that most applications use to retrieve credentials supports normal use of stored credentials, regardless of role memberships. However, if someone who has user administration capabilities makes a raw metadata request for logins, no usable passwords are returned.

CAUTION:

If the identity that the object spawner uses to retrieve server launch credentials from the metadata has the user administration role (or the unrestricted role), the spawner will not operate properly.

Do not give user administration capabilities to the identity that the object spawner uses to retrieve server launch credentials from the metadata. In a typical configuration, the spawner uses the SAS Trusted User to retrieve server launch credentials (through a raw metadata request).

Differences between Roles and Groups

Roles and groups serve distinct purposes. You cannot assign permissions to a role or capabilities to a group. Here are some additional distinctions:

The identity hierarchy is relevant for groups, but not for roles. If you are a member of a role, you have all of that role's capabilities, regardless of whether you are a direct member of that role and what your other memberships are.
You can deny a permission to a group, but you cannot deny a capability to a role. Each role either provides or doesn't provide each capability. No role takes capabilities away from its members.
A group's permissions are not displayed as part of a group definition, but a role's capabilities are displayed as part of a role definition.
A group can be a member of another group, but a role cannot be a member of another role. Instead, one role can contribute its capabilities to another role.

Availability of Application Features in a New Deployment

In general, the initial configuration provides appropriate access to application features. Most nonadministrative capabilities are available to either PUBLIC (everyone who can access the metadata server) or SASUSERS (those members of PUBLIC who have a well-formed user definition). To ensure appropriate availability of features for your applications, see the administrative documentation for each application.