Tag: Roles & Capabilities

SAS Global Forum 2016 is just over 2 weeks away, and I’m really excited about showing a Permissions Tracer feature we’ll be releasing in the next version of our Metacoda Security Plug-ins. Metacoda is a SASGF sponsor again this year and we’ll be showing a preview of this new version at our Metacoda stand in The Quad, so please stop and say hello if you’re going to be there too.

Metacoda Permissions Tracer

We’ve had some very positive feedback about how helpful our Identity and Object Permissions Explorers have been, so I’m looking forward to getting some feedback on this new feature too. One of the other reasons I’m excited is that this is something we’ve been building up to for several years as we’ve expanded our code base to help visualize the richness of the SAS metadata security model, including its interacting object inheritance paths, user identity hierarchies, and role-implied special conditions.

I was asked yesterday whether it was possible to use the SAS® Management Console BI Lineage plug-in to provide non-administrators with the ability to review BI Lineage scans (as previously run by administrators). The BI Lineage plug-in can be used to do impact analysis for BI content (reports, information maps etc.) in a similar way that SAS Data Integration Studio provides impact analysis for DI content (jobs, tables, etc).

I’d never needed to do this before, so I did a little research. It didn’t take long to find the Granting Users Permission to View Scan Results section of the Using the BI Lineage Plug-in page in the SAS® 9.4 Intelligence Platform: System Administration Guide, Second Edition. That page explains how to open up access to the BILineage custom repository so that normal non-administrative users can get access to the scans (which are otherwise only available to unrestricted users). The document doesn’t get into explaining how to provide normal users with access to the BI Lineage plug-in itself so in this blog post I’m going to outline the steps required, with screenshots, to show the entire process. The end result of this process will be a BI Lineage Users group. You can then add normal non-administrative users as members of this group to provide them with access to both the BI Lineage plug-in and the scans in the BILineage repository.

Yesterday I saw a question on the SAS® Communities site from Nick about Registering Custom Tasks and managing the capability metadata that’s used for role based access control on those custom tasks. I found Nick’s question especially interesting because we have some free Metacoda Custom Tasks and those techniques can also be used to control access to them.

Nick had mentioned how he used SAS® Enterprise Guide® to register the capability metadata for some custom tasks, was asking about doing the same for the SAS Add-In for Microsoft Office, and also about how one would go about removing the capability metadata. Chris Hemedinger later replied with a response that I found very useful. There was a link to one of his prior blog posts on the topic (Controlling access to custom tasks in SAS Enterprise Guide – The SAS Dummy) and some information on using RegAddin.exe to get the capability metadata populated for use by the Add-In. Chris also mentioned there was not a way to remove the custom task capability metadata short of the potentially dangerous technique of using the SAS Open Metadata Interface’s DeleteMetadata facility.

Having already registered the custom task metadata myself, I now needed a way to remove it so I could repeat the process for future documentation and testing purposes. I used the DeleteMetadata method. This is the main topic for this blog post and it serves 2 purposes: the first is that I wanted to document how I did it so I could do it again later; the second is that it was an opportunity for me to use the SAS Management Console XML Metadata Interface and capture a few screenshots along the way. I rarely use the SAS Management Console XML Metadata Interface and it’s always a journey of re-discovery every time I do. This time I wanted a permanent memory of the steps so I could refer to them again in future. I also ran into an interesting unknown-public-type issue that initially prevented me from deleting the capability metadata, so I’ll show how I resolved that too. Continue reading “Removing Custom Task Capability Metadata”

Did you know that with SAS® 9.3 you can promote (export/import) SAS metadata packages containing users, groups, roles, and ACTs, just like you can with Jobs, Tables, Libraries, Stored Processes, Reports and Information Maps? I needed to do this myself a few weeks ago. I wanted to promote some groups, roles and ACTs from an existing SAS 9.3 M1 installation to a newer SAS 9.3 M2 installation. Security metadata can be exported and imported via a SAS package file (.spk) from special virtual folders under the top-level /System folder. These virtual folders are distinguishable from normal folders because they have white folder icons instead of yellow folder icons as shown below.

You can find out more information about this feature, including a few considerations you need to be aware of, by reading the Promoting Security Objects and Server Objects sub-section of the main Promotion Details for Specific Object Types section in the SAS 9.3 Intelligence Platform: System Administration Guide, Second Edition.

My security metadata promotion was a little more complicated than normal because I was also promoting some security metadata located in a custom repository. I normally avoid using custom repositories as much as possible (preferring to store everything in the Foundation repository and partitioning content with folders and ACTs). This is especially the case for security metadata: I’ve found that security metadata in custom repositories, being less visible, tends to get forgotten until it gets rediscovered whilst troubleshooting tricky security problems. Helping a customer resolve such problems was the reason we made security metadata from custom repositories highly visible in our Metacoda Security Plug-ins. We have since needed to keep some security metadata in custom repositories for the purposes of development and testing of our software. This is the custom repository security metadata I was attempting to promote, but it took me a little while to find it in the virtual folders …. Continue reading “Promoting SAS Security Metadata (in Custom Repositories)”

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: Continue reading “Protecting your Metadata Protections: Part 2”