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). Lets again take the example of 2 environments Dev and Prod. In Production we have
the following Application Roles.
1.
2.
3.
4.
5.
6.

BISystem
BIAdministrator
BIAuthor
BIConsumer
ReportAuthor
ReportDeveloper

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

1.
2.
3.
4.
5.
6.

BISystem
BIAdministrator
BIAuthor
BIConsumer
ReportAuthor
ReportConsumer

Basically there are 3 main differences between the above shown 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 systemjazn-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

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-configpolicy.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. Lets find out why. Maybe its 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.

Lets 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 behavior. 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 cant 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,BIAuth
or)
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).