Migrating Security Policies from Development to Standalone WLS 11g

By Andrejus Baranovskis

Problems with security policies migration during deployment were solved using policies migration scripts from Steve Muench article - Simplified ADF 11g Application Credential and Policy Migration to Standalone WebLogic Servers. Its worth to mention, with latest JDeveloper 11g PS2 and WebLogic release, security policies are migrated during deployment process automatically - WLS system-jazn-data.xml is updated without running additional scripts. However, it happens we need to update system-jazn-data.xml with new policies, without whole application redeployment. For this purpose, similarly as in Steve article, we can use WLST command - migrateSecurityStore.

If you will run Steve scripts on latest Oracle Fusion release - you will see that some parts need to be updated (build.xml should contain updated references to JPS libraries, jps-config.xml should be updated with new system-jazn-data.xml location in fmwconfig folder). Main goal of my today post is to describe how you can apply migrateSecurityStorecommand and migrate security policies from development environment (or any other) into test/production WLS environment.

I'm using sample jazn-data.xml from this application - JaznMigration.zip. There is one simple security policy defined for index page:

Application role is mapped to specific Enterprise role:

In order to use migrateSecurityStore command, you will need to define jps-config.xml file, where you will point to source jazn-data.xml and to destination system-jazn-data.xml:

More about this file structure, please read in Oracle FMW Security Guide - Section 7.5.2.1. In my case, I have created jps-config.xml file inside WLS domain folder structure, I have copied source jazn-data.xml manually.

In order to execute WLST command, we will need to run WLST.cmd script. Make sure, you are using WLST.cmd script from oracle_common folder, otherwise it will not recognize ADF related WLST commands:

When WLST is running, you can execute migrateSecurityStore command. This WLST command can be run offline, this means no need to have running WLS server. Make sure you specify jps-config.xml file, source and destination contexts correctly, as it is defined in jps-config.xml:

And here we go, security policies are magically migrated to WLS system-jazn-data.xml and ready to be used:

Next step, make sure WLS server is connected to Active Directory service, where WLS can find users with correct Enterprise roles. Or for test purpose, define these users and roles in WLS embedded security realm.

Ah, almost forgot - make sure you have restarted WebLogic, before trying to test if it works.

Users and Groups migration: a handy JDeveloper feature

By Andre Correa

When you run an ADF web application directly from JDeveloper, it starts its embedded WLS and deploys the application. In such context, JDeveloper has a very convenient feature when dealing with users and groups defined in the application's jazn-data.xml file. They get deployed along with the application into WLS embedded LDAP server, provided the Users and Groups check box is selected in the Application Properties Deployment window, as shown right below:

Then by simply asking JDeveloper to run your application you get everything you need.

As said, that's a JDeveloper convenience that only works when deploying the application through JDeveloper. Do notice this apply whether you click & run a page or taskflow or explicitly ask JDeveloper to deploy your application into WLS, as shown:

But if you’re not using JDeveloper, you’re on your own. You should not expect it to happen when generating an ear file and deploying via any other means, although jazn-data.xml is packed within the ear file. `I've gotten this question from a few of customers. And some believe that's a bug. It's not.

You need to manually populate WLS embedded LDAP. There are two ways to accomplish it:

1) Using wlst.sh:

> connect ('weblogic','','t3://:') > cd('')>  > cmo.importData('DefaultAtn', '', None)  

2) Using WLS Console:

Notice the path at the top to understand how to get to this screen.

Enter the ldif file absolute path name in “Import File” on Server field. Notice the file has to be accessible on the server file system.



Here's a small sample of the ldif file you can use and extend:

dn: dc=@domain@

dc: @domain@

objectclass: top

objectclass: domain

dn: ou=@realm@,dc=@domain@

ou: @realm@

objectclass: top

objectclass: organizationalUnit

dn: ou=groups,ou=@realm@,dc=@domain@

ou: groups

objectclass: organizationalUnit

objectclass: top

dn: cn=group1, ou=groups, ou=@realm@, dc=@domain@

memberURL: ldap:///ou=people,ou=@realm@,dc=@domain@??sub?(&(objectClass=person)(wlsMemberOf=cn=group1,ou=groups,ou=@realm@,dc=@domain@))

objectclass: top

objectclass: groupOfUniqueNames

objectclass: groupOfURLs

cn: group1

uniquemember: cn=user1,ou=people,ou=@realm@,dc=@domain@ 

dn: ou=people,ou=@realm@,dc=@domain@

ou: people

objectclass: organizationalUnit

objectclass: top

dn: uid=user1,ou=people,ou=@realm@,dc=@domain@

objectclass: top

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

objectclass: wlsUser

cn: user1

sn: user1

uid: user1

userpassword: welcome1

wlsMemberOf: cn=group1,ou=groups,ou=@realm@,dc=@domain@

Detailed Logging for ADF Security

is possible to get more information about what security checks are happening and failing when you run an application with ADF Security enabled. The answer is yes. Just go to the Run / Debug / Profile entry in the project properties and edit the run profile (or create a new one) and add the following parameter to the Java Options field:
-Djps.auth.debug.verbose=true

Then when you run you'll get a huge amount of output showing each check and the status - rather like this:

[JpsAuth] Check Permission    PolicyContext:        [unsecuredtuhra2#V2.0]    Resource/Target:      [sessiondef.fragments_searchUIPageDef_BasicEmployeeSearchCriteriaQuery_VCTree_Root_internal_vcival_def_34_DynamicRegion]    Action:               [view]    Permission Class:     [oracle.adf.share.security.authorization.RegionPermission]    Result:               [FAILED]    Evaluator:            [ACC]    Failed ProtectionDomain:ClassLoader=sun.misc.Launcher$AppClassLoader@1ea2dfe   CodeSource=file:/C:/builds/R1_Production/jdeveloper/modules/oracle.adf.share_11.1.1/adf-share-support.jar   Principals=total 2 of principals(     1. JpsPrincipal: oracle.security.jps.internal.core.principals.JpsAnonymousUserImpl "anonymous" GUID=null DN=null     2. JpsPrincipal: oracle.security.jps.internal.core.principals

Managing ADF Security Using Oracle Enterprise Manager 11g

from Andrejus Baranovskis's Blog by Andrejus Baranovskis

Recently I had a long meeting on customer side, to discuss and describe various ADF Security management strategies in production environment. Good news - at the end, everyone left this meeting happy and with correct understanding of benefits given by ADF Security. I will describe how you can manage Application and Enterprisesecurity roles, as well as Permissions, after ADF application deployment on production WebLogic server.

Download sample application - ApplicationRoles.zip. This application contains one Application level role -accountants, for testing purposes it is mapped to Enterprise level role - Accountants:

There is test user defined - dev1, granted with Enterprise role:

Application contains one JSPX page and one ADF Task Flow with fragment. JSPX page is granted to be viewable for any authenticated user:

ADF Task Flow only to accountants Application role:

Sample application is configured not to migrate any users or groups defined inside local jazn-data.xml. This means we will consume users and groups defined in WebLogic server, without uploading those ones from development environment:

After deploying application, I can see there are no users uploaded from development environment, thats what I want:

Now, when deployment is done, we can open application control screen in Oracle Enterprise Manager 11g. There is Security group in the menu - it gives access to application policies and roles. This means we can manage ADF Security directly, even after application was deployed on the server, without redeployment:

I can see two Application Policies defined based on authenticated-role and accountants roles:

We can access Application Role - accountants:

And see details for this role:

Interesting thing, I can still see that Application Role accountants is mapped to Accountants group (Enterprise Role). It should not be visible, because with deployment profile I have declared not to upload any users or groups from development environment. I will try to delete this mapping:

However, delete operation fails with error - such role is not found:

This means it is good practice to remove any mapping between Application and Enterprise Roles in development environment, before doing actual deployment:

After removing role mapping in jazn-data.xml and redeploying, I can see correct picture - no Groups assigned to Application Role:

Now I will switch to WebLogic console, and I will define new Group (Enterprise Role) - FinanceG. This role may come from Active Directory, etc:

I have defined new user on WebLogic server as well - john:

This user is granted with group - FinanceG:

Now its time to open Oracle Enterprise Manager 11g and map FinanceG group with Application Role -accountants:

Through Oracle Enterprise Manager 11g we can browse and assign groups from WebLogic server. All users fromFinanceG group, will be able to access resources protected by accountants Application Role:

Login as user john, granted FinanceG group:

Both - page and ADF Task Flow are rendered:

If I would login as user scott, who is not granted with FinanceG group:

Region from ADF Task Flow will not be rendered, thats correct because user scott is not authorized to access this region without accountants Application Role:

Let's say organization security policy is changing and it is not allowed anymore to show Countries page without proper role assignment. You may think, application change and redeployment will be required. However, there is easy way - we can change Application Policies directly in Oracle Enterprise Manager 11g. Open Application Policies screen and select main page permission granted to authenticated role:

Grant this permission to accountants Application Role:

Remove authenticated role from the list:

Application becomes secured completely only by accountants Application Role:

All users from different groups, not mapped with accountants Application Role, will be unauthorized to access application (user scott in this case):