SAS Viya Identity Management
Your identity to a computer system is one of the key factors that determine what you can and cannot do, or what you are "authorized" to do. In this article we will look at identity management in SAS Viya visual deployments (programing only deployments are different).
My colleague Stuart Rogers has covered in detail the authentication aspects of SAS Viya, how you get in. In this article we will look at how your identity determines what you can do once you have authenticated.
SAS Viya Visual deployments establish a user's identity by reading user and group information from an identity provider. For SAS Viya 3.2 LDAP based identity providers are supported, including Microsoft Active Directory, OpenLDAP or Apache Directory Server. Access to the identity provider can be configured in two ways:
- During deployment by entering the LDAP configuration information in SiteDefault.yml
- Post-deployment interactively with SAS Environment Manager
Learn more about how to configure the connection to the identity provider.
There are no users stored in SAS Viya, but a key feature is the ability within SAS Viya to create custom groups. Custom groups can be created that exist in SAS Viya and not in the authentication provider. This provides great flexibility in creating groups to manage access to resources within SAS Viya.
There are 4 pre-defined custom groups in SAS Visual Analytics on SAS Viya.
SAS Viya Pre-defined Custom Groups
In addition to the four pre-defined groups authenticated users is an implicit group to which all users who can authenticate to the system belong.
To slightly complicate things the CAS server also has group-like structures called roles. There is a CAS administrator (or super user ) role and a Data administrator role.
- CAS Roles determine the level of administrative access for CASLIB, table, column and action administration and authorization
- Custom groups determine the level of administrative access in SAS Environment Manager for general administration and authorization
CAS Roles and SAS Viya groups are related. By default in SAS Viya the SAS Administrator pre-defined group is included in the CAS Administrator role. Resulting in all SAS Administrators also being CAS Administrators.
CAS Roles and Role Membership in CAS Server Monitor
The table below shows the initial setup of the 4 SAS Viya pre-defined custom groups and what functionality they can access.
The SAS Administrators group is a special group called an assumable group. This means that a user can opt into that group to gain its elevated privileges. In SAS Environment Manager if you opt into the SAS administrators group at logon you may also assume the CAS administrator(or super user) role to administer the CAS server. My colleague Scott McCauley covered assumable groups in a previous article.
What a user or group can do (and see) is controlled by rules. A rule is a composite of authorization elements including:
- Target: a resource for example a folder or report
- Principal: user or group
- Permissions: type of access for example read or write
- Setting: indication of whether access is provided, for example grant or prohibit.
SAS provides an initial set of rules to control your users’ access to resources. These rules determine what the pre-defined custom groups can do and see. The screenshot below shows the default rules for the SAS Visual Analytics and SAS Visual Data Builder applications.
It shows that Authenticated Users (principal) can access SAS Visual Analytics (target) because Read (permission) is Granted (setting).
The DataBuilders pre-defined custom group(prinicpal) can access SAS Visual Data Builder(target) because Read (permission) is Granted (setting).
The general authorization system in SAS Viya implements a default deny to resources. A user cannot access a resource unless permissions is granted. For that reason, with the rules above applied, only members of the DataBuilders group can access the SAS Visual Data Builder application.
I hope this brief introduction to users and groups in SAS Viya will prove useful. In a follow up article I will go into more detail on rules, and show how you can create new groups and rules to change a user's access to functionality.
