JDev 11gR1 & WebLogic

Did you know JDev 11gR1 embeds WLS 11gR1 (10.3.1) . When you develop an application in JDev and run it, JDev deploys the application automatically in the embedded WLS and launches the application's start page.

A less obvious fact is that this embedded WLS also comes with WLS Admin Console that is accessible from http://localhost:7101/console with weblogic/weblogic1 as the administrative account.

Deleting Application Policies with WLST

OPSS can automatically delete application policies when the application is undeployed. This is controlled by flags I talked about in my previous posts.

Now there are occasions where you might want to delete application policies manually. Here is a WLST command sample.

1. Launch WLST command as /common/bin/wlst.sh
2. Connect to Admins server, connect('weblogic','welcome1',"localhost:7001")
   Sample Output
   Connecting to t3://localhost:7001 with userid weblogic ...
   Successfully connected to Admin Server 'AdminServer' that belongs to domain 'domain1'.
   
   Warning: An insecure protocol was used to connect to the
   server. To ensure on-the-wire security, the SSL port or
   Admin port should be used instead.
   
   
3. Delete the authZ policy for a an application, deleteAppPolicies(appStripe="TB#V1.0#9")
   Sample Output
   

wls:/domain1/serverConfig> deleteAppPolicies(appStripe="TB#V1.0#9")
{appStripe=TB#V1.0#9}
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

Note the application stripe is a fully qualified name and include the application + the version.

Application policy and App un-deployment

You can deploy an ADF application with EM to a WebLogicServer Domain. Lets say the ADF app is secured. When the app is deployed, the security policies are also deployed with the app to the the target server. This happens automatically within JDeveloper. But when the app is deployed to a remote WLS this is exposed as configuration choice that the application deployer (Administrator by another name) will have to make.

This is controlled with the flags I blogged in my last post.

What about undeploying application security policies, when the corresponding application is undeployed. Turns out this does not happen automatically in 11gR1, and requires the application to be packaged(EAR file) with an "Weblogic-Application-Version" entry in its manifest file.

JDev automatically creates a MANIFEST file for the application when the application is packaged(deploy to an EAR). Here is an example manifest file.


Manifest-Version: 1.0
Created-By: 1.6.0_07 (Sun Microsystems Inc.)
Weblogic-Application-Version: V1.0

When this app is un-deployed its application policies are automatically removed.

Deploying a Secure application wiht EM

As a reader of this blog, you probably know that Oracle Platform Security Services (OPSS) supports application life cycle from design, to deployment to monitoring etc. Now the security configuration management is exposed through Enterprise Manager - Fusion Middleware Control(names ,names, when will we use shorter names, but let me not get off track). It allows administrator to control how security related artifacts (policies, credentials etc) are deployed to the target server.

The feature is documented in the Oracle Fusion Middleware Security guide (section 7.2.1) but the doc is somewhat awkward. I recently has some email exchange with a customer about this, and I thought while we improve the doc, the clarification might be of interest to others.

"

The following three application security artifacts are of interest during application deployment process.

1. Identities - Which mean users and groups and application roles to groups/users mapping. These are defined by a Developer during application development process within JDev.
   
• In most scenarios, the identities should not be migrated when deploying an application to a remote WLS (it is controlled with the check box, )
• Mapping Application role to enterprise groups/users in a remote WLS environment is a post application deployment task to be done by an Administrator.
  
2. Policies - Which include Application roles and permissions granted to application roles.
• When deploying the app for the first time, the policies should always be migrated to the Policy store, which is the option controlled by "Append" radio button
• Upon re-deploying the app, to preserve any application policy modification made in the policy store, the admin should choose the "Ignore" radio button.
3. Credentials - Which are username/password tuples used by the applications
• The radio button "Append" means credentials packaged with the application will be deployed to the remote WLS's credential store. In case a credential with the same map and key names already exists in the domain credential store, the migration process will skip that credential, and continue with others.
• The radio button "Ignore" means credentials packaged with the application will not be deployed to the remote WLS's credential store. In this case, the administrator is then expected to create a credential valid for the environment, before the application works as designed by the developer."

Shout out to my colleague Sam for reviewing this post.