Oracle BI EE 11g – Migrating Security – Policy Store – Part 2

April 5th, 2011 by

In the last post, we saw how to go about doing a security migration of the Identity Stores. Today we shall look at the migration process of the Policy Stores. Just to give a brief background, Policy Store is nothing but a physical file that contains the Application Role, Applications Policies and their corresponding mapping to the Weblogic Users and Groups. So, anything that is accessible from within the EM Security Page (shown below) will be present within the Policy Store. In BI EE 11g, the entire Policy Store exists as a single file called as the system-jazn-data.xml. This file generally exists under {Middleware_Home}/user_projects/domains/bifoundation_domain/config/fmwconfig directory.

To illustrate, shown below are a couple of screenshots. The first screenshot contains the actual EM UI where Application Roles are created or modified. The second screenshot shows how the roles that are created in the EM UI are stored within the system-jazn-data.xml file.

NewImage

NewImage

Migrating application roles from one environment to another is even more important as generally the Application Roles will more or less be the same across environments. In BI EE 10g, as the GROUPs were maintained within the RPD, there was no additional need to move the GROUPs separately. But in BI EE 11g, the Application Roles will have to be moved separately. Lets look at the possible ways of migrating the application roles from one environment to the other

Full Migration of Application Roles using WLST:

Unlike Identity Stores where we had an option to export the entire embedded LDAP provider, there is no such option for application roles. So, to move application roles we will have to use Weblogic Scripting (WLST). Let’s again take the example of 2 environments Dev and Prod. In Production we have the following Application Roles.

1. BISystem
2. BIAdministrator
3. BIAuthor
4. BIConsumer
5. ReportAuthor
6. ReportDeveloper

NewImage

In the Dev environment,  we have the following Application Roles.

1. BISystem
2. BIAdministrator
3. BIAuthor
4. BIConsumer
5. ReportAuthor
6. ReportConsumer

NewImage

Basically there are 3 main differences between the Dev and Prod environments.

1. ReportAuthor role exists in both environments. But weblogic user is assigned to this role in Prod but not in Dev.
2. ReportConsumer role exists only in Dev.
3. ReportDeveloper role exists only in Prod.

To migrate security there is a WLST method called as MigrateSecurityStore which can move the roles from one system-jazn-data.xml to the other. To do that, we need to first copy the system-jazn-data.xml from Dev instance to the Prod instance (to a temporary directory). In the same way copy the system-jazn-data.xml from the Prod instance to the temporary directory as shown below.

NewImage

Also, take a backup of all these files before doing the migration. Now, copy the jps-config.xml from any one of the instances (Dev or Prod) to the temporary Directory as shown below. And rename the file to jps-config-policy.xml.

NewImage

Open up the jps-config-policy.xml. You will notice that this file contains all the details about all the stores in the environment. Now, for policy migration, we need to basically use this file to point to the locations of the Dev and Prod (source & target) system-jazn-data.xml files. Also, since we are doing only policy migration, we do not need the other store related tags within this file. Remember that we are modifying only a copy of the jps-config.xml. This copy file will be used only for migration. The modified file is given below

 

NewImage

 

Now that we have our jps-config file ready, navigate to the temporary directory from command prompt and initialize the WLST using the following command.

NewImage

In WLST, application role migration can be done even in offline mode. So, effectively there is no need for us to connect to the weblogic admin server. In offline interactive mode, fire the following command

migrateSecurityStore(type=”appPolicies”, srcApp=”obi”, configFile=”C:/SecurityMigration/jps-config-policy.xml”, src=”sourceFileStore”, dst=”targetFileStore”, overWrite=”false”)

NewImage

You will see a lot of warnings like Identity Store not found etc. These can be safely neglected as we are only moving the policy store. If you now open up the Prod system-jazn-data.xml (under the temporary directory), you will see that the application role which existed only in Dev (ReportConsumer) would now exist in this file as well.

 

NewImage

To understand what exactly happened, lets stop the Prod BI EE instance and overwrite the existing system-jazn-data.xml file with the migrated one. If we now look at the list of roles in the EM, you will notice that a merge has happened (with no overwrites on existing roles in Prod).

NewImage

But if you notice, the weblogic user which was assigned to the ReportConsumer role in Dev has not been migrated. Let’s find out why. Maybe it’s because our jps-config-policy.xml did not have the connectivity to identity stores, it was not able to migrate the weblogic user. To validate this, lets go back to the dev environment and assign the BIConsumer role to the ReportConsumer role. Also, lets add ReportDeveloper role as well but with BIAuthor role assigned as shown below.

NewImage

Let’s now run the Migration again. Again neglect the warnings and restart the BI Services with the migrated security-jazn-data.xml file.

NewImage

Even now its the same. The member assignments are not carried over during the migration. I am not sure whether it is a bug or an intended behaviour. But be aware of the fact that while doing the app role migration, the member assignments are not carried over. We will have to reapply the assignments post migration.

Incremental Migration of Application Roles using WLST:

As shown above, full migration cannot migrate the member assignments of an application role. Also, full migration does not allow us to pick and choose the roles that we would like to move. To do an incremental Role by Role migration (and to automate it), there are a separate set of WLST commands that can be put to use. We will start off with some simple ones and then move on to the actual incremental migration.

Listing Application Roles using WLST:

The first command we will see is used for listing the complete application roles that we have as part of BI EE. This command is what is used internally by the EM to display the list of Application Roles. The command for that is given below

connect(“weblogic”,”welcome1″,”localhost:7001″)
listAppRoles(“obi”)

NewImage

Listing Application Role Members using WLST:

To list all the members that are present within a role, there is a command called as listAppRoleMembers which can give us the complete listing. Again, this is what is used by EM internally to extract all the member related information of a specific Application role.

connect(“weblogic”,”welcome1″,”localhost:7001″)
listAppRoleMembers(“obi”,”BIConsumer”)

NewImage

Creating Application Roles using WLST:

To create a new role using WLST, there is a command called as createAppRole which can create roles automatically. For example, lets create a new Role called as ReportWLSTRole from the command line and see whether that appears within the EM.

connect(“weblogic”,”welcome1″,”localhost:7001″)
createAppRole(“obi”,”ReportWLSTRole”)

NewImage

NewImage

Assigning Members to an Application Role using WLST:

And finally to automatically assign members to an application role, we can use the grantAppRole command. An example of the command is given below. Here a weblogic user, weblogic group and an App Role are assigned to the newly created Application Role.

connect(“weblogic”,”welcome1″,”localhost:7001″)
grantAppRole(“obi”,”ReportWLSTRole”,”oracle.security.jps.service.policystore.ApplicationRole”,”BIAuthor”)
grantAppRole(“obi”,”ReportWLSTRole”,”weblogic.security.principal.WLSUserImpl”,”weblogic”)
grantAppRole(“obi”,”ReportWLSTRole”,”weblogic.security.principal.WLSGroupImpl”,”BIAdministrators”)

NewImage

To do an incremental migration will be using a mix of all the commands above to automate the entire process. During my WLST automation blog post later this month, i will upload a script that will automatically do all the above processes in the backend (not interactive).

Comments

  1. daledo9 Says:

    Thank you for the very useful post. One question … When I performed the migration, the group member data from my custom Roles were not migrated. Is there a way to also migrate the member data?

    members>

    weblogic.security.principal.WLSGroupImpl
    GROUP_NAME

    Thank you.

  2. Venkatakrishnan J Says:

    Daledo – As mentioned above, the migratesecuritystore method does not seem to migrate the member associations. So, we will have to use the combination of listAppRoleMembers method and the grantAppRole for moving the member associations.

    -Venkat

  3. William Says:

    Venkat,

    I came across this website:
    http://itnewscast.com/applications/migrating-security-policies-development-standalone-wls-11g

    and used the mentioned jps-config.xml script in combination with your posting. This moved the roles and the members.

    Regards

  4. Hans van den Berg Says:

    Venkat,

    Thanks for your very useful Migrating steps. Where can I find the script you mention “that will automatically do all the above processes in the backend (not interactive).”
    Regards,
    Hans

  5. king Says:

    venkat,

    Is this method works if we want to migrate security from obiee 11.1.1.3 to 11.1.1.6 ?

    regards,
    King

  6. Maninder Says:

    Yes you can use the same method.

  7. Angelina Says:

    Hi,

    can you please confirm that this approach works if we transfer security from obiee 11.1.1.5 to 11.1.1.6?

    Thanks,
    Angelina

  8. Ravi Says:

    Thank you for the information :) This was really useful.

    “Even now its the same. The member assignments are not carried over during the migration. I am not sure whether it is a bug or an intended behaviour. But be aware of the fact that while doing the app role migration, the member assignments are not carried over. We will have to reapply the assignments post migration”

    I am suspecting the reason behind this is that enterprise is not in sync with Weblogic Embedded LDAP server Users and Groups… within myrealms .

  9. Tiago Dib Says:

    Hello, I’ve used this process to make a migration out of place OBIEE 11.3 to 11.6. But users’ permissions are not working properly by accessing the dashboards in analitycs get an access denied message on the objects, but the permissions on CatalogManager are there, I tried to refresh the guid but to no avail, anyone have any ideas to help me ?

  10. Anil Says:

    Oracle accepted “The member assignments are not carried over during the migration” as a bug(#14239413) and developers are working on it.

    Thanks,
    Anil

  11. jack Says:

    Hi i have a requirement to read roles/role members and update them in a oracle table..(where LDAP user details will be populated to create a relation table role-group-ldap user details..)
    my strategy was to achieve using WLST.. by calling listAppRoles(“obi”) and its Role members and create a JDBC source in weblogic and try inserting above captured details into it using cmo.settable…

    wls:/bifoundation_domain/serverConfig> listAppRoles(“obi”)
    Traceback (innermost last):
    File “”, line 1, in ?
    NameError: listAppRoles
    wls:/bifoundation_domain/serverConfig> listAppRoles(appStripe=”obi”)
    Traceback (innermost last):
    File “”, line 1, in ?
    NameError: listAppRoles

    can you suggest me if any alternative way to capture roles & its members into a db table automated way..

  12. Lisa Says:

    Have you written the WLST automation blog post yet? We are trying to do this exact thing and I was hoping this post was complete so we could use it as a reference.
    Thanks!
    Lisa

  13. Krishna Says:

    Thank you for this information! I used this along with Andrejus’ blog mentioned by William and was able to migrate both roles and membership without any scripting on 11.1.6.4
    I think the key difference between the two blogs is the value of type in migrateSecurityStore WLST: you use ‘appPolicies’ and Andre uses ‘policystore’ which migrates everything. More details are available in Oracle documentation.

  14. Swakshar Kundu Says:

    Hi Venkat,

    If the situation demands that security setup in a non prod instance needs to be refreshed from prod, can we simply replace the system-jazn-data.xml of the non prod or are there any parameter changes that we need to do?

    Regards,

    Swakshar.

  15. Diego Luis Says:

    First of all, thanks for such a good document.
    I tried a PoC similar to the one that is posted here on an OBIEE 11.1.1.6.4 environment and I can confirm that the member assignments are carried over during the migration process.
    I created a specific user in Dev and made it belong to the BIAuthor role, after the migration to Prod the BIAuthor role has the user as a member however (as this user has not yet been created in Prod) it does not have rights to log in.

  16. Darshit Says:

    Hi,
    I have sucessfully migrated the security from OBIEE 11.1.1.5 to OBIEE 11.1.1.6.8 with the help of your document,but one strange thing i observed that during policy migration itself the credentials were also migrated, so part 3 was not required in my case.
    Thanks,
    Darshit

  17. Shobhank Says:

    Thank you for the valuable information.
    I have successfully migrated roles and as in some of the above people’s experiences, role membership migrated too! without incremental approach.

Website Design & Build: tymedia.co.uk