Categories
- All Categories
- 86 Oracle Analytics News
- 7 Oracle Analytics Videos
- 14.1K Oracle Analytics Forums
- 5.2K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 48 Oracle Analytics Trainings
- 59 Oracle Analytics Data Visualizations Gallery
- 2 Oracle Analytics Data Visualizations Challenge
- 4 Oracle Analytics Career
- 4 Oracle Analytics Industry
- Find Partners
- For Partners
How to implement complex role model in OBIEE 12c
Its easier to explain it by the example
- a lot of users
- 2 models (only in this example)
- there could be filters for each model
- some people should not have export to ext format
- some people shouldnt see some columns in some models
So every user can have different privs. First can see only data from one model, second only from another, next cannot export, next should have filter for one of the model, etc
As far as I know to implement this
FIRST I should create following roles
r1. Role with access to the first model
r2. Role with access to the second model
r3. Role without access to some columns of the first model
r4. Role without access to some columns of the second model
r5. Role with filter to the first model
r6. Role with filter to the second model
r7. Role with no access to Export
NEXT I should create a lot of end roles to grant them to end users
1. role included in r1
2. role included in r1 and r5
3. role included in r1 and r5 and r7
4. role included in r2 and r4
5. role included in r2 and r4 and r7
6. role included in r3
7. role included in r3 and r5
8. role included in r3 and r5 and r7
9. role included in r4
10. role included in r4 and r6
11. role included in r4 and r6 and r7
12. role included in r1 and r2
13. role included in r1 and r2 and r7
14. role included in r1 and r2 and r5 and r7
...............
and many others and then assign one role from the second step to each user
It is very complicated. Is there any way to assign some roles from the first step to the end user?
We have about 40 models (probably more) and thousands of users
Or Probably there is another easier way?
PS We autheticate user from Oracle database table (Security Block in repo)
Best Answer
-
I don't have an environment around using that kind of authentication (and I also don't have an OBIEE around anymore, and because it's a desupported feature in OAS I can't trust it would still work like before).
Row-wise initialization should still be a thing, I don't really see why it wouldn't work...
But I also remember something where some of these variables were semicolon separated lists, because they were designed to work like that because of some historical integration with something.
Maybe something to test: a "fake" row-wise because you provide the list as a string in a single row.
1
Answers
-
HI @ DENISKA80
Are you creating these users in RPD layer or DB layer and what version of BI are you using?
Regards,
Arjun
0 -
Hi,
I would say that in general the roles 1-14 of the second step isn't really required: a user can have many roles, and therefore you don't really need to create one role that includes a unique combination of of the r1 - r7 roles to then assign a single role 1-14 to your users.
Your complex requirement is somehow ... normal : I would expect most companies having a real usage of their OBIEE to have such kind of needs. Still, most ignore that step and setup a fairly random security.
What I tend to suggest most of the time is to split the roles into 2 different trees: one tree is for the features, the second tree is for the content.
In your example r7 is part of the first tree, r1-r6 are part of the second. Because, as you know, you can't control features by content (you can't say "don't allow to export content A but allow to export content B"). Therefore making a tree with the features using inheritance to build up more and more powerful roles, a bit like the default list of roles.
For the content, the tree can be as complex as your own needs: it can be basic with just "access to content A" (content A could be a subject area), or it can be a subset of tables or columns of a subject area and growing in permissions up to full content to A.
Then you assign a combination of roles to your users based on each specific need. In theory it is more practical to be able to build groups representing each profile of user. This allow to add your user to a group, and even if the user leave the company, the group representing the functionalities and content the user had is still there for when a replacement is hired. In your case you could also skip the groups part and go straight to the users if you really have a need of individual roles for each user.
At the end of the day, you have a fairly normal requirement. That's why the security model is a task that should be designed at the beginning and growing it while you develop your content instead of trying to build it fully after.
Also, scripting as much as possible the security model is a key element. I believe it's already the case for you as you are using the database.
0 -
Almost all users are in database. No users created in RPD layer. Couple created in Weblogic.
I mean the first ones
OBIEE 12.2.1.4.
0 -
@Gianni Ceresa thanks
Ok features and content are separate.
but , regarding content, if steps 1-14+ arent required how can i assign several roles to one user in the security block?
this script asigns only one role(r1) to user (and of cource all roles in wchich it was included in weblogic)
select
'1111' user_id,
'DEN' username,
'Den HZ' user_descr,
'r1' role_code,
2 loglevel,
'user' as user_group
from dual
union all
select
'1111',
'DEN',
'Den HZ',
'r2',
2,
'user'
from dual
0 -
Row-wise initialization IS A THING
semicolon works
Thanks!
0 -
One more question
If I configure OBI to use a database as the authentication provider by using a SQLAuthenticator (as described in official guide) how can i assign multiple roles to one user from databse similar to initialization block?
Of course all roles are phisically presented in weblogic
0 -
I would say that you will use the SQLAuthenticator to assign your users to groups ( ), all in the database (that's where you will manage who is part of what group), and then you just map groups to application roles (if you look at the sample database objects in the doc, you see it has users and groups and it handles all that in there).
This could be what I mentioned in my first reply: you have "simple" application roles (only doing one, or a few, things), and then you use groups to define the "kind" of users you want. This allow you easily have more than 1 user with the same permissions as the user can go, but the group stays and you can have many users in it.
You will fully move away from the RPD for authentication and authorization, while still using the database for the job.
1
