Recently, an OAUG member submitted a question about establishing a security model to accommodate multiple user hierarchies across two Essbase platforms. I was honored to be tapped as a subject matter expert who could provide assistance.
I thought others might have similar questions or, better yet, have additional ideas regarding Essbase security. So, I'm sharing the Q&A here. If you find this information helpful, please share with others. And be sure to leave a comment if you have experience working with security hierarchies or have additional questions.
We are revising our security model and have a situation where we have multiple hierarchies in a specific dimension. Each hierarchy has the same level 0 members (stored in one hierarchy; shared in all others) but different parent rollups (e.g., stores by business channel, stores by state, etc.). Some users will be permitted to see all dimension members. However, there will be a portion of our user base that should not see all of the dimension members.
One solution to restricting these users' access is to go through each hierarchy and give access to a large number of specific parent members. While this method would work, this would make the security model very complex and vulnerable to hierarchy changes, both of which could negatively impact the users and admins alike. I would like to know if you have come across this situation before with another OAUG member and if there is another method that you could share with us that may make our model less complex and less maintenance intensive.
The security changes would be applied individually to two separate Essbase ASO cubes and a Planning BSO cube.
- Security groups could help if there are multiple users that have the same access. For example, instead of assigning 5 people to the same hierarchy member, create one group, assign it to the member, and add the 5 people to the group. Additionally, you can use the groups across applications if it makes sense for your business.
- Go as high on the hierarchy as you can, and use relationships where possible. I commonly set security at the parent level and use the "descendants of" relationship so that as members move, the security stays dynamic.
- Depending on your situation, you may choose to allow all access at the top roll-up and then choose to apply "no access" to certain levels below. You'd only want to do this if the information that users shouldn't see is in a logical hierarchy.
- Practically speaking, I usually push to have as high of a security model as allowable for the business. It is important to understand the concerns of allowing higher level access. For example, if the concern is someone overwriting data they shouldn't, I may leave security as is but limit who can access certain web forms in planning, or set read vs. write access at the roll-up level.
Your comments are invited and most welcome. Additional insights from the OAUG users' community accelerates learning and problem solving for everyone. And be sure to subscribe to this blog post or the general OAUG blog to be notified when updates are available.
P.S. The recent COLLABORATE 17 conference featured more than 100 sessions in the EPM/BI educational track. The conference presentations and white papers from the COLLABORATE 17 – OAUG Forum have just been added to the OAUG Conference Paper Database. Browse or search to locate titles, and use your OAUG member login to download materials.
Beth McLaughlin is a financial systems manager with Dunkin' Brands.