Looking at a week of posts in the OTN forum there is always at least one thread about security. And the questions aren't the scariest part: some of the answers provided by "experts / advanced users" are worst, mixing the different levels of security and what is supposed to be done where.
Making life more difficult in this security jungle OBIEE has some contradictions between these security layers, where in some cases "no access" is weaker than "read", yet "deny" is stronger than "grant"!. The inheritance mechanism of Application Roles adds another level of complexity to this already-complex situation.
Putting all this together many developers aren't really sure what happen when a user has multiple application roles assigned to him with contradictory security rules.
There is not a simple single and unique answer to this topic but it's possible to cover most of the needs by adopting a generic security strategy that we will present here, like a kind of best practice to start with and extend based on requirements. This approach has been refined over the course of numerous client projects, many threads on OTN, and a reflection on the multiple available solutions. Whilst no solution can be truly universal the model that we present will act as a benchmark by which to judge the strengths (or weaknesses) of custom security solutions implemented for OBIEE elsewhere.