In my previous post, Group-based access to Azure Files in the new SAS Viya, I walked through an example of making one or more Azure File Shares available to SAS Viya end user sessions with a group-based access pattern.
This post extends the scenario and covers the case where we configure a SAS Viya environment to an identity provider that does not provide POSIX attributes for determining membership. In the example environment, the SAS Identities Service has been configured to accept users and groups pushed from Azure Active Directory. We will use the more-likely scenario where we have not enabled Azure Active Directory Domain Services, which would allow communication over LDAP protocols. Instead, we will rely on the default and more cloud-native SCIM protocol.
SCIM explained, briefly
While the details of SCIM are out of scope for this post, at its core SCIM (System for Cross-domain Identity Management) is a REST- and JSON-based communication protocol. It touts the benefits of being a more standardized, secure, and automation-ready solution for identity management than its alternatives. All of these characteristics make it an ideal choice for cloud-native solutions and platforms like SAS Viya on Kubernetes. Learn more about configuring SAS Viya on Kubernetes to use a SCIM client for identity management in this series of SAS Community articles by my colleague Stuart Rogers.
When choosing to use a SCIM client, such as Azure Active Directory or Okta, as your identity provider for SAS Viya, you'll need to be aware of the implications that will impact SAS user flows. One such ramification is that the SCIM client will provide no POSIX attributes to determine group membership. In my last post, we created Kubernetes persistent volume(s) to specify how to mount Azure File Share(s) into our Pods. We defined which POSIX group owned the mount in the PV manifest.
But in this case, what GID should we specify to ensure that we have a group-based access model when we don't know what POSIX groups the user is in? That's where these additional steps come in, valid at version 2020.1.4 and above. After you complete them, you can continue on with creating your Persistent Volumes, Persistent Volume Claims, transformers, and other necessary components to make the data available to end user sessions, just as we did in the previous post.
Creating your Custom Group
Since we will not have POSIX group memberships from our SCIM client, we rely on the SAS Viya General Authorization System to create Custom Groups and assign users to them. In this example, I created a Custom Group called Project.Auto Auction with the unique ID of auto_auction_group. I like to use the Project. prefix just as a matter of personal preference because it keeps similar usage patterns grouped together in the alphabetical list. Be sure not to use any special characters other than underscores for the actual IDs though. I then added members to the group.
Note that you can add a combination of provisioned SCIM groups to your Custom Groups instead. If a SCIM group is provisioned to your SAS Viya environment which contains all of your intended users, you can skip this step of creating a Custom Group and move onto the next section. Notice though, at the time of this writing, Azure Active Directory (AAD) only allows provisioning of Office 365 Security Groups via your AAD SCIM client (not standard Office 365 groups).
Now, we have a Custom Group we can use to provide access to our Azure File Share. We also need to ensure we can map to a POSIX GID because of the way Azure File Shares are mounted into Pods. The SAS Identities Service is the microservice on the SAS Viya side that's interfacing with your SCIM client to keep track of users and groups in your environment. The SAS Identities Service uses an algorithm to map the name of your Custom Groups into GIDs. In cases where we do not receive POSIX attributes from the identity provider, the SAS Identities Service will also use the same algorithm to map unique group names into GIDs. We'll see evidence of this in the next section.
Determining the GID of that custom group
Another implication of opting for the more cloud-native SCIM approach to managing identities rather than LDAP is the
password OAuth flow is no longer relevant. The SCIM paradigm eliminates individual applications from handling username and password combinations and instead relies on your application, redirecting them to the identity provider itself. When we want to interact with SAS Viya REST endpoints then, we can't use the
password grant type which would expect us to provide a username and password. Instead, we'll need to use the
client_credentials grant types. I wrote an entire series on the topic of selecting the appropriate grant type to communicate with SAS Viya REST endpoints if you're interested in learning more on that topic. There is also great information about communicating with SAS Viya APIs in this post by Joe Furbee and this white paper by Mike Roda.
For the purpose of this post, I will just provide an example of the
authorization_code OAuth flow so we can authenticate as ourselves without sending our username/password combination to SAS Viya in the REST call. First, in my browser, I navigate to:
Where, of course, you will replace the
myServer part of the URL with your environment URL. The value for the
client_id property in the URL corresponds to a client that was registered by default. It was created for the SAS Viya Admin CLI. We'll reuse it here because it has the necessary properties for the
authorization_code flow without giving users the opportunity to accidentally not approve some scopes that are crucial for this to function properly. If you would like to create your own client instead, information on doing so is available in all three resources linked in this section of this post.
When I navigate to to this URL, I'm redirected (if not already logged in) to Azure Active Directory's login page where I login as usual. I'm then automatically redirected back to SAS Logon. The next REST call we will make to get the GID for a SCIM or Custom Group requires membership in the SAS Administrator's Custom Group so at the SAS Logon prompt I assume my SAS Administrator's group rights. Finally, I'm redirected to a screen like this:
Next, I can use a tool like Postman (or curl or whatever you prefer) and trade that code for an OAuth token:
Due to the configuration of the sas.cli client, the returned token takes on the scope of my individual user, including my Administrator's group rights.
Then I make another call, this time to one of the SCIM endpoints of SAS Logon, to get the GID of the Custom Group I created in the previous step. Note that I have the actual ID (auto_auction_group) of that Custom Group in the URL, not the name of it (Project.Auto Auction).
Note: the identities API is not a publicly documented API and is not supported by SAS Technical Support or R&D.
This GID is what we will use when defining the Persistent Volume for our Azure File Share. This way, anyone placed in this Custom Group has rights to that mount in our Pods based on the group part of the permissions we set in that PV manifest. That will make more sense after you read Part 1 of this series.
If you're looking for the ID of a particular provisioned SCIM group instead of a Custom Group, make a call like the following to narrow down the responses to only provisioned SCIM groups:
From the response, locate the common name of your SCIM group, and its corresponding
id. Remember to replace spaces with
%20when you use this ID in your REST calls.
To locate the UID of the user we want to own the files for our mount, we can make a similar call but this time to the user identifier endpoint:
We can do validations on a few users we expect to be in that Custom Group using the call in the screenshot above. We can make similar calls to the identifier endpoint for users we know are not in this Custom Group and ensure we don't see that GID listed in their
And finally, to keep the post short, I've left out the actual mount and permissions validations. Feel free to repeat the steps in the previous post and validate they yield the same results.WANT MORE GREAT INSIGHTS MONTHLY? | SUBSCRIBE TO THE SUGA DOWNLOAD
I'm glacially getting up to speed on this - am I correct to understand that one pvc mount can map to one group in this paradigm? I've got an existing environment where I see the pvc mounted to a top-level folder (for example, /tla), and I under there, I'd like to have this custom group permitted to /tla/users, and with a separate user folder in there (for example, /tla/users/carl)
Since my system already has /tla, and I could create the custom group, I guess I'm really wondering how I could make /tla/users be owned by my tlausers group that I would be creating.
Or am I all wet on this?
Hey Carl - if you haven't had a chance to check out the post the precedes this one, I think it might help. Unfortunately though, the short answer is no - that's not possible. Azure File Shares were not intended to be a replacement for full blown replacement for complex shared file systems where you can specify specific access controls on sub directories. In that linked post before this one, it's a bit more obvious but we're only able to map an entire File Share to a PV and then set the permissions on that top level. It's great for a very particular set of use cases where an entire group should have the same level of access to all items inside, but not fitting for use cases like yours or like home directories for example where you'd need separate permissions on each subdir.
Would you be able to have a chat regarding this??
We'd be happy to discuss the content of this article further and how it pertains to your particular situation. Can you please outline what topics you'd like to discuss or list specific questions we can answer.