Home > BISM, SSAS > BISM – Tabular Security Gotcha! (Denied Permissions)

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
Categories: BISM, SSAS Tags:
  1. bhavikmerchant
    April 19, 2012 at 11:04 pm

    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.

    • April 21, 2012 at 3:43 am

      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).

  2. bhavikmerchant
    April 19, 2012 at 11:13 pm

    by the way, have you using something alone these lines tried this? “You can use the filter, =FALSE(), to deny access to all rows for an entire table.” http://msdn.microsoft.com/en-us/library/hh213165.aspx

  1. No trackbacks yet.

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

Follow

Get every new post delivered to your Inbox.

Join 228 other followers

%d bloggers like this: