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

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.

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

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

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

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.

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.

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

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" 
schema-major-version="11" schema-minor-version="1">    
<!-- This property is for jaas mode. Possible values are "off", "doas" and "doasprivileged" -->    
<property name="oracle.security.jps.jaas.mode" value="off"/>
 <propertySets>        
<!-- SAML Trusted Issuer -->        
<propertySet name="saml.trusted.issuers.1">            
<property name="name" value="www.oracle.com"/>        
</propertySet>    </propertySets>
 <serviceProviders>        
<serviceProvider type="POLICY_STORE" name="policystore.xml.provider" class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider">            <description>XML-based PolicyStore Provider</description>        </serviceProvider>    </serviceProviders>
 <serviceInstances>
 <!-- JPS XML Policy Store Service Instance -->        
<serviceInstance name="srcpolicystore.xml" provider="policystore.xml.provider" location="C:/Migration/Source/system-jazn-data.xml">            
<description>File Based Policy Store Service Instance</description>        
</serviceInstance>
 <serviceInstance name="policystore.xml" provider="policystore.xml.provider" location="C:/Migration/Target/system-jazn-data.xml">            
<description>File Based Policy Store Service Instance</description>        
</serviceInstance>
 </serviceInstances>
 <jpsContexts default="default">        
<!-- This is the default JPS context. All the mendatory services and Login Modules must be configured in this default context -->        
<jpsContext name="sourceFileStore">            
<serviceInstanceRef ref="srcpolicystore.xml"/>        
</jpsContext> <jpsContext name="targetFileStore">            
<serviceInstanceRef ref="policystore.xml"/>      
</jpsContext>    
</jpsContexts>
</jpsConfig>

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.

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")

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.

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).

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.

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

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")

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")

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")

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")

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).