I think you might find this to be a little cumbersome, but possible. You are on to something with the central table for authorizations however
- I like the idea of a central table that hold all of the analytic privileges, a 3 column structure with USER | COLUMN | VALUE would suffice.
Since each view will need to be checked for different columns, you will end up writing a stored procedure for each of the columns that need to have security applied. Imagine checking an authorization would be SELECT VALUE FROM <AUTH_TABLE> WHERE COLUMN = 'COUNTRY' AND USER = SESSION_USER. This would get the authorized values for a given column for that user.
- In the case that there is no value found for a given column of data that a user is authorized for, they will not be able to see the view in any of the front end tools.
- With the above point in mind, you still have to be cautious that a user authorized for a given column across two views should not see the views they logically are not allowed. Take for example two models, Finance and Sales. A given Sales user may be authorized for COUNTRY = 'GERMANY', and therefore be allowed to see the Finance view as well, which is probably not desired behavior.
- Keep in mind that the CalcEngine is invoked and there is a *very small* overhead to each column that a user needs to be evaluated on. This is called for every column, even if the user is not accessing a model with that column.
My conclusions
- A central table for authorizations is a great idea
- Create the analytic privileges to cover the various roles as needed (Finance/Sales/etc) in order to ensure the functional areas are contained.
- Use dynamic AP's with stored procedures that read from the central table for any columns that should be restricted.
I have implemented a simple version of the above for one functional area and it works great.
Regards,
Justin