General Authorization Essentials Part 2: Functionality
In SAS Viya, there are two authorization systems, one for the Cloud Analytics Services server and other for the General Authorization components. The CAS authorization layer deals with access to the in-memory analytics engine and its data, while the General Authorization layer controls access to content and functionality in other parts of SAS Viya. Understanding both authorization systems will help ensure the security for the entire SAS Viya system. This series of posts will cover the essentials of securing content and controlling access to functionality so that you will be equipped to perform one of the common SAS Viya administration tasks: securing the environment.
Links
General Authorization Essentials Part 1
General Authorization Essentials Part 1: Content | SAS Communities
Simple general authorization patterns
CAS Authorization Documentation
General Authorization Documentation
The Rules Page
https://go.documentation.sas.com/doc/en/sasadmincdc/default/evfun/n1uw3er96phzpfn1pxvnf01f6sw3.htm
Authorization Overview
Functionality in SAS Viya
When we discuss the concept of functionality in SAS Viya, we mean access to applications, selected features, and selected components. In the first part of this series on general authorization we learned about how to control access to objects like reports, SAS programs, or other content information stored within the SAS Viya folder structure.
General Authorization Concept Reminders
Several concepts carry over and apply when controlling access to functionality. Principals are the identities to which rules apply and allow or disallow access to endpoints or interface elements. General authorization makes sure that someone is allowed to perform a given action when they attempt it.
Principals refer to users, groups, or custom groups. A best practice is to use groups or custom groups and then adding or removing users from those groups, making maintenance of the system easier in the future.
Remember also that there is an Authenticated Users principal which refers to all the users who can successfully sign-in to SAS Viya. Rules can target this principal too.
Basic Approach in Controlling Access to Functionality
The general authorization security model inherently secures SAS Viya. By design, access that is not granted is implicitly disallowed. There are some predefined groups that exist that can grant access to components or features. See this link for more information on the predefined custom groups and the functionality to which they grant access: SAS Help Center: Identity Management: Reference
If these groups are appropriate for your needs, your security tasks will be to assign users to those custom groups. If you need additional customization, read on.
Targeting URIs to Modify Access to Functionality
Remember that authenticated users have a default level of access that is usually appropriate for default users of the software. It is recommended to leave Authenticated Users as the principal in rules that control functional access. However, if after careful review you want your environment to modify that default access, you’ll need to modify the rules that control this access to functionality.
An important item of note: when you modify access to applications, this does not affect access to underlying services. For example, modifying a principal’s access to SAS Environment Manager might still allow them to access SAS Content folders through another interface.
Begin by identifying the access that you want to enforce. Do you want all users to be able to export PDF reports to their local machines? Do you want anyone to be able to upload data to CAS? Do you want all authenticated users to be able to edit reports? Plan out the access levels to give to various business units or teams in your organization.
Then you will need to identify the URI that targets the functionality that you want to modify or restrict for these access levels. There are documented URIs, which you can see here for a list of published Application URIs SAS Help Center: Access to Functionality: Application URIs. Some of those URIs support fine-grained functionality targeting, and you can find functional URI references for applications, components, or features.
Some examples of those URIs mentioned above:
| Application, Component, or Feature | URI |
| Export Visual Analytics reports as PDF. | /reportRenderer/reports/** |
| Show the Import tab in SAS Data Explorer | /casManagement_capabilities/importData |
| Create and edit reports. | /SASVisualAnalytics_capabilities/edit |
See here for more information on working with URIs: Uniform Resource Identifiers (URI) in SAS Viya - SAS Support Communities
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Key Points about Prohibits and Authenticated Users
Harkening back to the first part of this series, a reminder that SAS documentation recommends minimizing the use of prohibit rules. That includes never prohibiting Authenticated Users. Prohibit rules have absolute precedence and can even deny SAS Administrators from access.
Instead, use selective grants to provide access to other principals instead of Authenticated users. Simply change the principal from Authenticated Users to another group or custom group. This goes back to one of the primary tenants of authorization in SAS Viya: any access that is not granted is implicitly disallowed.
SAS Administrators already have a universal grant through an existing rule, and you don’t need to add additional rules to grant them access.
Taking it Further
There are many URIs in SAS Viya, and you can make more extensive changes by looking over the rules page in SAS Environment Manager. You can see the list of existing rules that target various URIs.
Not only can you replace principals on these rules, but also edit them in other ways such as making copies, changing permissions, or even deleting rules. Rules can also have conditions on them, only granting access based off the originating IP address, or removing access on the weekends. More information here: SAS Help Center: General Authorization: Concepts
An advanced user can also attempt to work with URIs that are not documented. You can use developer.sas.com to understand the structure of a service before attempting to build a Target URI for a bit of functionality dealing with that service.
There is also a page named the Capabilities page in SAS Environment Manager, which shows content if you license a product that uses capabilities. Currently, capabilities can only be viewed at this time.
In general, access to functionality is controlled by the Read permission. Some predefined rules grant additional permissions. You can view a rule’s description for more information or details about a rule.
Don’t forget to perform backups before and after you make significant changes to your system. Managing access to functionality can be a complex task. Test your changes to make sure you do not introduce unintended effects.
Find more articles from SAS Global Enablement and Learning here.
