SAS® 9.1.3 OLAP Server Security

INTRODUCTION

Security consists of two parts –authentication and authorization. Authentication asks the question: Is this user who he says he is? The client application presents the credentials and those are authenticated. In SAS 9.1 the credentials are entered on the client application (such as the OLAP Cube Studio, Enterprise Guide, Information Map Studio, etc.) and then authenticated/validated by the Authentication Provider.

Authorization, which is discussed throughout this paper, is when an authenticated/validated user seeks access to protected information such as Data Sets or Cubes. In other words, does this user have permission to access this data?

It is important before applying OLAP Server Authorization that you understand the Metadata Security in general. Please refer to the SAS® 9.1.2 Intelligence Architecture: Planning and Administration Guide under the Security Concepts and Administration and the Understanding Authorization (pps 67-68 specifically for OLAP) sections.

The examples in this paper were created in SAS9.1.3 and it is the recommended version to practice or reuse these examples.

OLAP SERVER AUTHORIZATION

Not all the permissions available are relevant for the OLAP objects. Generally read, readmetadata, writemetadata, checkinmetadata and administer can be used depending on what the user needs to accomplish. Below is a summary table that shows what authorizations are needed depending on the task you are accomplishing.

Cube OLAP Server Monitor MetadataAccessing from client App.

Building Building w. ETLS Change Management

Deleting Connecting to OLAP Server

Viewing User Sessions

Viewing Cube

Changing Permissions on OLAP Objects

Readmetadata Checkinmetadata CreateWritemetadata Administer Read Delete

Write

Table 1: Summary of permissions required for OLAP-related tasks

OLAP SERVER MONITOR

The OLAP Server Monitor object inherits permissions directly from the Application Server. To use the OLAP Server Monitor Plug-in you first need to connect to the OLAP Server, this requires the user to have Administer permissions granted. A user such as SAS Administrator (sasadm) will be able to log on to the OLAP Server and be able to perform multiple tasks such as viewing user sessions, terminating sessions, and refreshing cubes (to name a few).

OLAP DATA

Below is a diagram to explain the inheritance of Access controls in OLAP Data Objects.

Figure 1: Inheritance of Access Controls in OLAP (Planning and Administration Guide p. 67)

To access and/or load the metadata information for the cube, you require readmetadata permissions. However once you have that access only read is required to view the actual data. This is how you can control what a user can see and access. It is essential to understand how to navigate through your OLAP data and what effect applying or denying read access has on the parent or child components of your cube.

Figure 2: Access Requirements for Navigating through OLAP Data (Planning and Administration Guide p. 68)

There are several scenarios for setting up these restrictions and it is dependant on what access you want your users to have. Below are some scenarios that explain the different type of restrictions you can implement.

EXAMPLE DATAThe scenarios below are using a fictitious retail business, Orion Star Sports & Outdoors, selling sports and outdoor products, such as shoes, clothing, and sports gear for men, women, and children.  The company is international with headquarters in the USA and retail stores in a number of countries including USA, Belgium, Holland, Germany, UK, Denmark, France, Italy, Spain and Australia.

In addition to the physical retail stores, products are sold as catalog-mail orders and over the Internet. Customers sign up as members of the Orion Star club organization - thereby receiving some favorable special offers.

The data contains patterns showing trends in sales and constitute a profitable company – though more successful in some areas than in others. Trends include weekly, monthly, seasonal, yearly, and geographical variations by product group. Thus, sales patterns reflect what sports are popular in different countries. Data include the time frame 1998 through 2002 - both included.

ASSUMPTIONSThe following assumptions have been made in these scenarios:

1. The instructions.html file has been followed and implemented. Note the instructions.html file is created at the end of the Configuration process. These are the initial steps needed to create all users and servers.

2. The relevant user and group metadata identities have been created (possibly additional users/groups to step1).

3. The users and groups have been given the appropriate permissions in the repository ACT.4. The cube has been built successfully.

AUTHORIZATION FOR DIMENSION, HIERARCHY AND LEVEL OBJECTS You have a share holder that would like to have access of the total Global Profits of Orion Star. The cube contains Time and Geography dimensions and the measure Total Profits which the share holder will require in their report. The issue is this cube also contains information on Customers, Products, and Demographics so how do we hide these values from the share holder?

You can do this by denying read permission for the user (sas guest user) in the dimension properties of these two dimensions.

1. You navigate to the Dimension Properties by:

SAS Management Console Authorization Manager Resource Management By Location SASMain SASMain - OLAP Schema OrionStar Expand the Dimensions folder Right Mouse Click on Geography Dimension and select Properties

Figure 3: Authorization Path to set Dimension permissions.

2. In the dimension properties for Customer, Products, Demographics and Channel select your user, sas guest, and change the read and readmetadata permission to deny.

Figure 4: Denying Access for SAS Guest on the Customer Dimension

The latter (deny readmetadata permission) is a requirement for the SAS web-based applications such as SAS Information Map Studio, SAS Web Report Studio and Visual Data Explorer (OLAP Viewer component in SAS Information Delivery Portal), however it is optional for Enterprise Guide 3.0 where only a deny on the read permission is required.

Figure 5 : Denying Access for SAS Guest on the Product Dimension

For denying access to levels and hierarchies it is he same process but you deny read access on the specific hierarchy properties or level properties. Hierarchies and levels are in the respective folders below its associated dimension.

APPLYING MEMBER LEVEL SECURITY

Member Level Security allows an administrator to control what rows and columns (ie. members) that a user can see or not see in their OLAP report. In Orion Star Sports & Outdoors you have the following organizational structure:

Figure 6: Organizational Overview of Orion Star Sports & Outdoors

OrionStar Cube also has a Geography Dimension that corresponds to the areas that each of these managers is responsible for:

Fig

ure 7: Geography Dimension Levels

VP International

VP AmericasManaging Director

North America

Managing DirectorEurope

Managing DirectorAsia

Managing DirectorAfrica

Managing DirectorAustralia/PacificPresident

Sales Manager Germany

Sales Manager United States

All Level Continent Level

Country Level City Level

Africa

Asia

Australia / Pacific

North America

Europe Germany

United States

All Geography

The security that needs to be implemented in the organization is that each user can only see minimum their corresponding area. To define member level security to a user you need to go to the properties of the Dimension and add a condition to the relevant user. This condition is a MDX statement that generally will be communicated (via the OLAP Server) to the Client Application. Below is a table that gives the required MDX condition needed for each user.

Metadata Identity (User)

MDX Condition Description

President N/A No MDX expression is needed as this user has rights to see everything

VP Americas {[Geography].[All Geography], [Geography].[All Geography].[North America]}

Only North America was needed as Orion Star Sports but plans are being made to open a store in Brazil (Sth Am)

VP Americas (Continued…)

{[Geography].[All Geography], [Geography].[All Geography].[North America], [Geography].[All Geography].[South America]}

When Sales are made in South America then the condition will change to include this continent

VP International Except({[Geography].Members}, {[Geography].[All Geography].[North America]})

Using the Except function allows us to exclude North America which is easier than trying to write all the Continents that the VP International is in charge of

MD North America {[Geography].[All Geography], [Geography].[All Geography].[North America],[Geography].[All Geography].[North America].Children}

Using the .Children function lets the Managing Director of North America view the countries within his/her Continent.

{[Geography].[All Geography], [Geography].[All Geography].[North America],descendents([Geography].[All Geography].[North America]) }

If the managing director is also wanting to see the cities with the best sales then the Descendants function is the easiest way to give rights to many lower levels

{[Geography].[All Geography].[North America],Geography].[All Geography].[North America].Children}

To deny permission to the All level then you can write an expression that does not include it.

MD Africa {[Geography].[All Geography].[Africa],Geography].[All Geography].[Africa].Children}

Equivalent expression for Africa

MD Asia {[Geography].[All Geography].[Asia],Geography].[All Geography].[Asia].Children}

Equivalent expression for Asia

MD Australia/Pacific

{[Geography].[All Geography].[Australia/Pacific], Geography].[All Geography]. [Australia/Pacific].Children}

Equivalent expression for Australia / Pacific

MD Europe {[Geography].[All Geography].[Europe],Geography].[All Geography].[Europe].Children}

Equivalent expression for Europe

SM Germany (*) {[Geography].[All Geography].[Europe].[Germany], descendants([Geography].[All Geography].[Europe].[Germany])}

This MDX condition excludes the higher level Continent

SM United States (*)

{[Geography].[All Geography].[North America].[United States], descendants([Geography].[All Geography].[North America].[United States])}

This MDX condition excludes the higher level Continent

Table 2: Summarization of MDX Conditions that can be applied to each user

(*) Note there is an additional step needed for this type of permission condition that has excluded parent levels. In the hidden Level it is recommended to also deny readmetadata permission for that user as well.

This is a requirement for web clients – IMS, WRS, and VDE (SAS Information Delivery Portal), and an optional step for Enterprise Guide 3.0.

VP Americas member level security is the first example above. This can be used as an example on how to apply member level security for the rest of the users in Orion Star organization.

1. Go into the Geography dimension properties as you did in Step 1 in the previous section (Authorization for Dimension, Hierarchy and Level Objects)

2. Select the user VP Americas.

Figure 8: Initial view of the permissions for VP Americas user – note the Grayed Add Condition button

3. This can be ungrayed by explicitly granting READ access (remember when viewing OLAP data objects only read is required), this should make the background change from gray to white/blank.

Figure 9: Activating the Add Condition button to set member level security

Note that the gray color indicates that this has been inherited from a parent object while white indicates that the permission has been explicitly applied on this object.

4. The button is now ungrayed and you can add a condition.

Figure 10: Example of applying a MDX condition

RECOMMENDED READING

SAS Institute Inc. (2003), SAS 9.1.2 Intelligence Architecture: Planning and Administration Guide, CARY, NC: SAS Institute Inc.

SAS Institute Inc. (2003), SAS 9.1 OLAP Server Administrations Guide, CARY, NC: SAS Institute Inc.

ACKNOWLEDGEMENTSThanks needs to be given to Matthias Ender for reviewing the paper. Additional thanks to Cathy Phipps and Jennifer Reavis for explaining some of the internal workings of OLAP Authorization.

CONTACT INFORMATIONMichelle WilkieTechnical SupportSAS Institute (EMEA)michelle.wilkie@eur.sas.com