BISM – Tabular Security Gotcha! (Denied Permissions)


And as the marketing saying goes “Now that I’ve got your attention”. In my last post, (BISM – Tabular Security Model) I commented that role based tabular model security was similar to traditional SSAS. While this is true, the tabular model has no concepts of denied permissions, and I think this is worthy of a small but separate post.

I’ve raised this on the Denali (Pre-Release) forums (see here). Cathy Dumas from the product team (her blog is here) comments that there is no denied permission and that permissions are additive (as one would expect).

This subtle difference is important to identify. The statement ‘table‘[column]<>’value‘ is not a denied permission on the columns value. Rather, it is an allowed permission on everything else other than value. If the value row data is permitted through some other role, the user will see the data that was previously excluded (under the role ‘table‘[column]<>’value‘).

This is a change from the denied permissions of the UDM. In this model, denied permissions took authority over the accumulative allowed permissions so that restrictions could be actively applied. In situations where the same account is covered by many roles, the tabular model lack of denied permissions will require more stringent security controls.

About these ads

3 thoughts on “BISM – Tabular Security Gotcha! (Denied Permissions)

  1. spotted a couple of typos in the above… can you approve this one instead!

    Hmm this is interesting. i hadnt realised as ive not much done much with roles in the new model!
    I thought perhaps the use of a security dimension/table, which is common for more complex or easier to maintain multidimensional security scenarios would work. The documentation states that DAX expressions can grant access to “any related rows in the many direction” … but i dont know of any function in SSAS Tabular to get the username.. like USERNAME() in MDX. Again we would need to use the ‘table’[column]‘value’. So i dont know if its plausible even with the ability to get a username.

    • Hi Bhavik, There is already a method to implement dynamic security in tabular which is essentially the same as the method in OLAP. It uses a bridge table to derive allowed rows and a sumarize to restrict member access based on the username. Also, unlike OLAP you can use this idea of FALSE() to deny any permission the the security table so that a user cannot see the security table data (which is not available in OLAP).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s