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.