Advanced Analysis Services Security Chris Webb Crossjoin Consulting Limited

Who Am I? Chris Webb – Independent Analysis Services consultant and trainer Author: “MDX Solutions” and “Expert Cube Development with SSAS 2008” SQL Server MVP Blogger:

Agenda Dimension Security Cell Security Dynamic Security Performance Impact of Security Security in the Tabular Model

Assumptions You know SSAS cubes You know how to do basic dimension and cell security You know a little bit about the Tabular model in SSAS 2012 You’re interested in a deep dive about SSAS security!

Testing Security Roles can of course be tested in BIDS by pressing the Change User button They can also be tested in SQLMS by setting two connection string properties (if you’re an administrator): –EffectiveUserName – connect as if you were this user –Roles – connect as if you were a member of one or more roles

BIDS Helper BIDS Helper Roles Report does the following: –Documenting your roles and permissions –Finding out who has access though which role –Identifying causes of errors, such as invalid members Duplicate Role allows you to copy roles –Native copy/paste only creates a new role with no permissions defined but same membership

Securing Database and Cube Dimensions Securing a Cube dimension means you secure just that instance of a dimension in a cube Securing a Database dimension means you secure every instance of that dimension in every cube in the database –But errors when you have role-playing dimensions!

Allowed and Denied sets In dimension security, a role makes allows access to all members in the Allowed set, except those present in the Denied set Always use the Allowed set to grant access, rather than denying access to specific members –What happens if new members appear on the hierarchy?

Denying Access to Levels and Dimensions An empty Allowed set allows you to prevent access to an entire attribute or level No way of denying access to an entire dimension easily –Have to deny access to everything except the All Member on all attributes on a dimension –Then have to hide the dimension itself, maybe with a perspective

Multiple Roles Users can be members of multiple roles In that case a user will see everything each individual role can see unioned together –If one role allows access to a member and one denies, the user is allowed access

Parent/Child Hierarchies When applying dimension security to a parent/child hierarchy: –We cannot apply security to the key attribute –Granting access to a member on a p/c hierarchy means you grant access to all its ancestors –By default, granting access to a member also grants access to all its descendants, unless you explicitly deny access to them For dynamic security it causes even more complications…

MDX Script Errors If a calculation references a member that a role has denied access to, it will lead to an error in the MDX Script It is possible to ignore MDX Script errors, but this could mean you miss errors you do want to see Instead, use IsError() to detect if an expression returns an error Then use named sets and scoped assignments to perform calculations conditionally

Read and Read Contingent In cell security, a read permission allows/denies access to individual cells Read permissions are extremely easy to get around though, so don’t use them! Read contingent permissions take the extra step of checking to see if you have access to the cells a calculation needs to access

Replacing Cell Security Cell security can be avoided by creating a new dimension on your fact table –Create a new key on the fact table that is 1 for all rows to be secured, 0 for everything else –Then build a dimension with 1 and 0 as members and apply dimension security –Then make the dimension invisible to users –Not so easy to do with Measures 

Dynamic Security Dynamic security is when a single role can return different permissions for different users A role can be dynamic by either of two functions: –UserName(), to return the Windows username of the user that is connecting –CustomData(), to return the string passed in through the Custom Data connection string property. Useful when a front-end app is handling authentication.

Dynamic Security Approaches There are two basic approaches to implementing dynamic security: –Call a custom MDX function in a.NET dll to return details on permissions –Model permissions into dimensions and measures in your cube, then query them from within the role

Dynamic Security Approaches The measure group approach is to be preferred: –It’s faster – permissions are evaluated several times during login –When permissions change the cache needs to be cleared: For the dll approach you have to clear all caches on the cube For the measure group approach you need to reprocess just the measure group, which leaves SE caches on other measure groups intact

Dimension Security and Performance Different dimension security permissions can result in different query plans –Always build aggregations with roles in mind Formula Engine cache-sharing is also affected –Only users with exactly the same permissions can share FE caches –With dynamic security, FE caches are never shared

Cell Security and Performance Cell security can be very bad for performance: –It prevents the use of bulk mode for calculations –It prevents the caching of the results returned by MDX calculations for more than the lifetime of a query For this reason alone, avoid using it!

Security in the Tabular Model Tabular security is very similar to dimension security but operates on the row level No concept of denied sets though Nothing equivalent to dimension security

THANK YOU! For attending this session and PASS SQLRally Nordic 2011, Stockholm