Question:
What is the best way to resolve the following scenario:
We need to secure data by an attribute of Employee, for example Gender.
1. 0GENDER has been flagged as authorization-relevant via RSA1.
2. Created authorization object through PFCG or RSSM
3. Assigned the authorization object to a user role
4. Created an authorization mandatory variable
5. Included the authorization variable in a query.
Ideally, we would like to have one cube & one object EMPLOYEE__GENDER, with some people having access to gender and others no access to gender.
My understanding (which could be wrong) is as follows:
If you have an InfoObject which is authorization-relevant in the query you are querying & have an authorization variable in the query, then the person will get "Not Authorized", if they are not authorized to see the data. They will get this message instead of data. Those who do have access will see data.
If the InfoObject is in the InfoCube in which you are querying, but NOT part of the query, do those who do not have access to this field see other data without an authorization error? I think so.
If you have ":" (colon) in the authorization object via RSSM, then when the object is in an InfoCube and not specifically called in the query, the authorization check for that is bypassed and data could be displayed, for example through a display attribute of Employee (some people should see this, others should not see this). In that case you end up with a user who can see more data than they should. Or if a query developer forgets to include the authorization variable in the query, a user could see more data than they should.
Is there another option besides ":" to control this. I know there is "*" for full authoriztion for characteristic values and "#" for not assigned values.
If my understanding is correct, this seems like a hole in the security model. As a work around, we may need two different InfoObjects - Employee-Secured Data & Employee Non-Secured data with two different InfoProviders (I would actually use MultiProviders - based on the same InfoCube) one for secured data, using the employee secured objects and one for non-secured employee data, both cubes would be used to view headcount & actions.
Please let me know your thoughts. I was hoping we could have one object (0EMPLOYEE) & one cube (0PA_C01), but because we do not want to have security compromised by a query developer not including an authorization variable in a query or someone including a display attribute, we may need to change our model. I know we can lock down the queries/workbooks once they are rolled out to the users, however we would like this resolved at the object level and not rely on using authorization variables in the query to control this.
Any insight or clarification would be greatly appreciated. Thanks for your help!
Answer:
I'm moving this one to Security.
Answer:
The use or omission of authorization variables will not compromise your security, they simply allow you to restrict the results of a query based on the user's access. For example, a cost center manager sees only results for his or her cost center without having to explicitly select it. However, your situation is not like this -- you don't want to restrict results by gender, only the ability to report by gender.
Using ':' should achieve the result you want, it allows people so see all the data as long as it is summarized by gender -- i.e. they cannot filter or drill down by gender. If gender is also a separate display attribute of employee you should also make it authorization relevant; the effect of this is only to hide the attribute, it does not restrict query results (unlike characteristics and navigable attributes). So for users who are not permitted to report by gender you would not make any assignment for the display attribute authorization.
The following post includes a link to the section of the on-line help that describes the use of symbols in BW authorizations:
/forums/viewtopic.php?t=103981
Answer:
Thanks for the response. The information provided helped in our discussions with our security group, as a result I think we are on the right track. We are testing to make sure we do not have any holes.