Data Driven Security in SSAS

Implementing a data-driven

security model in SSAS

© Pariveda Solutions. Confidential & Proprietary.1

Contents

Overview of SSAS Security

The Use Case

The Problem

The Solution

Conclusion


SSAS Security

Overview


The Use Case

The Problem

The Solution

Conclusion


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

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”


Static

Dynamic

The Use Case



The Use Case

The Problem

The Solution

Conclusion

Business process: Order Invoicing (Sales)


Sales RepCustomer Taker

Enters the order into the

ERP system

Sells items to a customer

Invoice generated

Invoice Data

Sees measures for items which

he sold

Sees measures for items which he entered

Dimensional Model


Invoice Line ItemInvoiceLineItemKeySalesRepKeyTakerKey….RevenueCOGSGross Profit

Sales RepSalesRepKeyLoginIDFullNameRegion

TakerTakerKeyLoginIDFullNameBranch

High-level Star Schema For simplicity, our example will focus on the following key dimensions

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


Invoice Universe

Sales Rep = Current

User

Taker = Current

User

Taker =

Current User

Sales Rep =

Current User

And herein lies the challenge…

We might expect the security framework to provide the union of both available subsets of data.

The Problem



The Use Case

The Problem

The Solution

Conclusion

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


Invoice Universe

Invoices whereTaker OR Sales Rep

= Current User

Demo: Implementing user roles in Visual Studio


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


Invoice Universe

Invoices whereTaker OR Sales Rep

= Current User

Invoice Universe

What’s happening here?

The Taker role secures only the attributes on the Taker dimension, while the Sales Rep role securesonly 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


Invoicesallowed by Taker role

Invoicesallowed by

Sales Rep role

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 isn’t 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!

Let’s explore some other options…


The Solution



The Use Case

The Problem

The Solution

Conclusion

There are two primary workarounds to address

this behavior

Monolithic Security Dimension

Custom Role Assembly


Introducing the “Data Security” role and the

Monolithic Security Dimension

If we can’t 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


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


CREATE VIEW [dbo].[vDimSecurity] WITH SCHEMABINDING AS SELECT DISTINCT

SalesRepKey = Rep.SalesRepKey, SalesRepLoginID = UPPER(RTRIM(LTRIM(Rep.LoginID))), TakerKey = Taker.TakerKey, TakerLoginID = UPPER(RTRIM(LTRIM(Taker.LoginID))),

FROM dbo.FactInvoiceLineItem InvLn INNER JOIN

dbo.DimSalesRep Rep ON InvLn.SalesRepKey = Rep.SalesRepKey INNER JOIN dbo.DimTaker Taker ON InvLn.TakerKey = Taker.TakerKey GO

Demo: Implementing the Security dimension in

SSAS with Visual Studio


A custom assembly can also be used to short-

circuit “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


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

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;

elsereturn false;

}


Conclusion



The Use Case

The Problem

The Solution

Conclusion

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:

– Monolithic Security Dimension

– 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


Appendix A: Implementing Individual Roles


Appendix B: Implementing Monolithic Security


Data Driven Security in SSAS

Documents

Transcript of Data Driven Security in SSAS