Applying security in OBIEE involves a myriad of controls that weave layers of protective barriers over the data. 
There are three Main layers, each with it own strata that work in isolation or in association with the other layers.
The main layers (from bottom to top) are:
- Database
- OBIEE Application
- Location
The Location layer is quite simple, it’s where you expose the web address and it’s how you decide who can see the web page. For example, In a simple development environment you may have your server on a separate subnet, which is only accessible to developers using computers or virtual machines on that network.
Access to web servers can actually be restricted too, maybe behind a firewall, or to a specific set of IP addresses. Windows Kerberos security can be employed to make sure you only allow access to the server from already authenticated people.
Dont forget the simple controls that the location of a server can bring, and please don’t expose your server to the internet directly (Or Christian will hunt you down!)
The Database layer has a wealth of security measures to protect the data.
A brief glance at the Oracle website, oracle /database /security, will show all the layers available in the database – similar options are available on MS SQL server too.
The simple measures not listed are also important to consider, for example the use of Separate Schema to separate your data. You can keep HR records separate from Finance, separate from Sales etc, by placing the data into separate Users, or separate Pluggable databases even! A common database security measure is Virtual private Database (VPD) which is worth examining, although I prefer to keep this sort of security in the application layer to keep it more flexible.
Data masking and data redaction can help to hide the real values, as well as database vault can keep the real data away from unauthorised users – like DBA’s!
The OBIEE Application layer has a mixture of Object Security and Data level security.
Object security is available in all three layers in the RPD and also available in the catalog. The common theme is that the both use users and groups to determine what you can see. The recent change to remove the very handy Catalog groups from the equation is a real shame, but at least Application Roles can do the job nicely, and could be sourced from corporate directories.
It’s worth pointing out that user roles use a hierarchy of permissions, or inheritance if you like. This can get really confusing if Roles are members of other roles, which have conflicting permissions. I prefer to keep a flat hierarchy of roles (i.e. no parent-child relationships) which makes my life simple.
Data level security is applied to the business layer of the RPD. It magically adds a where clause to your queries, nicely hiding some data, and if you design it right, letting you see the big picture.
The trick with data level security is to secure only those dimensions that need securing.
You can also build your own fine grained security, just by making use of object security or just exposing subsets (using content levels or different views in the source).
In the next article in this series we will look into Object security in the Catalog..