The BO security model: an introduction

Over the years I have seen a lot of BO security models. Probably most of them were quite nice when they were implemented. They always start out as simple and structured models and everybody is determined to keep it that way. I am sure that if there were no business users on the system it would stay that way, simple and structured. But in real life a security model evolves, new business departments join and have different needs: we don’t want everybody to be able to schedule reports. More mature BO users may come up with extra needs: we want some users to only see their own instances and others to see all instances. The system grows: we only want to see a list of our colleague’s when we sent a report not the whole world. And new functionality to BO is added, like the commentary in BO 4.2.

After some time the simple and structured model begins to turn into a big ball of mud: haphazardly structured, sprawling, sloppy, duct-tape and bailing wire: 

• complete custom access levels (CAL) are copied and then one little thingy is changed
• user groups are created with weird names and very specific functions
• users are directly assigned to folders and given advanced rights 

In this blog series I would like to share some insight I gathered over the years. These can serve as guidelines the next time you have to work on a model. 

·         This blog series is aimed at experienced BO administrators, which means there will be no how-to screenshots

·         This blog series can be used as a guideline, it cannot be used as a manual

·         This blog series only covers the internal BO stuff. No windows AD or SAP roles and no IAM software

When I’m implementing a new security model I want it to be effective. Where effective stands for: simple and structured. But also maintainable, flexible, expandable and easy to use.

Simple, structured, maintainable, flexible, expandable and easy to use. That’s a lot! Well actually they are interrelated, if you give it structure and keep it simple it will be easy to use and maintain. And if you’re lucky it turns out to be flexible and expandable as well. 

I never re-use any of the existing CALs because I don’t want to mess with the existing model. When you create new CALs you can run both models on the same system for comparison and testing. And reverting to the original model in case of issues is easy, just delete all the new CALs.

I prefer to create the new model on a sandbox machine and when it’s finished and tested, promote it to a live system. Start with development, then test, UAT and production. When issues are found resolve them, go back to the sandbox, make the same adjustments to your model and start promoting again.

If a model is a mess, don’t recreate the mess in a structured way. If a model is a mess manage expectations and preach that the new model will not be exactly like the old one.

A BO security model consists of: 

• access rights (view, edit, delete etc.) 
• users 
• objects (reports, universes, connections etc.) 
• assignments: the relations between them 

There are hundreds of access rights, they will be grouped in custom access levels (CALs).
There can be hundreds of objects, they will be grouped in folders.
There can be hundreds of users, they will be grouped in user groups

In the assignments I will only use these grouped items: folders, user groups and CALs.

It is a humongous mistake maybe even a mortal sin to assign directly on an object ! Even if it is only once ! Exception: Calendars don’t have a folder structure, if you want Calendars to not be visible to everybody you should grant access on object level.

In the next blog I will talk about the structure of the model from a very high level.