Metacoda Security Plug-ins – Page 6

Role-Based Access to Metacoda Security Plug-ins in SAS Management Console

This post explains how to provide role-based access to Metacoda Security Plug-ins in the SAS® Management Console (versions 9.2 and 9.3).

Update 01Sep2023: The method described in this post is relevant for Metacoda Plug-ins version 5 and earlier. Metacoda Plug-ins version 6 and above, available since 2016, allow a much more flexible approach where you can control access to individual plug-ins and various other features. Metacoda customers can find more information in the documentation for the Metacoda Plug-ins Metadata Installer at https://support.metacoda.com/docs/plugins/v6.0/user-guide/tools/metadata-installer.html

Metacoda Security Plug-ins are initially only available to administrators, specifically members of the Management Console: Advanced role, of which the SAS Administrators group is a member by default. As unregistered plug-ins, Metacoda Security Plug-ins are controlled by the Access Unregistered Plug-ins capability which is only granted (by default) to the Management Console: Advanced role.

At Metacoda, we sometimes get asked about the possibility of providing wider access to Metacoda Security Plug-ins, for users that need/want to review and/or troubleshoot security metadata, but who are not members of the SAS Administrators group and/or the Management Console: Advanced role.

One possible option would be to modify the Management Console: Content Management role, of which SASUSERS is a member (by default) and grant the Access Unregistered Plug-ins capability. Whilst this works, it is not a recommended approach. It involves modifying the capability set for a SAS predefined role. The SASUSERS membership also means anyone with access to the SAS platform and SAS Management Console will get access to the plug-ins which is probably much wider access than is required.

These are the recommended steps to follow to provide limited, non-administrator, access to Metacoda Security Plug-ins in the SAS Management Console.

1. Choose/create Group(s) for Role-Based Access to Metacoda Security Plug-ins

The first step is to identify which groups of users need access to Metacoda Security Plug-ins. You might already have suitable groups you can use. If not then create a new group (or groups) and assign users (or nested groups) as appropriate. In this example we have a Metacoda Plug-ins Users group that contains a few individual users, including the SAS Demo User for testing purposes.

2. Enabled Role-Based Access to Metacoda Security Plug-ins

Whilst logged into SAS Management Console as an administrator, select Plug-in Manager from the Tools menu to access the Plug-in Manager dialog.

Locate Metacoda in the list of plug-ins, tick the check box to enable role-based access, and click the OK button to save the changes.

3. Create a New Role for Metacoda Security Plug-ins

Now that we’ve enabled role-based access to Metacoda Security Plug-ins, we can create a new custom role to provide access to the capability for the target users.

From the SAS Management Console User Manager plug-in, create a new role using the menu sequence Actions > New > Role. In the General tab, provide an appropriate name and description for your installation, as shown in the screenshot below.

4. Assign Capabilities to the New Metacoda Security Plug-ins Role

In the Capabilities tab for the new custom role, expand the Management Console application group and then the Plug-ins folder to locate the new Metacoda capability. Tick the check box to grant the Metacoda capability to this new custom role as shown here.

If necessary you could also grant additional capabilities for this role.

5. Assign Members to the New Metacoda Security Plug-ins Role

With the capability granted, all that remains is to use the Members tab to assign users and/or groups to the role to provide them with access to the capability. In the screenshot below I have added the Metacoda Plug-ins Users group I identified in step 1. You could also add individual users here but I prefer to use groups in role memberships and manage user access through group memberships instead.

Now the new custom role is ready, click the OK button to save the changes.

6. Test the New Metacoda Security Plug-ins Role

You can test this new role by asking one of the target users to log-in to SAS Management Console and verify Metacoda Security Plug-ins are now available to them. Alternatively, as an administrator, you could use impersonation techniques to log-in as one of the target users and verify this for yourself.

In the screenshot below you can see the SAS Demo User has limited access to just Metacoda Security Plug-ins and the standard SAS Management Console Authorization Manager, Data Library Manager and User Manager plug-ins, but none of the other plug-ins (such as Server Manager). Access to Metacoda Security Plug-ins has been provided via the new custom role. Access to the other plug-ins is provided via the predefined Management Console: Content Management role in its default state.

Final Thoughts

Whilst it’s easy to provide limited non-administrator access to Metacoda Security Plug-ins where required, bear in mind that those users may only be seeing part of the picture. Metacoda Security Plug-ins do not attempt to bypass metadata security, so users can only review security metadata on objects they would ordinarily be able to see (where they have an effective grant of the ReadMetadata permission). Since they are not unrestricted users and not user administrators, they will also only be able to see their own logins and logins for any groups they are a member of. If any folders or objects in metadata have been hidden from those users (with an effective denial of ReadMetada) then they won’t be able to review the security metadata for those folders and objects. If there is a requirement for those users to review security metadata for content they would not ordinarily be able to see, it is best handled by getting an administrator to export HTML reports from Metacoda Security Plug-ins and publish them in an area accessible to those users.

These instructions show how to provide role-based access to all of the features in Metacoda Security Plug-ins through a single capability. Depending on your role memberships you can either access none of the features or all of the features. If there is a need for it, in a future version, we can register the individual reviewers, and even the tabs within those reviewers, as specific individual capabilities to allow for much finer role-based access. If this is something that is important to you then please let me know.

Login Reviewer: Finding Accounts with Stored Passwords

In a previous post I mentioned how the Accounts tab in SAS® Management Console 9.3 now displays a blank in the password field when logins don’t have a stored password, and only displays ******** when there is a stored password. Compare this to SAS 9.2 where it always displays ******** regardless of whether there’s a stored password or not.

This is a great enhancement in SAS 9.3 because it allows us to know whether a password is stored in metadata or not. Sometimes it’s necessary to store passwords in metadata, but we generally try to minimize this. Passwords stored in metadata might be wrong and can get stale when password changes are enforced.

So now thanks to SAS 9.3 we can spot stored passwords when looking at individual users and groups. At Metacoda, we also wanted to be able to see, in one view, all logins that have stored passwords, across all users and groups, and in all repositories. This would show us how prevalent stored passwords are and which users and groups have them.

We’ve just enhanced the Login Reviewer for the next version of our Metacoda Security Plug-ins software to add a Password indicator column. Here’s a screenshot of this Password indicator column shown in SAS Management Console 9.3. I’ve sorted the Password indicator column to group together all the logins with and without stored passwords.

You might notice that one of the logins above is for a group found in a custom repository. I don’t recommend this approach, it’s just there for testing purposes. When I’m reviewing security metadata, I definitely want to know if there are things like this tucked away in custom repositories :)

Finally, for completeness, here’s another similar screenshot of the Login Reviewer’s Password indicator column, but this time in SAS Management Console 9.2. With SAS 9.2, when logged in as an unrestricted user, we can’t tell if there are stored passwords or not. This is why the screenshot below shows the column full of ‘Unknown‘ values. With SAS 9.2 we can only show Yes/No values when logged in as a normal user (in which case they will only get to see their own logins and any logins for groups they are a member of).

If you’d like to try this out, along with the other enhancements we’ve got planned for our next Metacoda Security Plug-ins version, then please let me know. We’re keen to talk to anyone who’d like to try out the beta when it’s available.

Metacoda Security Plug-ins Tip: Where’s that login?

This is a tip for Metacoda Security Plug-ins users who might have a need to track down which user or group identity in their SAS® metadata owns a particular user id.

Have you ever gone to add a login to a user or group identity in the SAS Management Console, perhaps some database credentials for a group to share, but couldn’t because the userid had already been used elsewhere? If so then you’ll be familiar with this error:

So now you know the userid has already been used elsewhere, but where exactly? Maybe it shouldn’t have been used on the other identity, or maybe you just want to check out the other identity because you might be able to take advantage of it instead of adding a new one?

It’s easy to find that user id, and the user or group identity it is associated with, by using the Metacoda Security Plug-ins Login Reviewer, especially if you have the new 2.0 version (which works with SAS 9.3 and SAS 9.2).

To track down the login open the Login Reviewer:

… and then, in the new filter bar, type in the user id which was already used, scott in this example. You’ll then see which identity has that login. In this example the scott login is already being used on the Vegas Enterprises: Oracle Users group which is why it couldn’t be added to the Custom Oracle Users group earlier.

If you have SAS 9.1.3 SP4 and Metacoda Security Plug-ins V1.0 then you won’t have the filter bar, but you can still find the login by clicking on the userid column header to sort by user id and then scroll down to find the problem login.

So finding a login isn’t that hard after all…

Capability Reviewer Preview: who has access to a capability and how?

The next version of the Metacoda Security Plug-ins includes a new Capability Reviewer. This new feature provides the ability to review who has access to a specific capability and by what paths a user, group or role acquires that capability.

As an example of how this is useful I’ll step through a scenario where we want to assess what needs to be done to avoid granting a specific capability to a specific user. If you have ever tried to make sure a user doesn’t have a particular capability then I’m sure you have seen this type of scenario. Lets say Bob Baxter is our user and he has the Drill to Detail capability in SAS® Web Report Studio 4.3 but he shouldn’t have.

We have to find all the roles that provide that capability directly to him and make sure he isn’t a direct member of the role. We need to remember that capability acquisition is cumulative and capabilities can’t be denied. It only takes 1 role to provide him the capability for him to have it. He can also get access to the capability through his, possibly nested, group memberships if those groups are members of a role that provides the capability. He can also get access through capability contributions, from contributing roles, to a role he is a member of directly or indirectly.

So now lets say Bob has been removed as a direct member of any roles that provided the capability but he still has the capability. Chances are he has acquired the capability indirectly through one of the groups that he is a member of (either directly or indirectly through nested group members, or implicitly through SASUSERS or PUBLIC). That means we need to track down how those groups have the capability and either remove him from the group or remove the group from the role (taking into account removing him from the group and/or removing the group from the role could have significant impacts elsewhere).

So where do we start with this? How do you find out which users, groups and roles have access to a specific capability and how they have access to that capability? This is where the Capability Reviewer in the upcoming V2 release of our Metacoda Security Plug-ins shines. The following screenshots show how we can use the Capability Reviewer to find this information.

The first screenshot below shows the initial view of the Capability Reviewer. It shows a list of all capabilities. Clicking on a capability shows all of the users, groups and roles that have access to that capability. This is presented in a tree format on the left and a table format on the right. The tree shows the various paths from the capability, through the roles, to the groups and users (including nested groups and contributing roles). The screenshots in this post are quite small, but you can click on any of them to view them full size.

We are interested in a specific capability, so we type drill in the filter bar to limit the display to those capabilities that include the text drill in their path/name or description. The result is shown in the next screenshot …

In the screenshot above (click it to view full size) we can see the filter bar has been used to find the Drill to Detail capability in SAS® Web Report Studio 4.3. The capability has been selected and we can see in the tree and table below it who has access to that capability. There are quite a few identities listed, but we are interested in a specific user (Bob). The next screenshot shows how we can look specifically at Bob’s access to that capability …

In the screenshot above (click it to view full size) we can see the filter bar within the Roles & Members tab, has been used to find Bob. By default the tree and table only show the shortest path by which the user acquires that capability, but if we want to ensure a user doesn’t have a capability we need to find and eliminate all capability access paths for that user, so we also click the “Show Duplicates” button on the filter bar. The table then shows all 3 paths by which Bob acquires the Drill to Detail capability:

Bob Baxter is a member of the implicit PUBLIC group which is a member of the Web Report Studio: Report Viewing role which has been granted the capability.
Bob Baxter is a member of the implicit PUBLIC group which is a member of the Web Report Studio: Report Creation role which has been granted the capability.
Bob Baxter is a member of the Vegas Enterprises: Executives group which is a member of the Vegas Enterprises: Report Consumers group which is a member of the Vegas Enterprises: Report Consumer Role which has Web Report Studio: Report Viewing as a contributing role which has been granted the capability.

As you can see the Capability Reviewer allows us to find exactly how Bob acquires the capability through all of the potential paths. To make sure he doesn’t have the capability we need to ensure he is not in any of these paths. How that is done for you will depend on how you have set up your groups, roles and capabilities within your SAS platform installation. The simplest way will be to either remove Bob from the relevant roles and/or groups, or remove the capability from the relevant role(s). However, we also need to bear in mind that, depending on the changes you make, this can have significant impacts to roles, capabilities and access controls elsewhere. A more realistic outcome from a requirement to effectively remove a capability for a user is that the roles & capabilities implementation needs to be re-assessed and re-planned. Roles & capabilities needs careful planning but that’s a bigger story than we have time for here.

Our other Metacoda Security Plug-ins reviewers can help you assess the potential impact of any changes you might plan to make. For example: the Role Reviewer can help you find out what other users and groups might be affected by changes to a role’s capability set; the Group Reviewer can help you find out what other users and groups are direct or indirect members of a group you might want to change role memberships for.

If you’d like to find out more about the Capability Reviewer, or evaluate a beta version when it becomes available soon, then you can either send me a message or contact us via the Metacoda contact form.

If you are attending SAS Global Forum 2011 in Las Vegas this week then you can also see the Capability Reviewer in action by visiting us at the Metacoda booth (#106) in the demo area.

Updated 08Sep2011: Metacoda Security Plug-ins V2.0, and the new Capability Reviewer, is now available to customers and evaluators. If you would like to try it out you can request a evaluation from the Metacoda web site.

User Reviewer V2: Sneak Peek

If you’re a SAS platform administrator who manages a SAS metadata security implementation then you might be interested in this sneak peek of some of the enhancements in the next version of our Metacoda Security Plug-ins (custom plug-ins that can be installed into the SAS Management Console). We’ve been hard at work updating our plug-ins to provide enhanced views of the great new metadata security improvements in SAS® 9.2 like roles and capabilities.

Roles and capabilities in SAS 9.2 let you control, via the SAS metadata server, user access to functionality and features in SAS client applications such as SAS Enterprise Guide, SAS Add-in to Microsoft Office, SAS Web Report Studio and SAS Management Console. For an excellent overview of roles and capabilities I’d definitely recommend reading Kathy Wisniewski’s SAS Global Forum 2010 paper “Be All That You Can Be: Best Practices in Using Roles to Control Functionality in SAS® 9.2“.

We’re improving our Metacoda Security Plug-ins User Reviewer by adding Roles and Capabilities tabs that provide extended information about the roles and capabilities for a user. This screenshot (click the thumbmail to view the full size image in a new window) shows a preview of our new Roles tab:

In the screenshot you can see that I have tracked down a particular user and am looking at all of the roles he is associated with. It shows:

direct role associations, where a user is a member of the role directly
indirect role associations, where the user is a member of a group (possibly nested) and that group is a member of the role
implicit role associations, where the user is associated with the role through the one of the implicit groups (SASUSERS and PUBLIC)
contributed role associations, where the user is associated with a role indirectly through that roles contribution to another role the user is associated with

Essentially this new Roles tab allows you to answer the question: is a user associated with a particular role, and if so, by what means are they associated?

Another question administrators want to answer for a given user is what capabilities do they have or not have, and why? That’s where our new User Reviewer Capabilities tab helps. Here is another screenshot (once again click the thumbnail to enlarge):

This screenshot shows the Capabilities tab where you can see a list of all the capabilities and whether or not the user has been granted access to them. If the user has been granted access to a capability it also shows which role is providing them with the capability and the membership path from the user to the role. If you’ve ever tried to track down why a user has an unexpected capability then I’m sure you’ll appreciate how useful this is.

That’s it for this sneek peak, but if you are going to SAS Global Forum 2011 in Las Vegas this year, and you’d like to find out more, then please pop by and visit us in the SAS Alliance Cafe for a demo – we’ll be in booth #106.

BTW if anyone out there is interested in trying out a beta version then we’re looking for a few more beta testers. If you have a SAS metadata server in a development, test, or sandpit environment and would like to test drive our plug-ins then let me know. You can contact me through this blog, Twitter, my LinkedIn profile, the Metacoda web site or even in person at the SAS Global Forum in a few weeks time :)