Chapter 3: Understanding Initial Authentication and Administering Users, Groups, and Roles

In default installations, the SAS Administrator is an
internal user account, created during deployment ([email protected])
SAS Administrator Identity
-has access to all SAS Management Console application capabilities
-has access to all SAS Environment Manager application capabilities
-has all capabilities provided by the metadata server regardless of metadata permission settings, due to membership of the Metadata Server: Unrestricted role
-can perform all user management functions and metadata administration tasks
-SAS does not recommend using this as an administrator b/c fake they will create their own unrestricted user
SAS Trusted User [email protected]
A service identity that can act on behalf of other users
-all spawners will use this to connect to Metadata servers
SAS Environment Manager Service Account [email protected]
-required for communications between the SAS Environment Manager agent and the SAS Environment Manager server
-enables SAS Environment Manager plug-ins to access the SAS Metadata Server
SAS Anonymous Web User [email protected]
A service identity that functions as a surrogate for users who connect without supplying credentials
-an optional account that can be used to grant web clients anonymous access to certain SAS Web Infrastructure Platform applications (SAS BI Web Services and SAS Stored Process Web Application)
-this anonymous account is configured with the SAS Deployment Wizard and is applicable only when SAS authentication is being used
-if web authentication is used, the web application server processes authentication requests, and this anonymous account has no effect
Authentication
the process of verifying the identity of a person or process for security purposes
Internal Accounts
-primarily used to connect to the metadata server and exist only in the metadata
-are authenticated by the metadata server
-created by the SAS Deployment Wizard and by the User Manager plug-in SAS Management Console or Administration page in SAS Environment Manager
By initial policy, these server-level settings for internal account policies are in effect:
-accounts do not expire and are not suspended due to inactivity
-passwords must be at least six characters, do not have to include mixed case or numbers, and do not expire
-the five most recent passwords for an account cannot be reused for that account
-there is no mandatory time delay between password changes
-after three failed attempts to log on, an account is locked. If an account is locked because of logon failures, further log on attempts cannot be made for one hour
-for an account that has a password expiration period, there is a forced password change on the first use after the password is reset by someone other than the account owner
an internal account has the format [email protected]
If you need to unlock an internal account and you have the necessary host access do the following:
1. Edit the adminUsers.txt file to create a new unrestricted user by adding the fully qualified user ID preceded by an asterisk. Restart the metadata server for the change to take effect
2.Log on to SAS Management Console with the new unrestricted user and unlock the account
3. Verify that the account is unlocked by logging on to SAS Management Console with the account

Remove the unrestricted user that you added from the adminUsers.txt file and restart the metadata server.

SAS Internal Authentication
1. At logon prompt, [email protected] and password are entered. The client sends those credentials to the metadata server for verification
2. The metadata server recognizes that the ID is for an internal account, 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 accepted using the SAS identity associated with the internal account
Internal authentication alone is not sufficient to allow a user access to a standard workspace server because
a host account is required
SAS 9.4 Authentication Mechanisms: External
-Host authentication (credential-based)
-Direct LDAP authentication
-Integrated Windows authentication
Web authentication
SAS 9.4 Authentication Mechanisms: Internal
-SAS internal authentication
-SAS token authentication
SAS Token Authentication
-is when the metadata server generates and validates a single-use identity token for each authentication event.
SAS Token Authentication enables the following SAS processing servers to accept users who are already connected to the metadata server:
-OLAP server
-stored process server
-pooled workspace server

The workspace server can also use SAS Token Authentication

SAS Token Authentication Steps
1. The user initiates a request that requires access to a target server (for example, a request in SAS Enterprise Guide to open a cube associated with the OLAP server). Using the existing connection to the metadata server, the client requests an identity token for the target server
2. The metadata server generates the token and returns it to the client
3. The client sends the token to the target server
4. The target server sends the token back to the metadata server for validation
5. The metadata server validates the token and returns an acceptance message and a representation of the user to the target server
6. The target server accepts the connection

diagram pg. 3-33

How Logons Are Used

pg. 34 -35

-to enable the metadata server to match an incoming user ID with a particular SAS identity (inbound use)
-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 (SAS Token Authentication)
-to enable clients to seamlessly obtain user credentials for disparate systems, for outbound use, logins are stored in Metadata: User ID, Password, Authentication domain
Information under slide on pg. 3-34
Disparate systems
computer data processing system that was designed to operate as a fundamentally distinct data processing system without exchanging data or interacting with other computer data processing systems.
Example of outbound use
is a DBMS (OracleAuth) or workspace server on a machine with separate authentication from where the metadata server resides
Outbounds Logons can be defined on the Accounts tab (in SMC) of individual and group identities and must include these items:
-a fully qualified external account
-password
-authentication domain
Clients use authentication domain assignments to determine
which credentials are valid for which servers. The target server validates the client-supplied credentials against its authentication provider
In most deployments of the platform for SAS Business Analytics, passwords for external accounts need to be stored in the metadata to support these types of access only:
-seamless access to an external database
-seamless access to the standard workspace server in a mixed provider environment where Integrated Windows Authentication and SAS token authentication is not applicatble
Authentication Domains
a SAS metadata object that pairs logons with the server definitions where those credentials are correctly authenticated

example: an oracle server definition and the SAS copies of Oracle credentials (outbound logons) have the same authentication domain value (for example, “OracleAuth”) if those credentials authenticate on that Oracle Server

password management pg. 3-37
What are Metadata roles?
-determine which user interface elements (such as buttons, tabs, and menu items) are visible to which users
-for example, role memberships determine who can see the Server Manager plug-in in SAS Management Console, or see the Compare Data Task as a menu choice in SAS Enterprise Guide
Applications that support roles include the following:
-SAs Add-In for MO
-SAS EG
-SAS MC
-SAS Studio
-SAS Web Report Studio
-Visual Analytics
Roles can be accessed and managed from the ____________________________ in SAS Environment Manager or the _____________________________ in SAS Management Console
-Administration page
-User Manager plug-in
T/F All applications have roles
-FALSE. Not all applications have roles
Capabilities pg. 3-41
-the various features in applications that are under role management
-each role has application capabilities that are assigned to it
SAS desktop applications connect to the metadata server using
connection profiles
Connection profiles are stored
-in files on the user’s desktop (locally on the user’s machine: C:UsersStudentAppDataRoamingSASMetadataServerProfile)
– in the above location, Java applicaitons have the connection information in .swa files and Windows applications are in a file named ConfigurationV71.xml (the versions might be different)
-but stored passwords are encrypted
Key points of metadata-based roles
-roles do not protect data or metadata
-roles control which features in a particular application are available to which users
-having a certain capability is not an alternative to meeting permission requirements
-capabilities are additive. There are no negative capabilities (capabilities that limit what a user can do).
-it is not possible to deny a capability (capabilities are either granted or not granted)

for example, if a group is in two roles, that group has all the capabilities from both roles

Differences between roles and groups:
-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
-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
-you cannot assign permissions to a role. You cannot assign capabilities to a group
The initial configuration of the software includes some predefined roles.
-if these roles meet your needs, assign the correct membership
-if these roles do not meet your needs, create new roles, assign appropriate membership, and explicitly select application capabilities and designate contributing roles

*do not change the name of predefined roles

There are two predefined roles:
-Management Console: Advanced
-Management Console: Content Management
Management Console: Advanced role
-provides access to the Folders tab and all of the plug-ins under role management
-Default member: SAS Administrators
Management Console: Content Management role
-provides access to the Folders tab, User Manager, Library Manager, and Authorization Manager plug-in
-Default member: SASUSERS
The capabilities for the SAS Management Console roles also affect controlling access to modules on the Administration page of SAS Environment Manager:
-Data Library Manager controls access to the Libraries module
-Folders View controls access to the Folders module
-Server Manager controls access to the Servers module
-User Manager controls access to the Users module
Only unrestricted users can access the _____________ in SAS Management Console
Plug-in Manager
In order to control which SAS Management Console plug-ins (and the Folders tab) are under role management, select
Tools, Plug-in Manager
only unrestricted users can access the Plug-in Manager
In addition to the client application roles, the following implicit metadata server roles are defined at installation:
-Metadata Server: Unrestricted
-Metadata Server: User Administration
-Metadata Server:Operation
Metadata Server: Unrestricted role
All capabilities provided by the metadata server regardless of metadata permission settings
-unrestricted users can use only those logons that are assigned to them (or to groups to which they belong). They do not automatically have implicit capabilities that are provided by components other than the metadata server
Metadata Server: User Administration role
Create, update, and delete users, groups, roles, internal accounts, logins, and authentications domains
Metadata Server: Operation
Administration of the metadata server (monitor, stop, pause, resume, quiesce) and its repositories (add, initialize, register, unregister, delete)
The metadata server roles have implicit capabilities. This means…
that the default capabilities for these roles cannot be viewed or modified. However, additional capabilities can be added to these roles.
Administrative users have special abilities and privileged access to metadata based on their assignments to roles. There are two basic levels of administrative users:
-Administrators
-Unrestricted Users
Administrative user: Administrators
-have metadata access capabilities that a typical end user does not have
-are subject to metadata layer access controls
Administrative user: Unrestricted Users
-have unrestricted access to metadata
-can perform tasks when the metadata server is paused for administration
Many administrative tasks have permission requirements in addition to capability requirements. For example, to operate servers other than the metadata server, you need the
Administer permission
If a user needs to function as both an administrator and as a non-administrator, create two user definitions as follows:
-one definition that is based on an internal account and is a member of the SAS Administrators group, and if needed, the Metadata Server: Unrestricted role
-another definition based on an external account and NOT a member of the SAS Administrators group
pg. 3-45? Controlling Access to Environment Manager
Native users are…
-created by first creating the user definition in metadata and then synchronizing the user information with SAS Environment Manager
-you cannot create or edit native user definitions in SAS Environment Manager directly
Native roles enable…
-you to grant capabilities and permissions for actions in SAS Environment Manager to selected users
-for example, an administrator role could be granted full permissions for all resource types and the ability to acknowledge and fix alerts, while a guest role could be denied the ability to fix or acknowledge alerts and have only Read permission for resources
-assigning a native role to a native user determines the actions that the user can perform in SAS Environment Manager
-each native role also has its own unique Dashboard page. Each user has access to their own personal Dashboard page and the Dashboard pages of all native roles of which they are a member
Environment Manager controls access and permissions within the applications with its own registry of users and its own system of roles and permissions. Steps:
Step 1: user accesses http://:7080 in browser
Step 2: Request is redirected to the SAS Logon Manager application for authentication
Step 3: User is authenticated by the metadata server
Step 4: Request is passed on to SAS EV Server
Step 5: User is again authenticated in SAS EV, and his/her Role membership determines what he/she can do in SAS Environment Manager
A connection profile is
-a file stored locally on the user’s machine: C:UsersStudentAppDataRoamingSASMetadataServerProfiles
-contains the information necessary for connection to the metadata server, such as the metadata server host name and port
Connection information is stored in different files for Java applications and Windows applications. Where are they?
-Java applications have the connection information in .swa files
-Windows applications are in a file named ConfigurationV71.xml
Web-based applications connect to the metadata server through the
-SAS Logon Manager
SAS Logon Manager
-web application that handles all authentication requests for SAS web applications
-as a result, users see the same sign-in page when they access any of the SAS web applications
Initial connection to the SAS Metadata Server by providing credentials – Example Ahmed pg. 3-5
1.Ahmed supplies credentials to log on to the metadata server
2.The metadata server passes Ahmed’s credentials to its host authentication provider. By default, the metadata server passes the credentials to its host. If the accounts are local, they are verified by the host. The host can also be configured to pass the authentication requests to LDAP or Microsoft Active Directory.
3. The authentication provider verifies that the credentials are valid and returns the fully qualified user ID (sasserverAhmed) to the metadata server – does NOT return the password. The form of the fully qualified user ID varies depending on the authentication provider. If the account is a UNIX account, the returned user ID is Ahmed, for example.
4. The metadata server searches for the fully qualified user ID in the metadata repository (inbound logon)
5. The metadata server determines which metadata identity owns the user ID. Based on the metadata identity, the metadata server can determine what level of access Ahmed has to the metadata. Access to the metdata server is set in the repository ACT (access control template) Only users with ReadMetadata and WriteMetadata in the repository ACT, named Default ACT by default, are allowed to connect to the metadata server
6. The metadata server sends a credential handle to the application so that when the application requests information from the metadata server, it can pass the handle. The metadata server then knows the metadata identity of the user.
Initial connection using Integrated Windows Authentication (IWA)
1. The client asks Windows for a token that represents the user who is currently logged on to the client computer
2. Windows provides the token to the client
3. The client sends the Windows token to the metadata server. The user’s password is not available to the metadata server
4.The metadata server sends the token back to Windows for verification
5. Windows tells the metadata server that the token is valid
6. The metadata server identifies the user and verifies that the user was granted access to the metadata in the repository ACT
7. The metadata server accepts the connection from the client
For accountability, each person who uses the SAS environment should have
an INDIVIDUAL SAS metadata identity
Benefits of having each person who uses the SAS environment having an individual SAS metadata identity:
-control over a user’s access to application features and resources
-ability to audit individual actions in the metadata layer
-access for each user to a personal folder in the repository
A user’s metadata identity includes a copy of
the external account that the user uses to log on to SAS applications
The metadata server enforces certain identity- related constraints. What are they?
-you cannot create a user definition that has the same name as an existing definition (the display names do not have to be unique)
-you cannot assign the same fully qualified external account to two different identities
-all of the logons that include a particular ID must be owned by the same identity. This requirement enables the metadata server to resolve each ID to a single identity. This requirement is case INsensitive and applies to the fully qualified form of the ID
-avoid using spaces or special characters in names
To enable multiple users to share an account…
store the credentials for that account in a log on as part of a group definition. Then add the users who share the account as members of that group definition
If you give a user two logons that contain the same ID, the logons must be associated with a different
authentication domains
For administration and ease of maintenance and accountability, you should create ______________ identities
group
Groups can be used to do the following
-assign permissions
-share credentials
-populate roles
The following groups are predefined:
-PUBLIC
-SASUSERS
PUBLIC
group with implicit membership that includes everyone who can access the metadata server
SASUSERS
group with implicit membership that includes the members of the PUBLIC group who have an individual metadata identity
All of the user’s group memberships are part of the user’s
identity
Two ways to define user and group identities
-manually, using the User Manager plug-in in SAS MC or the Administration page in SAS EV
-using the user import macros supplied by SAS to import identity information from an authentication provider
The user import macros enable
the batch import and synchronization of user and group identity information from an authentication provider such as LDAP into the SAS metadata
The user import macro process follows these general steps
-extract information from your authentication provider
-extract information from the SAS metadata
-compare the sets of tables and identify additions and updates that need to be made to the metadata
-validate the changes
-load the updates into the metadata
diagram pg. 3-18?

*backup the metadata before synchronizing user or group information

The synchronization process performs two extractions. What are they?
-one from your authentication provider
-one from the SAS metadata
The synchronization process performs two extractions, and then
loads validate updates into the metadata
An external identity is a
value used to map the user information in the SAS metadata to the information from the authentication provider
An external identity must
-be unique to each user or group and unchanging
-must exist as a field in the user or group information in the authentication provider and in the SAS metadata
-is used during the synchronization process to compare information stored in metadata to information from the authentication provider
If you need to perform periodic synchronization and want existing users and groups that you created manually to be included in the process, then…
add the appropriate external identity value to the user or group metadata identity
Most SAS identities have stored, __________________________________ as part of their metadata definitions.
external IDs
Most SAS identities have stored, external IDs as part of their metadata definitions. The external IDs are used for…
-authentication to the SAS Metadata Server
-The identites use these credentials when logging on to SAS applications, such as SAS Enterprise Guide, SAS Web Report Studio, or SAS Information Delivery Portal