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.
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.