SAS Administrator: Access to All Capabilities

internal user account, created during deployment (sasadm@saspw)

-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

A service identity that can act on behalf of other users -all spawners will use this to connect to Metadata servers

-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

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

the process of verifying the identity of a person or process for security purposes

-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

-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 userID@saspw

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.

1. At logon prompt, sasadm@saspw 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

a host account is required

-Host authentication (credential-based) -Direct LDAP authentication -Integrated Windows authentication Web authentication

-SAS internal authentication -SAS token authentication

-is when the metadata server generates and validates a single-use identity token for each authentication event.

-OLAP server -stored process server -pooled workspace server The workspace server can also use SAS Token Authentication

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

-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

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.

is a DBMS (OracleAuth) or workspace server on a machine with separate authentication from where the metadata server resides

-a fully qualified external account -password -authentication domain

which credentials are valid for which servers. The target server validates the client-supplied credentials against its authentication provider

-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

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

-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

-SAs Add-In for MO -SAS EG -SAS MC -SAS Studio -SAS Web Report Studio -Visual Analytics

-Administration page -User Manager plug-in

-FALSE. Not all applications have roles

-the various features in applications that are under role management -each role has application capabilities that are assigned to it

connection profiles

-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

-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

-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

-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

-Management Console: Advanced -Management Console: Content Management

-provides access to the Folders tab and all of the plug-ins under role management -Default member: SAS Administrators

-provides access to the Folders tab, User Manager, Library Manager, and Authorization Manager plug-in -Default member: SASUSERS

-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

Plug-in Manager

Tools, Plug-in Manager only unrestricted users can access the Plug-in Manager

-Metadata Server: Unrestricted -Metadata Server: User Administration -Metadata Server:Operation

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

Create, update, and delete users, groups, roles, internal accounts, logins, and authentications domains

Administration of the metadata server (monitor, stop, pause, resume, quiesce) and its repositories (add, initialize, register, unregister, delete)

that the default capabilities for these roles cannot be viewed or modified. However, additional capabilities can be added to these roles.

-Administrators -Unrestricted Users

-have metadata access capabilities that a typical end user does not have -are subject to metadata layer access controls

-have unrestricted access to metadata -can perform tasks when the metadata server is paused for administration

Administer permission

-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

-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

-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

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 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

-Java applications have the connection information in .swa files -Windows applications are in a file named ConfigurationV71.xml

-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

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.

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

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

the external account that the user uses to log on to SAS applications

-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

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

authentication domains

group

-assign permissions -share credentials -populate roles

-PUBLIC -SASUSERS

group with implicit membership that includes everyone who can access the metadata server

group with implicit membership that includes the members of the PUBLIC group who have an individual metadata identity

identity

-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 batch import and synchronization of user and group identity information from an authentication provider such as LDAP into the SAS metadata

-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

-one from your authentication provider -one from the SAS metadata

loads validate updates into the metadata

value used to map the user information in the SAS metadata to the information from the authentication provider

-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

add the appropriate external identity value to the user or group metadata identity

external IDs

-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