When implementing BPM processes, application roles can be defined, which will be created in the policy store. To enable users to work with the processes, groups are assigned to these application roles. Users are ofcourse assigned to their respective groups. Management of the BPM process application roles is available in Enterprise Manager Fusion Middleware Control or the BPM workspace.
Let’s first use Fusion Middleware Control. We need to go to the security section.
Choose application stripe: OracleBPMProcessRolesApp. This stripe contains all BPM process roles.
Edit the application role to add or remove principles (users,groups or other application roles).
Be sure you save your changes or they are lost.
We can do the security mapping within the BPM workspace aswell. You need to have the correct permissions.
Go to the ‘administration’ in the BPM workspace.
Select the Application role you want to manage. Beware: do not mistake the ‘escalation path’ items for grants.
In the BPM workspace application you can grant the application role to users, groups and or other application roles.
Again, make sure you save your work.
But there is another way to apply these configuration changes. With WLST (WebLogic Scriting Tool) you can do almost anything you do in EM or the console through scripts.
Managing application roles through WLST is simple. There is a whole list of commands available to manage security (check the online command reference).
start wlst (from oracle_common, so the correct libraries are loaded). If you need help with wlst commands, just type for example help(‘listAppStripes’).
$MW_HOME/oracle_common/common/bin/wlst.sh connect('whlogic','rocks','t3://soasuite.whitehorses.nl:7001') help('listAppRoles')
Which application stripes (also called Application Context) do we have:
listAppStripes() Already in Domain Runtime Tree OracleBPMComposerRolesApp OracleBPMProcessRolesApp b2bui oracle-bam#11.1.1 soa-infra
Next we want to see what application roles are present in this application stripe.
listAppRoles('OracleBPMProcessRolesApp') Already in Domain Runtime Tree [ [Principal Clz Name : oracle.security.jps.service.policystore.ApplicationRole, Principal Name : BPMProcessAdmin, Type : APP_ROLE], Display Name : BPM Admin Role, Description : BPM application admin role, has full privilege for performing any operations including security related, Guid : AB659440D35811E2BFA12381EAEAC78D] [ [Principal Clz Name : oracle.security.jps.service.policystore.ApplicationRole, Principal Name : e.Administratie, Type : APP_ROLE], Display Name : Intake.Administratie, Description : null, Guid : D47186A0F45A11E28F7E0FB393B77198]
Let’s see which grants have been done.
listAppRoleMembers(appStripe='OracleBPMProcessRolesApp',appRoleName='e.Administratie') Already in Domain Runtime Tree [Principal Clz Name : weblogic.security.principal.WLSGroupImpl, Principal Name : Operators, Type : ENT_ROLE] [Principal Clz Name : weblogic.security.principal.WLSGroupImpl, Principal Name : Administratief, Type : ENT_ROLE]
Now let’s grant the e.Administration application role to the Whitehorses group.
Revoking is just as simple. It’s only a different fucntion.
When clustering is involved, you need to be aware of some things. When you are using the default policy store provider, all is stored in an XML file ($WL_DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml) on the filesystem local of the AdminServer or the Weblogic server serving your session of BPM Workspace.
If you’re working with such a configuration, you should change this to an Enterprise class configuration with for example the Oracle internet Directory (OiD) or a database based provider.