Now I see you, now I don’t. How to prevent users from seeing other users.

[#1]

In a recent question on communities.sas.com, someone asked whether it is possible to limit the users or groups a user can see. The API for the identities service, that provides this information is not public. However any user could make use of the sas-viya CLI to list this information. Depending on the setup, phone numbers or addresses etc. might be shown.  This might not be something you want.

In this post we will look at configuration settings that allow an administrator to control what non-administrative users can see when they make use of the sas-viya CLI identities plugin to list users and groups or show details about a user.

Topics we will look into

• Overview of properties
• Example for each configuration property
• Are there any side effects
• How to set the properties using the sas-viya CLI

Overview of properties

The following table, from the documentation,  shows the configuration properties of the Identities service that will change what the non-administrative users can see. These options are available since LTS 2023.10. Note that by default none of the properties are enabled.

Property	Default Value	Definition
endpoints.secured.groups:	not enabled by default	When enabled, limits non-administrative users’ Read access for groups.
endpoints.secured.members:	not enabled by default	When enabled, limits non-administrative users’ Read access for group members.
endpoints.secured.memberships:	not enabled by default	When enabled, limits non-administrative users’ Read access for group and user memberships.
endpoints.secured.users:	not enabled by default	When enabled, limits non-administrative users’ Read access for other users.

You can find these settings in the SAS Environment Manager -> Configuration page

Please note, there is a new checkmark icon beside the pencil icon that indicates whether the default is used or it has been modified (no checkmark icon).

Example for each configuration property

We will look at the effect each property has.

Please note: there is a delay from enabling the property to it being applied, allow for 10-20 seconds before checking the result.

Impact of endpoints.secured.users

When this configuration property is enabled a non-administrative user will only see itself when asking for a list of users.

See here a screenshot with disabled / enabled results. The sas-viya command shown in the screenshots uses the profile eric (-p eric), this means all the commands run as user eric.

When enabled you can no longer show detailed information for another user. Example:

By enabling the endpoints.secured.users property, you prevent non-administrative users from seeing details of other users, or even that other users exist. In the above example we can see that eric can view the user eric (himself), but he can not view the information for another user (christine). This might already be all you need.

Impact of endpoints.secured.groups

When this property is disabled (default) a non-administrative user will see all the groups when using a command like this:

sas-viya -p eric identities list-groups

When this property is enabled only the groups the user is a member of, either directly or through group membership, are displayed:

In the example above the user eric has the following group memberships:

Impact of endpoints.secured.members

So far we have seen the impact of the endpoints.secured.users and endpoints.secured.groups properties. The user can still list all members of a group he belongs to. Example:

When endpoints.secured.members is enabled, the same command will only list the user that makes the request:

Impact of endpoints.secured.memberships

The sas-viya CLI identities plugin has a command list-memberships that allows to either provide a user (--user-id) or a group (--group-id) to list their memberships. When this property is enabled (all others are disabled) a non-administrative user can only see groups:

• of which the current user and the given user (--user-id) are both members
• of which the current user and the given group (--group-id) are both members

Example:

• The first command is run as eric requesting to see memberships of user delilah. Only the group NestedGroup01 is displayed since delilah is a direct member of NestedGroup01 and eric is a member of NestedGroup02 which is a member of NestedGroup01.
• The second command is run as SAS administator so all groups where delilah is a member of are displayed.

In other words, when the endpoints.secured.memberships property is enabled, the current user can only see groups which a named user or group is in, where the current user is also a member of those groups. So if the named user or group is a member of one or more groups that the current user is not a member of, the current user cannot see that the named user or group is a member of those other groups.

Are there any side effects

Will the above settings have any side effects. Yes they will! Below are some examples of functionality impacted.

• Can I still share SAS Content objects like a Visual Analytics report? Yes this is possible.
• Can I still distribute a Visual Analytics report to other users? No!
  Since you no longer can read specific user information for other users, it is not possible to read for instance the email address from another user, so you will get an error as shown below.
  

  This is not a complete list of side effects. This is the reason, why these configuration properties are not enabled by default. You have to decide what will work for you and which side effects you can live with, when enabling these configuration properties.

  How to set the properties using the sas-viya CLI

  Configuration properties can be set using the Configuration page in SAS Environment Manager. But often it is desirable to do this using a scipt. See here for the steps necessary to do this.

  Read the mediatype for what we want to change and store it in an environment variable

  MEDIATYPE=$(sas-viya configuration configurations download -d sas.identities | jq -r '.items[]["metadata"]["mediaType"] ')

  Next create a JSON file with the properties we want to change

  tee /tmp/update_identities_settings.json > /dev/null << EOF
  {
  "name": "identities configurations",
  "items": [
  {
  "metadata": {
  "isDefault": false,
  "mediaType": "${MEDIATYPE}"
  },
  "endpoints.secured.users": true,
  "endpoints.secured.groups": true,
  "endpoints.secured.members": true,
  "endpoints.secured.memberships": true
  }
  ]
  }
  EOF

   

  Update the configuration instance

  sas-viya configuration configurations update --file /tmp/update_identities_settings.json

  Verify the settings

  CFG_ID=$(sas-viya configuration configurations download -d sas.identities | jq -r '.items[]["id"] ')
  
  sas-viya configuration configurations show --id $CFG_ID
  

  The output looks like this:

  sas-viya configuration configurations show --id $CFG_ID
  id : 0da33450-35e0-4b23-bbe1-3fa78a042ab1
  metadata.isDefault : false
  metadata.mediaType : application/vnd.sas.configuration.config.sas.identities+json;version=5
  metadata.services : [identities]
  cache.cacheRefreshInterval : 12h
  cache.enabled : true
  cache.providerPageLimit : 1000
  defaultProvider : local
  endpoints.secured.groups : true
  endpoints.secured.members : true
  endpoints.secured.memberships : true
  endpoints.secured.users : true
  identifier.disableGids : false
  identifier.disallowedUids : 1001
  identifier.generateGids : false
  identifier.generateUids : false
  identifier.homeDirectoryPrefix : /home

  Summary

  By default any user can get a list of all users and groups. Any user can display the details about another user, or list the members of a specific group. By enabling the named properties the administrator can restrict the access for a non-administrative user to only himself and the groups he is a member of (direct or indirect). Some functionality within SAS applications might be affected.

  Find more articles from SAS Global Enablement and Learning here.

[ronan]

Thanks for sharing, @BrunoMueller . Security auditors warned us such unsecured endpoints could expose sensitive information and pose as a threat. Therefore we disabled as shown above. CLI sample codes are especially useful for direct implementation, thanks ! Besides VA sharing user list discovery, are there any negative impacts with Group-managed Service account scheduling, since  restricted users cannot in theory retrieve the Service Account user info from the predefined Service account group , once identities endpoints are secure ? See https://communities.sas.com/t5/SAS-Communities-Library/SAS-Viya-CLI-with-Group-Managed-Service-Accou...  .

[BrunoMueller]

@ronan Yes this will impact the use of Group-Managed Service Account

For instance in the Monitoring tab you can not longer select the service account to see the executed jobs.

If you try the "Run as" action in the Scheduling tab you will receive this error:

As mentioned because of unwanted side effects, these properties are not enabled by default.

There might be a way using rules. This will be additional maintenance and possibly have a performance impact. I have not investigated this any further but it is worth a try.

[ronan]

Thanks for the feedback, this confirms a previous result I was unsure of.