Category: SAS Metadata Security

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:

Identity Hierarchy

In my upcoming SAS Forum Australia & New Zealand 2010 presentation Best Practices with SAS® 9 Metadata Security, I mention that is important for platform administrators to have an understanding of the Identity Hierarchy concept. In this post I provide a bit more information about the identity hierarchy, and associated identity precedence, than time allows in the presentation.

Learning about the Identity Hierarchy

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

  • Read the SAS® 9.2 Intelligence Platform Security Administration Guide, Chapter 3 Users, Groups, and Roles, specifically the section titled Identity Precedence
  • Read the SAS® 9.1.3 Intelligence Platform Security Administration Guide, Second Edition, Chapter 2 Understanding Authorization, specifically the section titled To Whom Can Permissions Be Assigned?
  • Attend the SAS training course SAS Platform Administration: Fast Track. I think this is one of the best courses available from SAS and is an essential foundation for any platform administrator. I should point out that I do teach this course from time to time for SAS Institute Australia so I might be a little biased ;)

Visualizing the Identity Hierarchy

The identity hierarchy consists of the user, all of the groups that they are a direct member of, all of the groups that they are an indirect member of via nested group memberships, as well as the SASUSERS and PUBLIC groups that they are implicit members of. All of these identities can be arranged in a hierarchy. The following screenshot shows the identity hierarchy for a fictitious user Kate Knowles:

This screenshot was generated and extracted from the identity hierarchy tab available in our Metacoda Security Plug-ins User Reviewer. This tab provides a visualization of the identity hierarchy for any selected user in metadata. If you are wondering what the various icons mean:

  • represents a user (in this particular case a user bulk-loaded into metadata from AD or LDAP);
  • represents a normal group;
  • represents a group that has been bulk loaded into metadata (from AD or LDAP); and
  • represents a group that ultimately contains itself (via a circular reference)

At the top of the identity hierarchy (level 0), with the highest identity precedence, is Kate Knowles herself. Underneath Kate (at level 1), and with the next highest identity precedence, are the groups that Kate is a direct member of ( Northern Region HR for example). These level 1 groups are those where you will find Kate listed on the group’s Members tab. Underneath those level 1 groups are the level 2 groups (e.g. Northern Region), that have the level 1 groups as direct members (i.e. you will find the level 1 group listed on the Members tab of the level 2 group). Kate is an indirect member of the level 2 groups. This process continues until we exhaust all of the nested groups, which is at level 3 for Kate. Finally, at the deepest levels are the implicit groups: SASUSERS for everyone with a metadata identity; and PUBLIC for everyone with valid credentials.

You can see the screenshot shows two different views of the identity hierarchy: 1) the tree view shows the member relationships between the groups as well as the shortest path by which the user is a member of any given group; and 2) a flattened table view which just shows the user and the direct, indirect and implicit groups in order of identity precedence.

The identity hierarchy shown above is a simplified smaller representation of a complete identity hierarchy. It has had redundant duplicate groups that have the same or lower identity precedence removed, so that groups are only shown once at their highest level of identity precedence. To illustrate this a simpler identity hierarchy is shown below which includes a duplicate group reference. In this example, Tara Thompson is a direct member of both the Australia and the Asia/Pacific groups – these are shown at level 1. The Australia group is itself a direct member of the Asia/Pacific group too, and so the Asia/Pacific group is also a level 2 group and shown greyed out below – ordinarily we hide this lower precedence group from the identity hierarchy. You might notice that there is no need for Tara to be a direct member of the Asia/Pacific group because she already has that membership indirectly through the Australia group membership. In fact this multi-level membership has the potential to cause unwanted conflicts. I plan to post about this type of identity hierarchy issue later on.

Importance of the Identity Hierarchy

The identity hierarchy is important because it is used to determine identity precedence which plays a key role in resolving conflicts. It can also be used to find any shared logins accessible to the user, via their group memberships, by walking the tree looking for logins on any of the groups.

To quote from the SAS® 9.2 Intelligence Platform Security Administration Guide:

Identity precedence affects authorization decisions when a user has more than one relevant permission setting because of the user’s group memberships. Identity precedence affects login priority when someone has more than one login in an authentication domain. Identity precedence is not relevant for roles

In SAS 9.1.3 the identity hierarchy is only used to resolve authorization decisions and find shared logins. Its use in choosing a higher priority login is new in SAS 9.2.

A good understanding of the identity hierarchy allows you to understand and troubleshoot conflicts, and hopefully help you plan to avoid them where possible.

Potential Identity Hierarchy Issues to Avoid

Most of the time the identity hierarchy is quite straightforward, but you can also get into some odd situations. Some of the potential issues to avoid include:

  1. As shown above, in the identity hierarchy for Tara, a group can potentially appear at multiple levels in an individual’s identity hierarchy. Whilst this can be normal, care may need to be taken with access controls to avoid potentially unwanted outcomes. I plan to post an example soon which provides an example of an unwanted outcome due to an identity hierarchy conflict and “non-implicit-group permission denials”.
  2. It is possible to end up with circular references in the identity hierarchy. This occurs when a group contains itself as an indirect member through a nested group membership. The Metacoda Security Plug-ins User Reviewer detects these and tags the group with a special icon . The identity hierarchy shown earlier for Kate provides an example of this: Kate is a direct member of the Human Resources Managers group which itself is a direct member of the Human Resources group and that group in turn is a direct member of the Human Resources Managers group (it’s own parent).
  3. Whilst it’s possible to add the implicit groups SASUSERS and PUBLIC as direct members of other groups, this is not a recommended practice. It is however quite normal to add the implicit groups to roles with SAS 9.2. In another quote from the SAS® 9.2 Intelligence Platform Security Administration Guide:

    To avoid introducing unnecessary complexity, don’t make PUBLIC or SASUSERS a member of another group. For example, if you make PUBLIC a member of GroupA, then a user who is an indirect member of GroupA (through his automatic membership in PUBLIC) has GroupA as his lowest precedence membership. This contradicts the usual expectation that every user’s lowest precedence membership is PUBLIC

To be continued …

I am planning on following up this post with some additional examples and practices that build upon this discussion of the identity hierarchy, but that’s it for now. I hope this post is useful to those who may want to find out more than I can discuss in my forum presentation. Please let me know if you have any comments or questions.

Information Resources for SAS® 9 Metadata Security

In my presentation on Best Practices with SAS® 9 Metadata Security I mention a number of useful resources for more information. I don’t have enough time and space to list all of them in the presentation so I will list them here for those who are interesting in finding out more.

Resources for SAS 9.2

SAS® 9.2 Intelligence Platform Security Administration Guide
Available from http://support.sas.com/documentation/cdl/en/bisecag/61133/PDF/default/bisecag.pdf
SAS® 9.2 Management Console Guide to Users and Permissions
Available from http://support.sas.com/documentation/cdl/en/mcsecug/61708/PDF/default/mcsecug.pdf
Be All That You Can Be: Best Practices in Using Roles to Control Functionality in SAS® 9.2
Kathy Wisniewski
SAS Global Forum 2010 Paper 324-2010
Available from http://support.sas.com/resources/papers/proceedings10/324-2010.pdf
A Practical Approach to Securing a SAS® 9.2 Intelligence Platform Deployment
Jim Fenton & Robert Ladd
SAS Global Forum 2010 Paper 311-2010
Available from http://support.sas.com/resources/papers/proceedings10/311-2010.pdf

Resources for SAS 9.1.3

SAS® 9.1.3 Intelligence Platform: Security Administration Guide, Second Edition
Available from http://support.sas.com/documentation/configuration/bisecag.pdf
Best Practices for SAS®9 Metadata Server Change Control
Available from http://support.sas.com/resources/papers/MetadataServerchngmgmt.pdf
TS-760 Metadata Security and the DefaultACT in SAS®9
Available from http://support.sas.com/techsup/technote/ts760.pdf
TS-750 Securing SAS®9 Business Intelligence Content Managed in Metadata
Available from http://support.sas.com/techsup/technote/ts750.pdf

I will make sure that all of these are also in my Reading List.

Best Practices with SAS® 9 Metadata Security

As I mentioned in a previous post, I will be doing a presentation at SAS Forum Australia & New Zealand 2010 titled Best Practices with SAS® 9 Metadata Security. The abstract for this presentation is as follows:

SAS® 9 metadata security is becoming increasingly more important as SAS® 9 platform installations continue to grow and evolve. With more content, larger user communities and a wider variety of application interfaces, time-poor SAS platform administrators are looking for better ways to manage security with their organisations valuable metadata and data resources.

Knowledge and use of current SAS® 9 metadata security best practices can be a key differentiator between stressed platform administrators and well organised administrators. One group might spend their time applying ad-hoc quick fixes and tracking down authorisation conflicts, whereas the other group will plan ahead to reduce day-to-day overheads and minimise the impact of change.

This paper will provide an outline of some of the key SAS® 9 metadata security best practices together with information on where to go to find out more.

Of course this is a large topic for the time available, and so the presentation will provide an overview with a few examples. My plan is that this blog will act as a companion to the presentation. I will post articles here that provide further information with links to online materials that should be useful to other platform administrators wanting to find out more about the topic.