Categories
- All Categories
- 15 Oracle Analytics Sharing Center
- 14 Oracle Analytics Lounge
- 211 Oracle Analytics News
- 41 Oracle Analytics Videos
- 15.7K Oracle Analytics Forums
- 6.1K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 78 Oracle Analytics Trainings
- 14 Oracle Analytics Data Visualizations Challenge
- Find Partners
- For Partners
OBIEE 12.2.1.4 to OAS 5.9, how to map security (user and groups to objects, data) in OAS
HI Gurus,
We are upgrading (out of place) from OBIEE 12c to OAS 5.9, point to note is in 12c we have a novell authenticator and in OAS we decided to move to AD.
Now we are done setting up OAS 5.9. Ready to move metadata from 12c to OAS,
Concern is:- i can generate a BAR file in 12c and import ONLY the RPD and catalog into OAS (excluding security as we are moving to new authenticator which is already configured in OAS)
I can see all AD users and groups in OAS weblogic console. But how do i replicate the user to objects (reports, dashboards, filters) and user to data level (suppose if a user is restricted to only last 2 years data and of a particular geographic region, say North America for eg.), how i can perform this kind of mapping in OAS as it exists in 12c.
Please note we have arounds 4000 users and same number of groups and they are assigned to different application roles.
How can i bring (recreate) all this setup in OAS ? Should we do manually for all "4000" users and groups ??!!!
Please share inputs.
Thanks
Answers
-
Hi Gurus,
can someone please advice on this .
Thanks
0 -
You had a security setup in 12. All you need to do is tie your new AD groups to your existing (migrated) AppRoles. Nothing else. There's not a single other moving piece.
And you can script everything via WLST.
You import the whole BAR. Including security. If you don't do that you're creating a mountain of work yourself which can easily be prevented.
0 -
Hi Chris,
You said "You import the whole BAR. Including security. If you don't do that you're creating a mountain of work yourself which can easily be prevented."
-- wondering if i import security also in BAR, it may wipe out the already configured AD authenticator in weblogic console..
Thanks
0 -
A BAR doesn't contains the security done in WebLogic console and doesn't affect that at all.
0 -
Thanks Gianni. So all it brings is app roles,
0 -
It has app roles and the members of app roles (so app roles being member of another app role, or accounts and groups being members of an app role).
I didn't check lately the full format of how the user and groups are referenced, it's possible that because you change the source (AD now), they are referenced differently and therefore you will need to redo that mapping from groups to app roles (you shouldn't map users directly, try to always use groups because a user can leave the company, a group not really).
0 -
"It has app roles and the members of app roles (so app roles being member of another app role, or accounts and groups being members of an app role). "
Above is a bit confusing, you say app roles and its members (groups and users -- ideally users not be assigned directly , got it ) are in BAR.
If BAR brings users and groups, and we already have users and groups from the new (AD) authenticator in console, so we need to manually delete all expired/irrelevant users/groups in EM ? and also as Chris suggested map these AD groups/users to imported App roles in EM ?
Thanks
0 -
Do not confuse the definition of a user and a reference to a user.
The BAR contains references to users and groups, because users and groups aren't created in EM, App roles are created in EM and therefore those are created based on what has been exported in the BAR.
The OAS security has 2 sides: in WebLogic console you define the authenticators etc., you point to what contains your users and groups or you define users and groups in the internal LDAP of WebLogic.
In EM you only reference users, groups that exist somewhere else (in WebLogic console either as imported from AD or from the internal LDAP).
If you import that from the BAR, anything existing right now in EM will be deleted first and only the import will exist.
0 -
Aren't you two prolific tonight.
a) there's two security worlds: the "external" (where OBI/OA is concerned) WLS security world with security adapters on the one hand and then the "internal" world in EM with AppRoles
b) the import brings in AppRoles and their members: the so called security principals. These principals are either users (external world), groups (external world) or approles (internal for inheritance)
c) you just bring in everything. the security "structure", not the technical "config" of the adapters. you can always parse through it by code and kill all assignments of type user or group (if your new AD doesn't match anything that was there - I'm assuming here)
d) what you will need to do is create the assignment and that i wholeheartedly propose to utilize WLST. no need to know coding. even myself I'm too lazy and mostly concatenate the statements via excel or SQL and the copy+paste
0 -
Edit: Gianni and me did whole security workshops which sadly weren't recorded but I did another one last year which was:
0
