Implementing A Data-Driven Security Model in SSAS: © Pariveda Solutions. Confidential & Proprietary

Implementing a data-driven
security model in SSAS
Pariveda Solutions. Confidential & Proprietary.
Contents
Overview of SSAS Security
The Use Case
The Problem
The Solution
Conclusion

The Use Case
The Problem
The Solution
Conclusion
SSAS Security
Overview
SSAS security is organized around database

artifacts
Security can be applied at multiple levels corresponding to different
objects:
Cube
Dimension
Dimension Data (row level)
Individual Cells
Static
Dynamic
Access to these is applied through Roles

Membership in a particular role is configured using Windows users
and groups no SQL accounts in SSAS!
Role permissions are additive
4

The Use Case
The Problem
The Solution
Conclusion
The Use Case
Business process: Order Invoicing (Sales)

Sells items
to a
customer
Custom
er
Enters the
order into
the ERP
system
Sales
Rep
Taker
Sees
measures
for items
which he
sold
Sees
measures
for items
which he
entered
Invoice
generated
Invoice Data
Dimensional Model
High-level Star Schema
For simplicity, our example

will focus on the following
key dimensions
Invoice Line Item

InvoiceLineItemKey
SalesRepKey
TakerKey
.
Revenue
COGS
Gross Profit
Sales Rep
SalesRepKey
LoginID
FullName
Region
Taker
TakerKe
y
LoginID
FullNam
e
Branch
Security Use Case 1: User has single role secured

by single dimension
Example 1: Sales Rep
Has access to all transactions which he/she sold
InvoiceLineItem => SalesRep.LoginID = Current User
Example 2: Taker
Has access to all transaction which he/she entered
InvoiceLineItem => Taker.LoginID = Current User
Security Use Case 2: User has two roles secured

by different dimensions
We might expect the security framework to provide the union of
both available subsets of data.
Invoice Universe
Sales
Sales
Rep =
Rep
Current
=
User Current
User
Taker Taker =
=
Current
Current User
User
And herein lies the challenge

9

The Use Case
The Problem
The Solution
Conclusion
The Problem
10
To handle this use case, create SSAS roles for

each business role
Each role will have read access to
our cube
The Membership for each role is
the Authenticated Users group
Security is applied using the
Allowed Member Set on the
Dimension Data tab
An MDX expression limits the
allowed set via the UserName() by
matching the current user to the
LoginID attribute of each dimension
Invoices where
Taker OR Sales Rep
=
Current User
Invoice Universe
11
Demo: Implementing user roles in Visual Studio
12
When a user is a member of both roles, SSAS

returns the entire universe!
Our user is a member of
multiple roles (as defined by
the Membership tab), and
those roles include dimension
data security based on
different dimensions (Sales
Rep, Taker)
In this scenario, our
dimension data security is
effectively ignored
Invoices where
Taker OR Sales Rep
=
Current User
Invoice Universe
13
Whats happening here?

The Taker role secures only the
attributes on the Taker dimension,
while the Sales Rep role secures
only its own attributes
The result is that each role provides
full access to the members of the
other dimension:
The Taker role secures the Taker

dimension
But the Sales Rep role gives open access
to all members of the Taker dimension!
This behavior is a consequence of

the additive nature of SSAS security
14
Invoices
allowed by
Taker role
Invoices
allowed by
Sales Rep
role
Invoice Universe
Out of the box, a solely data-driven approach

based on multiple roles is impossible
It is possible to implement with Active Directory groups,
but this isnt ideal
These groups must be maintained in the separate system; the
business processes no longer drives security
Any users with overlapping membership will still encounter the
issue
You will probably not find out about this error unless someone tells
you!
Lets explore some other options
15

The Use Case
The Problem
The Solution
Conclusion
The Solution
16
There are two primary workarounds to address

this behavior
Monolithic Security Dimension
Custom Role Assembly
17
Introducing the Data Security role and the

If we cant solve our use case with
multiple roles, combine them into
a single role!
The single role will secure a new
Security dimension
Members represent every
combination of fact and
dimension to be secured
Again, a dynamic allowed
member set permits users to see
only the data matching their login
from the UserName() function
18
Implementing the Security dimension in the

data warehouse or data source view
Implemented as a view or a
named query against the fact
and dimension tables
Selects all distinct
combinations of keys for the
dimensions to be secured
19
Demo: Implementing the Security dimension in

SSAS with Visual Studio
20
A custom assembly can also be used to shortcircuit additive security

Earlier we discussed the unexpected behavior of the
multiple roles approach:
Sales Rep provides open access to the members of the Taker
dimension
Taker provides open access to the members of the Sales Rep
dimension
We can prevent this by using custom code to build the

allowed members for the opposite dimensions in each
role based on user membership
21
Implementing the custom assembly

The assembly exposes a static
method, IsUserInRole
Queries the roles of the current user

Returns true when the specified role is in the
list
Used in the allowed member set of

the other dimensions for each role
For Sales Rep, we add attribute security for
the Taker role
Uses IIF to return the empty set if the user is
in the Taker role
If not, returns all members of the Taker
dimension
Becomes more complex as roles are

added to the cube
22
public static bool IsUserInRole(string

roleName)
{
AdomdCommand cmd = new AdomdCommand(
@"SELECT ROLES FROM SYSTEMRESTRICTSCHEMA
($System.dbschema_catalogs,
[CATALOG_NAME]
= '"
+ Context.CurrentDatabaseName
+ "')");
if (
(cmd.ExecuteScalar() as string)
.ToLower().Contains(roleName.ToLower())
)
return true;
else
return false;
}

The Use Case
The Problem
The Solution
Conclusion
Conclusion
23
Conclusion
SSAS provides a useful model for securing data within a cube based on
dynamic business rules defined within the cube itself
This model employs a so called additive approach when combining multiple
security roles for a single user
However, there may be some surprising (and undesirable) consequences
when a user has multiple roles based on different dimensions
There are 2 primary solutions to achieve this use case:
Custom Role Assembly
We have found the Monolithic Security Dimension to be a relatively clean
and effective approach, which fulfills the business requirements and leverages
out-of-the-box SSAS functionality rather than requiring a custom assembly
24
25
Appendix A: Implementing Individual Roles
26
27
28
29
30
Appendix B: Implementing Monolithic Security
31
32
33

Implementing A Data-Driven Security Model in SSAS: © Pariveda Solutions. Confidential & Proprietary

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implementing A Data-Driven Security Model in SSAS: © Pariveda Solutions. Confidential & Proprietary

Uploaded by

Copyright:

Available Formats

Implementing a data-driven

security model in SSAS

Pariveda Solutions. Confidential & Proprietary.

Pariveda Solutions. Confidential & Proprietary.

Overview of SSAS Security

Pariveda Solutions. Confidential & Proprietary.

SSAS security is organized around database

Access to these is applied through Roles

Pariveda Solutions. Confidential & Proprietary.

Overview of SSAS Security

The Use Case

Pariveda Solutions. Confidential & Proprietary.

Business process: Order Invoicing (Sales)

Pariveda Solutions. Confidential & Proprietary.

For simplicity, our example

Invoice Line Item

Pariveda Solutions. Confidential & Proprietary.

Security Use Case 1: User has single role secured

Pariveda Solutions. Confidential & Proprietary.

Security Use Case 2: User has two roles secured

And herein lies the challenge

Pariveda Solutions. Confidential & Proprietary.

Overview of SSAS Security

Pariveda Solutions. Confidential & Proprietary.

To handle this use case, create SSAS roles for

Pariveda Solutions. Confidential & Proprietary.

Demo: Implementing user roles in Visual Studio

Pariveda Solutions. Confidential & Proprietary.

When a user is a member of both roles, SSAS

Pariveda Solutions. Confidential & Proprietary.

Whats happening here?

The Taker role secures the Taker

This behavior is a consequence of

Pariveda Solutions. Confidential & Proprietary.

Out of the box, a solely data-driven approach

Lets explore some other options

Pariveda Solutions. Confidential & Proprietary.

Overview of SSAS Security

Pariveda Solutions. Confidential & Proprietary.

There are two primary workarounds to address

Pariveda Solutions. Confidential & Proprietary.

Introducing the Data Security role and the

Pariveda Solutions. Confidential & Proprietary.

Implementing the Security dimension in the

Pariveda Solutions. Confidential & Proprietary.

Demo: Implementing the Security dimension in

Pariveda Solutions. Confidential & Proprietary.

A custom assembly can also be used to shortcircuit additive security

We can prevent this by using custom code to build the

Pariveda Solutions. Confidential & Proprietary.

Implementing the custom assembly

Queries the roles of the current user

Used in the allowed member set of

Becomes more complex as roles are

Pariveda Solutions. Confidential & Proprietary.

public static bool IsUserInRole(string

Overview of SSAS Security

Pariveda Solutions. Confidential & Proprietary.

Pariveda Solutions. Confidential & Proprietary.

Pariveda Solutions. Confidential & Proprietary.

Appendix A: Implementing Individual Roles

Pariveda Solutions. Confidential & Proprietary.

Pariveda Solutions. Confidential & Proprietary.