In this article we will discuss a change that has been implemented as part of SAS Viya 2020.1.4. This change enables SAS Identities microservice to provide secondary group information in all scenarios. Secondary group information is key to being able to generate a useful operating system level security model. When you want to share folders or files between groups of users you will normally rely on this secondary group information. Initially, secondary group information was only provided when it was available as POSIX attributes from the LDAP provider. Now secondary group information is also available for SCIM providers and LDAP providers that do not have POSIX attributes.
This change is a patch level change so it will be applied with SAS Viya 2020.1.4 and previous stable releases at the same minor version. The change is only available if you a running a version of the Identities microservice greater or equal to 2.40.19-20210222.1614007307905. You can confirm the version of the Identities microservice by looking at the annotations for the Kubernetes pod. For example, the following kubectl command:
kubectl -n ${NS} get pods -l app=sas-identities -o jsonpath="{.items[].metadata.annotations['sas\.com/component-version']}"
Where ${NS} is your SAS Viya namespace, will output the sas.com/component-version string. This must be 2.40.19-20210222.1614007307905 or greater for the Identities microservice feature to be present.
What Does it Do?
We have three different scenarios to consider:
- Identities configured with a SCIM client (either Azure AD or OKTA)
- Identities configured with a LDAP provider that does not hold UID/GID etc
- Identities configured with a LDAP provider that holds UID/GID information
Let’s consider the third scenario where the configured LDAP provider has POSIX attributes for users and groups. In this scenario, SAS Viya 2020.1 (and later) has always been able to provide UID, GID, and secondary GID information via the /identities/users/{{username}}/identifier endpoint. So long as the sas.identities.providers.ldap.identifier.enabled configuration option is set to on, which is the default. This information is used, for example, by the SAS Compute Server to run the pod as the end-user. Remember, with customization, these POSIX attributes can also be leveraged by SAS Cloud Analytic Services.
Originally, for the other two scenarios where the Identities microservice is not able to query POSIX attributes only the UID and GID information was provided by the /identities/users/{{username}}/identifier endpoint. In these cases, the UID and GID for the end-user were generated by hashing the unique identifier for the user and mapping this hash value onto a numerical space. This meant that the UID and GID values would be the same and would also be the same on different environments. So, if you had dev, test, and prod the same UID/GID values would be generated on all environments. For example, with an Active Directory LDAP provider the /identities/users/{{username}}/identifier endpoint for a user will return:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<identityIdentifier version="1">
<links>
<link href="/identities/users/gelviyaadmin/identifier" method="GET" rel="self" type="application/vnd.sas.identity.identifier" uri="/identities/users/sgelviyaadminsadm/identifier"/>
<link href="/identities/users/gelviyaadmin" method="GET" rel="user" type="application/vnd.sas.identity.user" uri="/identities/users/gelviyaadmin"/>
</links>
<gid>721898284</gid>
<uid>721898284</uid>
</identityIdentifier>
The change introduced with 2020.1.4 means that for the first two scenarios where POSIX attributes are not queried, secondary GID values are now provided. The Identities microservice since LTS-2020.1 has provided a group GID value, based on hashing the group unique identifier, available from the /identities/groups/{{group}}/identifier endpoint. This information is now used alongside the LDAP or SCIM group membership information to populate the secondary GID information. For example, with an Active Directory LDAP provider the /identities/users/{{username}}/identifier endpoint for a user will now return:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<identityIdentifier version="1">
<links>
<link href="/identities/users/gelviyaadmin/identifier" method="GET" rel="self" type="application/vnd.sas.identity.identifier" uri="/identities/users/gelviyaadmin/identifier"/>
<link href="/identities/users/gelviyaadmin" method="GET" rel="user" type="application/vnd.sas.identity.user" uri="/identities/users/gelviyaadmin"/>
</links>
<gid>721898284</gid>
<secondaryGids>
<secondaryGid>974918760</secondaryGid>
</secondaryGids>
<uid>721898284</uid>
</identityIdentifier>
The secondary GID values are only generated for either LDAP or SCIM groups. They are not generated for custom groups. Also, the primary GID value is exactly the same as the generated UID; since in the Identities microservice there is no way to determine the primary GID.
Implications
So why do we care about secondary GID values? These are key to being able to generate a useful operating system level security model. When you want to share folders or files between groups of users you will normally rely on these secondary GID values. Also, since in the case where the Identities microservice is generating UID/GID the GID values are all unique is was practically impossible to secure file system content. Now though, in those first two scenarios we have useful secondary GID values that can be leveraged in designing the security model.
Also remember it is possible to provide override values for the generation of GID values for groups, which is covered in the documentation. This means that it is possible to provide the GID values that will be assigned to your LDAP or SCIM groups. Which will further simplify the creation of a file system security model.
Finally, while the system will not generate a GID value for custom groups in the scenario of using SCIM, an administrator could manually create additional SCIM groups. The administrator can use the REST API SCIM endpoints of the Identities microservice to create additional groups that do not exist in the SCIM client (either Azure AD or OKTA). These custom SCIM groups could then be used to further enhance the files system security model.
Conclusion
The addition of secondary GID values for scenarios where the Identities microservice is unable to query these from the LDAP provider will greatly simplify the creation of well-rounded security models. It is easy to confirm if your SAS Viya 2020.1.3 (or later) environment has the correct version of the Identities microservice to enable this feature, and its use does not require any further configuration.
