Inheritance Paths

This is another companion post for my Best Practices with SAS® 9 Metadata Security presentation at next week’s SAS Forum Australia & New Zealand 2010 to expand a little on the concept of Inheritance Paths.

Importance of Inheritance Paths

Inheritance paths play a key role in SAS metadata security, providing a mechanism whereby objects can inherit some, or all, of their access controls from other objects. They provide a foundation for the development of an efficient security plan that meets security requirements with a minimum of access controls and ongoing maintenance.

When determining whether a user has been granted or denied a permission on an object in metadata (such as the ability to update an information map with a grant of the WriteMetadata permission), the SAS metadata server will first look to see if the object has any relevant direct access controls applied to it. If there are no relevant direct access controls on the object in question, then the grant or denial of the permission will be derived from the object’s inheritance paths instead. The inheritance paths consist of the objects parents, its parent’s parents and so on.

In any given metadata repository the vast majority of metadata objects will not have any direct access controls applied to them. Almost all metadata permission determinations will be made from inheritance paths. This is a good thing. Inheritance paths mean we can set a small number of key access controls in a few strategic locations high up in inheritance paths, such as high level tree folders or application servers, and rely on inheritance to propagate those permissions to the majority of objects lower down in the inheritance path.

The structure and content of an object’s inheritance paths will depend on the type of metadata object in question (as well as the version of SAS you are using – more on that in a moment). The SAS documentation provides more information on the specifics but it is often easier to use the SAS Management Console Inheritance tab when looking at specific objects.

With SAS 9.1.3 we used to have to work most of this out in our head. Things are much easier now with SAS 9.2 thanks to all the new metadata security goodies, such as the SAS Management Console Explore Authorizations and Inheritance tabs, but it is still important for a platform administrator to have a good understanding of inheritance paths. Whilst you may be able to find out that Susan has been granted WriteMetadata on the Current Sales Forecast information map through an inherited access control, it is an understanding of inheritance paths that helps you find the underlying source of that grant. A knowledge of inheritance paths is also key to planning a good metadata security plan as well as understanding the impact of any changes that are made.

Visualizing Inheritance Paths

An object’s inheritance paths can be easily viewed using the SAS Management Console Inheritance tab. This is a standard feature in SAS 9.2 and available as a downloadable plug-in for SAS 9.1.3.

When using SAS Management Console 9.2 you can access the Inheritance tab from an object’s properties dialog by using the Advanced button on the Authorization tab. The following is an example of the Inheritance tab in SAS 9.2 for a table named CUSTOMERS showing the single inheritance path consisting of the hierarchy of folders it is contained in. The tree path for this table is /SAS Folders/Shared Data/Sales Data/CUSTOMERS which can be seen in reverse in the Inheritance tab.

Whilst the Inheritance tab is not included in a standard installation of SAS Management Console 9.1, it can be easily added by downloading and installing the plug-in from the support.sas.com site. You can find the 913INHERITANCETAB01 download together with installation instructions in the SAS BI Administration Utilities 9.1.3 area.

Once installed in SAS Management Console 9.1, as shown in the screenshot below, the Inheritance tab can be seen directly in the properties dialog for an object (i.e. alongside the Authorization tab). You may notice that this is in a different location than with SAS 9.2 (where it is accessed from a button within the Authorization tab).

This additional feature is also described in SAS Usage Note 20960: The authorization inheritance utility is now available for the SAS® Management Console. As mentioned in the usage note, it is easier to view the inheritance path if the Show Association Node checkbox is unchecked (as I have done below). It must be manually unchecked with SAS Management Console 9.1, but is unchecked by default in SAS Management Console 9.2.

The example above shows the CUSTOMERS table in a SAS 9.1.3 installation where the table can be found in the tree folder /Shared Data/Sales Data and associated with the Sales library assigned to the SASMain application server.

You may have noticed that there are multiple inheritance paths for this table in a SAS 9.1.3 installation, whereas there was only one inheritance path in the SAS 9.2 installation…

Multiple Inheritance in SAS 9.1.3 vs Single Inheritance in SAS 9.2

As shown in the examples above, SAS 9.1.3 had a few instances of multiple inheritance where an object could have multiple parents and therefore multiple inheritance paths. The CUSTOMERS table shown above for SAS 9.1.3 has two direct parents: both the Sales Data tree folder, and the Sales library. This multiple parentage resulted in some confusion among platform administrators. Whilst the access decision flow handled the potential for conflict, it did so in a way that caused some often unexpected outcomes where a permission may have been granted when the administrator expected it to have been denied. When I say ‘unexpected’ I mean from the perspective of a platform administrator who is not aware of the rules – it is totally expected when considering the access decision flow :) I have a follow-up post planned that discusses this potential issue and the associated practice of consistently securing all inheritance paths

These are some of the metadata objects I am aware of that have multiple inheritance in SAS 9.1.3:

• DBMS Schema: inherits from both DBMS Server and Library (as documented in the SAS® 9.1.3 Intelligence Platform Security Administration Guide)
• Table: inherits from both Library and Tree folder
• OLAP Cube: inherits from both OLAP Schema and Tree folder
• Deployed Job: inherits from both Job and Tree folder

… if you know of any others, please let me know and I will add them to this list. From what I can see the SAS 9.1.3 Security Administration Guide for SAS 9.1.3 only covers the DBMS Schema instance. It does not mention the OLAP Cube and Table instances which are also commonly encountered.

One of the significant metadata security changes in SAS 9.2 was the virtual elimination of multiple inheritance. Tables and OLAP Cubes, for example, now have single inheritance paths in SAS 9.2 and only inherit from folders.

I say virtual elimination in SAS 9.2 only to be safe because, although I have yet to discover any metadata objects types in SAS 9.2 that do have multiple inheritance, the access decision flow still handles multiple inheritance scenarios and the documentation stills refers to the potential for multiple inheritance. The SAS® 9.2 Intelligence Platform Security Administration Guide, Chapter 5 Authorization Model section titled Authorization Decisions states that “A grant from any inheritance path can provide access.” and “Having more than one immediate parent is not a common circumstance.”, but it does not provide any concrete examples.

If you are reading this and you do know of any multiple inheritance examples in SAS 9.2 then I would be very keen to hear from you :)

Learning more about Inheritance Paths

If you want to lean more about this topic, I would suggest any or all of the following:

• Attend the SAS training course SAS Platform Administration: Fast Track.
• Read the SAS® 9.2 Intelligence Platform Security Administration Guide, Chapter 5 Authorization Model, specifically the section titled Inheritance Paths
• Read the SAS® 9.1.3 Intelligence Platform Security Administration Guide, Second Edition, Chapter 2 Understanding Authorization, specifically the section titled Where Can Permissions Be Set?