As someone who specialises in SAS® metadata security, I spend a lot of time using the Authorization tab in SAS Management Console. I also use Linux a great deal. When I run SAS Management Console on Linux, I’ve noticed that the check box background colours on the Authorization tab don’t render correctly (for me at least). I only ever see white background check boxes when I expect to also see green and gray ones: green indicating an ACT; white indicating an ACE; and gray indicating indirect. These colours are important indicators for the source of access controls so not being able to see them is a problem!
It occurred to me that I might be able to resolve this by specifying a Java System Property in the sasmc.ini file to change the Java Look & Feel.
I first tried changing the default look & feel (using ‑Dswing.defaultlaf) but that didn’t work. What did work is changing the default system look & feel (with ‑Dswing.systemlaf). Continue reading “Java Look & Feel with SAS Management Console on Linux”
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.
The first step is to create the BI Lineage Users group. Continue reading “Providing User Access to the SAS® BI Lineage Plug-in”
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)”
We recently released an update to our Metacoda Security Plug-ins (V3.0 R2) with support for use with SAS® 9.3 M2. This of course required testing with a variety of SAS Metadata Server versions and different versions of SAS Management Console clients too. We could rule out SAS 9.1.3 because our V3 plug-ins are only supported for use with SAS versions 9.2 and 9.3 but that still leaves SAS 9.2 M3, SAS 9.3 M0 and SAS 9.3 M2 because there are small SAS metadata model differences between all of these. For example SAS 9.3 M0 has new metadata model types CalculatedMember, FavoritesContainer, NamedSet, and Search, which are not present in SAS 9.2. SAS 9.3 M2 also has new metadata model types SecuredLibrary and SecuredTable not present in SAS 9.3 M0.
The obvious combinations to test are the matching SAS Management Console and SAS Metadata Server versions, 9.2 to 9.2, 9.3 M0 to 9.3 M0, and 9.3 M2 to 9.3 M2. However we also need to test mismatched client and server versions because some mixed combinations are allowed. I’m sure you can imagine situations where the SAS Metadata Server version is upgraded but a few client workstations still have older SAS Management Console versions installed. Or perhaps someone is using a newer SAS Management Console version but accidentally connects to an older SAS Metadata Server in the middle of a migration project.
The following table shows the combinations of client and server versions where we have tested connections (to see if we need to test our plug-ins): Continue reading “SAS Management Console: Client and Server Versions”
I ran into a tricky issue today whilst migrating some Access Control Templates (ACTs) from an old SAS® 9.3 M0 deployment to a new SAS 9.3 M2 deployment. I’d seen it before and I initially forgot how I resolved it. It took a little while to rediscover the method that worked so I’m blogging it in the hope I won’t forget it in future. Perhaps it will help others too.
As you may know, SAS 9.3 has virtual folders that allow you to export security metadata like users, groups, roles and ACTs. It’s quite handy. We use it at Metacoda to migrate some security metadata we carry over from version to version for testing and demonstrating our Metacoda Security Plug-ins. You can find more information about migrating security metadata on the SAS web site in the Promotion Details for Specific Object Types section of the SAS 9.3 Intelligence Platform: System Administration Guide, Second Edition.
I had successfully exported a package of ACTs from my source 9.3 M0 environment, but when I tried to import them into my target 9.3 M2 environment I saw the following error message:
It was quite puzzling. It said I had to import ACTs into a specific folder, but that was the very same folder I was trying to import into. I had a feeling of deja-vu. I realized I’d seen this back when I first set up our SAS 9.3 M0 environment and was testing migration of security metadata between levels for the same SAS version. Continue reading “Migrating SAS Access Control Templates”