In a guest post on blogs.sas.com in January, I wrote about protecting your metadata protections. In that post I said that “Ideally, a SAS® metadata security plan should address both ACT permissions and access to the Authorization Manager.” and went on to explain a method for addressing Access Control Template (ACT) permissions.
In this second part, I’ll talk about reducing access to the SAS Management Console Authorization Manager plug-in as further protection for your ACTs.
Of course, for some smaller SAS sites, and those with simple security requirements, this might be overkill. However, for other possibly larger organizations, those with potentially sensitive data/content, and perhaps those with specific regulatory requirements, it might be a necessity to implement a comprehensive metadata security implementation with multi-layered protections like these.
In the default metadata security implementations for SAS 9.3 and SAS 9.2, all SAS users have the capability to access a limited set of features in the SAS Management Console. This includes access to the Authorization Manager plug-in where any accidentally unprotected ACTs could be modified. In order to be able to take advantage of this capability, and modify an ACT, a user has to be able to fulfill all of the following requirements:
- have access to a workstation or server that has SAS Management Console installed
- have the capability to use the Authorization Manager plug-in
- have permissions to modify an ACT
Limiting access to just one of these can help protect ACTs, but controlling access to all three will be more robust. If you only control access via permissions on the ACT and don’t control access to SAS Management Console installations or the Authorization Manager plug-in, you might be vulnerable to modification of ACTs that are accidentally unprotected. If you only control access to SAS Management Console installations, or the Authorization Manager plug-in, you might be vulnerable to modification of unprotected ACTs via custom code using the metadata API (a less likely scenario, but it still needs to be considered at least). By using a multi-layered approach and controlling access to all of these things you can reduce the likelihood of inappropriate modifications to unprotected ACTs.
Access to any SAS Management Console installation is probably going to be controlled via limited software deployment, together with workstation and server access policies. I’ve previously discussed permissions on new custom ACTs in my earlier blog post, so the rest of this post will be about limiting access to the SAS Management Console Authorization Manager plug-in.
You might have noticed that, as shown in the screenshot at the top of this post, when a non-administrator logs in to a SAS Management Console installation, whilst they don’t have access to all of the available features/plug-ins, they usually do have access to the following:
- Authorization Manager plug-in
- Data Library Manager plug-in
- User Manager plug-in
- Folders tab
- Search tab (SAS Management Console 9.3 only)
For installations that have more than a handful of users, chances are that these features are probably accessible to a much larger group of users than is strictly necessary. As an administrator, you might want to reduce the scope of SAS Management Console access to a smaller, more appropriate, subset of users including administrators, developers and potentially some power users.
You probably already know that access to these features in SAS Management Console, as in other SAS applications, is managed through roles and capabilities. In tracking down why this particular set of capabilities is available to everyone, you might ask the following questions.
- “How does a particular user have access to these capabilities?”
- “Which users and groups have access to these capabilities?”
- “How can I change it so that only specific groups have access to these capabilities?”
I’ll start by looking at questions 1 & 2 with the quickest and easiest method I know, which is to use our Metacoda Security Plug-ins software. I’ll then look at question 3 using standard SAS Management Console features.
How does a particular user have access to these capabilities?
Starting with a candidate user, sasdemo in this example, I can use the Metacoda Security Plug-ins User Reviewer to easily answer this question. As shown in the screenshot below, I start by typing in part of a user’s name to locate them.
I select the sasdemo row in the table of users at the top of the screen, and then move to the Capabilities tab at the bottom of the screen. There are many capabilities, but I’m particularly interested in knowing how they have access to the Authorization Manager plug-in capability, so I type in the word “authorization” to filter the capability list. Looking at the selected Authorization Manager row, I can then see, from the Role Path, that they’re getting access through the “Management Console: Content Management” role, via its SASUSERS group member, of which sasdemo is in turn a member. Everyone who can login to the SAS platform (with a registered identity) is a member of SASUSERS which is why everyone gets this capability. I would therefore need to look into whether it is appropriate for SASUSERS to be a member of this role for my installation.
Which users and groups have access to these capabilities?
From the previous question I might think I already know the answer to this question, and I do for the candidate sasdemo user. However, it’s possible that other users might also get this capability via different mechanisms (other roles and groups) so it is still a question worth answering.
This time, changing my perspective from user to capability, I can answer the question with the Metacoda Security Plug-ins Capability Reviewer. I’m now interested in who has access to the Authorization Manager plug-in capability so, as shown in the screenshot below, I type in the word “authorization” to filter the capability list to find and select the capability I want.
Moving to the Roles & Members tab underneath the capabilities list, I can now see a tree and a table showing all of the groups and users that have access to that capability (64 of them in this environment), and the membership paths by which they acquire it. There, underneath the Management Console: Content Management role, I can once again see the SASUSERS group that is providing the capability to all SAS platform users. It’s worth looking from this perspective because it’s possible that, after addressing the SASUSERS group membership of Management Console: Content Management, some users might still have access to the capability because they have multiple paths by which they acquire it. In this example, Koby has access to the capability via two paths: his membership of the SAS Administrators group and his membership of SASUSERS. For Koby, as an administrator, that’s ok and it ensures that when we address the SASUSERS groups access, Koby will maintain access to the plug-in via the other path. For other users there might be multiple inappropriate paths providing access to the capability and from this perspective we can see and assess them all.
How can I change it so that only specific groups have access to these capabilities?
In answering the earlier questions, we have seen that everyone has access to the Authorization Manager plug-in via the SASUSERS group membership of the Management Console: Content Management role. Once we have decided that this is not appropriate for our installation, we then have two options to address it:
- Remove the Authorization Manager plug-in capability from the Management Console: Content Management role.
- Remove the SASUSERS group as a member of the Management Console: Content Management role.
We will probably rule out option 1 because Management Console: Content Management is one of the pre-defined/pre-installed roles, and the recommended practice is to not modify the capability set for pre-defined roles. Instead, the recommend practice for pre-defined roles is to modify the membership, which is our option 2.
Before implementing option 2, we should consider who this will impact, how it will affect them, and whether that correctly meets our requirements. By removing a broad group like SASUSERS we might be taking away access from a larger group than we want. Perhaps there are a few non-admin users who are currently getting appropriate access to the Authorization Manager plug-in via SASUSERS who might then lose that access. In that case we will want to add their narrower group as a member to ensure they retain that access. Additionally, there are other plug-ins and features provided to SASUSERS via the Management Console: Content Management role, not just the Authorization Manager plug-in. Perhaps some BI and DI developers might also be getting appropriate access to the Data Library Manager plug-in via the SASUSERS group and they might lose that required access. We also need to consider how to maintain their access too. The Metacoda Security Plug-ins Capability, Role and User Reviewers can all help me to review and identify the capabilities, roles and users that will be affected by this decision. They can also help me determine whether or not the appropriate users will continue to have access to their required capabilities by other paths, and whether or not we need to introduce narrower access paths to maintain their continued access.
In our fictitious organization, we have decided that only our Administrators and Data Integrators need to maintain access to the capabilities provided by the Management Console: Content Management role. Looking in the Capability Reviewer screenshot above, I can see that the SAS Administrators group will maintain its access via the “Management Console: Advanced” role, and the “Vegas Enterprises: Data Integrators” group will maintain its access via its membership of the custom “Vegas Enterprises: Data Integrators Role” which gets capability contributions from the Management Console: Content Management role. Having checked that everyone necessary will still maintain the access they need, we can then go ahead and use the SAS Management Console User Manager plug-in to edit the Management Console: Content Management role and remove SASUSERS as a member:
Having made that change, I can then verify it by asking a normal business user who, in our organization, should not have access to any SAS Management Console plug-ins, to log in to SAS Management Console. After the change, this is what they see:
They no longer have access to the Authorization Manager plug-in, nor any other plug-ins or tabs. For this particular organization that is the right outcome. In addition to applying permissions on new custom ACTs to prevent edits by non-administrators, we have also limited non-administrator access to the software feature by which edits to ACTs can be made. This multi-layered approach provides extra protections for our ACTs, which themselves are the core protections for our metadata security policy.
Do you have any other tips for protecting your metadata protections? If so, please leave a comment below. I’d love to hear from you.
If you’d like more information about Metacoda Security Plug-ins, or would like to see how they can help you manage access to SAS application capabilities in your own installation, you can register for an evaluation from the Metacoda web site. Also, if you’re going to the SAS Global Forum in a month’s time, please visit us in the demo hall. Metacoda has a stand in the SAS Alliance Members area (known as the SAS Alliance Café in previous years).