Among the many new features coming w/ SSAS 2017, object-level security for tabular models is at (or close to) the top of the list for a few clients I work with. In fact, for 1 client, it is/was important enough that we decided to join the early adopter program (EAP) and officially run the preview version in production.
What is Object-Level Security?
In it’s simplest form, object-level security is a way to hide tables and/or columns from users.
But perspectives are also a feature that allow you to hide tables/columns from users. The difference is that hiding a table/column via perspectives does not prevent user (especially the crafty ones) from accessing the table/column via DAX or changes to the connection string. Perspectives are simply a good way to improve the user-experience by hiding clutter. They are NOT a security mechanism!
Object-level security doesn’t just “hide” tables/columns… it “secures” them. Unlike perspectives, if a table/column is secured via the Table and Column Security tab in the Role Manager window, then that user can’t access the table/column at all. It doesn’t show up in the field list when using tools like Excel or Power BI. It’s not accessible via DAX. It’s as if the table/column never existed at all.
Below is a quick look at the GUI. All you need to do is add a check mark to any column or table you wish to secure.
At the time we installed SSAS 2017 (CTP 2.1) and upgraded the tabular model to the 1400 compatibility-level, the Analysis Services Project template for Visual Studio 2017 hadn’t (yet) been updated to allow for defining object-level security via the GUI. As such, we were forced to generate the JSON-based role definitions and apply them after model deployment (think: Excel + .NET). Fortunately, this is no longer necessary as the updated Analysis Services Project template for Visual Studio 2017 were just released last week!
What are the alternatives?
To be sure, running preview software in production was a calculated risk. We first explored alternative options…
- create separate tabular models for each security requirement.
- implement a DAX workaround shared by Darren Gosbell
Option 1 requires maintaining a several models with only minor differences across the included tables/columns while option 2 required “adjusting” nearly every measure in the model. This client’s model consists of more than 60+ tables, 1200+ columns, 250+ relationships (yes, that’s right… several accumulating snapshot fact tables), and 480+ measures… so neither of these options were particularly appealing due to the amount of developer and administration overhead required.
Note: for a model with this many objects, you NEED to be on SSAS 2016 or higher and upgrade your model(s) to the 1200 compatibility-level simply for speed increase (during development in Visual Studio) that comes from a move to the JSON-based Tabular Object Model.
Additional Resources: