A SAS consultant asked me if it would be possible to create a 'User Administrators' group in SAS Viya, whose members could manage users (i.e. add and remove members of custom groups, refresh the identities cache etc.) but are not otherwise full SAS Administrators. This is an excellent idea, and I think lots of other people would like to do the same.
Today, I'll show you how to set up such a custom group. For convenience of automation I'll show the steps using the sas-viya CLI. However, if you prefer you can easily do this all in SAS Environment Manager's Users and Rules pages. You can even do some steps in Environment Manager and some using the CLI; whichever suits you best.
This should work in both SAS Viya 3 and in SAS Viya 2020.1 and later. The only difference is in the name of the SAS Viya CLI command you use to create the group, grant permissions to it and add users to it. If you are using SAS Viya 3, the CLI is sas-admin. If you are using SAS Viya 2020.1 or later, it's sas-viya. I will use sas-viya in this post. Everything else about each command is exactly the same in both SAS Viya 3 and in SAS Viya 2020.1 and later.
Before you can create a group, grant permissions to it and add users to it, you will need to authenticate to the SAS Viya CLI for your release of SAS Viya (from here on, I'll just call it the sas-viya CLI) as a user who is in the SAS Administrators custom group.
If you're new to the sas-viya CLI, @GerryNelson wrote a nice post explaining this for the SAS Viya 3 sas-admin CLI, and also showed how to make it easier using the loginviauthinfo.py pyvyatool and a .authinfo file in the .netrc format: Automating post-deployment Viya tasks with REST and the administration CLI. The steps are the same with the sas-viya CLI. I'm using loginviauthinfo.py, and in our GEL workshop environments, we clone the pyviystools project into /opt/pyviyatools, so I first run:
/opt/pyviyatools/loginviauthinfo.py
Example output:
[user@hostname ~]$ /opt/pyviyatools/loginviauthinfo.py Logging in with profile: gelcorp Getting Credentials for: gelcorp.hostname.race.sas.com Enter credentials for https://gelcorp.hostname.race.sas.com: Login succeeded. Token saved. [user@hostname~]$
The user in my .authinfo file is called geladm, and is a member of the SAS Administrators group. You will see "createdBy": "geladm" in some of the example output that follows.
Members of this group will be able to administer users in your SAS Viya deployment, without being SAS Administrators:
sas-viya identities create-group --id UserAdministrators --name "User Administators" --description "Users who can administer identities, but are not full SAS Administrators"
The command shows you the whole JSON output of the new group, which is quite big because it includes all the 'links' indicating API actions that can be performed on the group. I will replace those links here with just '...', for the sake of brevity:
[user@hostname ~]$ sas-viya identities create-group --id UserAdministrators --name "User Administators" --description "Users who can administer identities, but are not full SAS Administrators" { "creationTimeStamp": "2022-04-07T15:29:01.236Z", "description": "Users who can administer identities, but are not full SAS Administrators", "gid": 0, "id": "UserAdministrators", "links": [ ... ], "modifiedTimeStamp": "2022-04-07T15:29:01.236Z", "name": "User Administators", "providerId": "local", "state": "active", "version": 1 } The group was created successfully. [user@hostname ~]$
We have a group with id:UserAdministrators, let's grant it some permissions.
Following this page in the documentation, we create a new authorization rule targeting the URI /SASEnvironmentManager/identities, used to grant the group access to see (i.e. read) the Users page in SAS Environment manager:
sas-viya authorization grant --object-uri /SASEnvironmentManager/identities --group UserAdministrators --permissions read --description "UserAdministrators can see the Users page"
Example output:
[user@hostname ~]$ sas-viya authorization grant --object-uri /SASEnvironmentManager/identities --group UserAdministrators --permissions read --description "UserAdministrators can see the Users page" { "acceptItemType": "", "acceptType": "", "contentType": "", "createdBy": "geladm", "creationTimestamp": "2022-04-07T15:39:16.911Z", "description": "UserAdministrators can see the Users page", "enabled": true, "id": "86e3177f-ce00-4296-bcb9-526743210c24", "mediaType": "", "modifiedBy": "geladm", "modifiedTimestamp": "2022-04-07T15:39:16.911Z", "objectUri": "/SASEnvironmentManager/identities", "permissions": [ "read" ], "principal": "UserAdministrators", "principalType": "group", "reason": "", "type": "grant", "version": 10 } The authorization rule has been created. [user@hostname ~]$
For all the next authorization grant rules, the expected output is quite similar to this, so I won't show it for them. Just look for 'The authorization rule has been created.' at the end.
The following commands grant the user almost the same permissions to do things with the SAS Viya Identities service that SAS Administrators have. We just skipped one that is not necessary for members of our User Administrators group:
sas-viya authorization grant --object-uri /identities/cache/** --group UserAdministrators --permissions "create,delete,update,remove" --description "UserAdministrators can manage the identities cache." sas-viya authorization grant --object-uri /identities/** --group UserAdministrators --permissions read --description "UserAdministrators can see identity information." sas-viya authorization grant --object-uri /identities/groups/*/identifier --group UserAdministrators --permissions read --description "UserAdministrators can query their group identifier." sas-viya authorization grant --object-uri /identities/groups/** --group UserAdministrators --permissions "create,delete,update,remove" --description "UserAdministrators can manage identities."
All being well, you should get similar JSON output followed by 'The authorization rule has been created.' for each of those four commands.
We do not use prohibit rules very often in SAS Viya, for two reasons. It's better to not grant a permission to someone if you do not want them to have it, by making the rules you do grant more selective or precise. And because 'prohibit always wins', or in other words because a prohibit will always take precedence over any other conflicting rule, they can easily have an unintended consequence of denying something to an identity like SAS Administrators who needs that permission. So, be careful not to expand the principle you use in a prohibit rule to include SAS Administrators, or Authenticated Users of which your SAS Administrator users are also members. Similarly, don't expand the prohibit rules below to apply to anything other than groups like SASAdministrators whom our new User Administrators group must not be able to modify.
Having understood the need for great care here, if you also create the following prohibit rules, members of the User Administrators group will be unable to modify the SAS Administrators group. (There are already rules that prevent anyone from deleting SAS Administrators):
sas-viya authorization prohibit --object-uri /identities/groups/SASAdministrators/members/* --group UserAdministrators --permissions "create,delete,update" --description "UserAdministrators cannot add or remove members of the SASAdministrators group." sas-viya authorization prohibit --object-uri /identities/groups/SASAdministrators/userMembers/* --group UserAdministrators --permissions "create,delete,update" --description "UserAdministrators cannot add or remove members of the SASAdministrators group." sas-viya authorization prohibit --object-uri /identities/groups/SASAdministrators/groupMembers/* --group UserAdministrators --permissions "create,delete,update" --description "UserAdministrators cannot add or remove members of the SASAdministrators group."
Here are all seven new rules that apply to the new User Administrators group, shown in the SAS Environment Manager Rules page. Instead of running the CLI commands above, you could alternatively just use the New Rule button on this page to create each of the rules:
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
To test whether the new User Administrators group works, we will make someone who is not a member of the SAS Administrators custom group a member of User Administrators. In my environment, I'm going to choose the user Hazel, but obviously you should substitute Hazel's userid below for a user in your SAS Viya deployment:
sas-viya identities add-member --group-id UserAdministrators --user-member-id Hazel
Example output:
Hazel has been added to group UserAdministrators
Have your new User Administrator sign in to SAS Environment Manager and test whether they can modify membership of any custom group except SAS Administrators, and refresh the identities cache. I'll sign in to my workshop environment as Hazel.
Having been added to the newly-created User Administrators group, Hazel is now able to see the Users page in SAS Environment manager, and can modify the members of any custom group except SAS Administrators.
You will notice that the 'Edit' button is still enabled for Hazel for the SAS Administrators group, and clicking it opens the 'Edit Members for SAS Administrators' dialog. In that dialog, it appears as if Hazel would be able to make herself a member of the group, or remove existing members of SAS Administrators. Hazel can even click the OK button in the edit dialog, and the dialog closes without an error message. However, no changes to the SAS Administrators group's membership can actually made. (There is already a rule that prevents anyone - the principal type 'Everyone' - from deleting the SAS Administrators group.)
Here is a new custom group that Hazel has created:
My thanks to my SAS colleagues Todd Chinigo and Gary Williams for reviewing the authorization grants in this post, and proposing the rules to prevent User Administrators from modifying the SAS Administrators group's membership.
If you have users who can be trusted to act as a limited user administrator, you can now set up a custom group which grants that capability to users without having to make them members of the SAS Administrators group, and without letting them make themselves or anyone else full SAS Administrators. The process is almost exactly the same in SAS Viya 3 and SAS Viya 2020.1 and later.
See you next time!
Find more articles from SAS Global Enablement and Learning here.
Thanks for sharing @DavidStern , this is very useful. It looks quite like the "Metadata Server: User Administration role" with SAS 9.
Thank you @ronan! Yes, I think it is similar to that role.
Registration is now open for SAS Innovate 2025 , our biggest and most exciting global event of the year! Join us in Orlando, FL, May 6-9.
Sign up by Dec. 31 to get the 2024 rate of just $495.
Register now!
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.