OBIEE Security: It's a Jungle Out There

Bf71450537acca19e045ae6f7febdf9a?s=47 Gianni Ceresa
December 05, 2016

OBIEE Security: It's a Jungle Out There

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.

Bf71450537acca19e045ae6f7febdf9a?s=128

Gianni Ceresa

December 05, 2016
Tweet

Transcript

  1. None
  2. • • • • • • • • • •

    • • • • •
  3. • • • • • • • • • •

    • • • • • • •
  4. • • • • • • • • • •

    • • • • •
  5. • • • • • • • • • •

    • •
  6. None
  7. None
  8. • • • • • •

  9. None
  10. None
  11. • •

  12. • • • • • • • • • •

    • • • • •
  13. • •

  14. • • • • • • • •

  15. • • • •

  16. None
  17. None
  18. None
  19. None
  20. None
  21. • • • • • • • • • •

    • • •
  22. None
  23. None
  24. None
  25. • • •

  26. • • • • • • • •

  27. None
  28. None
  29. • • • • • • • •

  30. • • •

  31. • • • • • • • • • •

  32. • • • • • • • • • •

    • •
  33. • • • • • • • • • •

  34. • • • • •

  35. • • • • • • • • • •

    • • •
  36. • • • • • • • •

  37. None
  38. • • •

  39. • • •

  40. None
  41. • • • • • •

  42. None
  43. • • • • •

  44. • • • • • • • • • •

    • • • • •
  45. • • • •

  46. BI Consumer BI Analyst BI Author BI Administrator Finance BI

    Consumer Finance BI Analyst Finance BI Author HR BI Author HR BI Consumer HR BI Analyst BICC departments / BU These roles are more placeholders holding permissions for inheritance A “BI Developer” role can be added underneath the Admin
  47. • • • •

  48. • •

  49. • • BI Consumer BI Analyst BI Author BI Administrator

    Default OBIEE application roles
  50. • • •

  51. • • • • • BI Consumer BI Analyst BI

    Author BI Administrator OBIEE privileges HR BI Author HR BI Consumer HR BI Analyst Web catalog and RPD objects permission
  52. • • •

  53. • • • • BI Consumer BI Analyst BI Author

    BI Administrator OBIEE privileges HR BI Author HR BI Consumer HR BI Analyst Web catalog and RPD objects permission Finance BI Consumer Finance BI Analyst
  54. • • • • • • • •

  55. • • • • • • •

  56. • • • • • • • • • •

    • • • • •
  57. • • • • •