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
Overview of SSAS Security
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 Item
InvoiceLineItemKey
SalesRepKey
TakerKey
….
Revenue
COGS
Gross Profit
Sales Rep
SalesRepKey
LoginID
FullName
Region
Taker
TakerKey
LoginID
FullName
Branch
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 where
Taker 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 where
Taker 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 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
Invoices
allowed by
Taker role
Invoices
allowed 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;
else
return 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

More Related Content

What's hot

Viewers also liked

Similar to Data Driven Security in SSAS

Data Driven Security in SSAS

Editor's Notes