SAS® 9.

1 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 Intelligence Platform: Security Administration Guide.

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 Metadata

Accessing Building Building w. Deleting Connecting Viewing Viewing Changing
from ETLS to OLAP User Cube Permissions
client Change Server Sessions on OLAP
App. Management Objects
Readmetadata • • • • • • • •
Checkinmetadata •
Create
Writemetadata • • • •
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 DATA
The 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.

ASSUMPTIONS
The 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:

Managing Director
VP International Africa

Managing Director
Asia

Managing Director
President Australia/Pacific

Managing Director Sales Manager

Europe Germany

Managing Director Sales Manager

VP Americas North America United States

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:

All Level Continent Country Level City Level

Level

All Geography Africa

Asia

Australia /
Pacific

Europe Germany

North United States

America

Figure 7: Geography Dimension Levels

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 MDX Condition
(User)
President N/A
VP Americas {[Geography].[All Geography], [Geography].[All
Geography].[North America]}
VP Americas {[Geography].[All Geography],
(Continued…) [Geography].[All Geography].[North America],
[Geography].[All Geography].[South America]}
VP International Except({[Geography].Members},
{[Geography].[All Geography].[North America]})
MD North America {[Geography].[All Geography],
[Geography].[All Geography].[North America],
[Geography].[All Geography].[North
America].Children}
{[Geography].[All Geography],
[Geography].[All Geography].[North America],
descendents([Geography].[All Geography].[North
America]) }
{[Geography].[All Geography].[North America],
Geography].[All Geography].[North
America].Children}
MD Africa {[Geography].[All Geography].[Africa],
Geography].[All Geography].[Africa].Children}
MD Asia {[Geography].[All Geography].[Asia],
Geography].[All Geography].[Asia].Children}
MD {[Geography].[All Geography].[Australia/Pacific],
Australia/Pacific Geography].[All Geography].
[Australia/Pacific].Children}
MD Europe {[Geography].[All Geography].[Europe],
Geography].[All Geography].[Europe].Children}
SM Germany (*) {[Geography].[All
Geography].[Europe].[Germany],
descendants([Geography].[All
Geography].[Europe].[Germany])}
SM United States {[Geography].[All Geography].[North
(*) America].[United States],
descendants([Geography].[All Geography].[North
America].[United States])}
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
Description
No MDX expression is needed as this
user has rights to see everything
Only North America was needed as
Orion Star Sports but plans are being
made to open a store in Brazil (Sth Am)
When Sales are made in South
America then the condition will change
to include this continent
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
Using the .Children function lets the
Managing Director of North America
view the countries within his/her
Continent.
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
To deny permission to the All level then
you can write an expression that does
not include it.
Equivalent expression for Africa
Equivalent expression for Asia
Equivalent expression for Australia /
Pacific
Equivalent expression for Europe
This MDX condition excludes the
higher level Continent
This MDX condition excludes the
higher level Continent
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. (2006), SAS Intelligence Platform: Security Administration Guide, CARY,
NC: SAS Institute Inc.

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

ACKNOWLEDGEMENTS
Thanks needs to be given to Matthias Ender for reviewing the paper. Additional thanks to Cathy Phipps and
Jennifer Reavis for explaining some of the workings of OLAP Authorization.
CONTACT INFORMATION
Michelle Wilkie
Technical Support
SAS Institute (EMEA)
michelle.wilkie@eur.sas.com