OPSS Scripts for Programmatic Policy Mgmt.

In the last post I gave example of WLST command necessary to grant code source permission to an application that will allow the application to use OPSS policy management API to modify the policy.

Here are more details.

I am using JDev build Build JDEVADF_11.1.1.2.0_GENERIC_091029.2229.5536.
The JDev is installed at the default location on my windows machine. Ran wlst command at C:\Oracle\Middleware\oracle_common\common\bin>wlst.cmd

In the WLST shell type
grantPermission(codeBaseURL="file:///C:/Documents and Settings/vishukla/Application Data/JDeveloper/system11.1.1.2.36.55.36/o.j2ee/drs/PolicySource/-", permClass="oracle.security.jps.service.policystore.PolicyStoreAccessPermission", permTarget="context=APPLICATION,name=PolicySource#V2.0", permActions="*")


1. The first bold entry is the exploded path where the application is during application development.
2. The second bold entry is the application stripe which by default is applicationame+"#"+"application version". By some quirk, each application version in JDev starts its counter at 2.
3. The third bold entry is the action, in this case I have a wild card to indicate all actions on the policy. However, in any non trivial environment you should use specific actions like "alterAppRole" as specified in the API javadoc.

Here are the command line output

wls:/DefaultDomain/serverConfig> grantPermission(codeBaseURL="file:///C:/Documen
ts and Settings/vishukla/Application Data/JDeveloper/system11.1.1.2.36.55.36/o.j
2ee/drs/PolicySource/-", permClass="oracle.security.jps.service.policystore.Poli
cyStoreAccessPermission", permTarget="context=APPLICATION,name=PolicySource#V2.0
", permActions="*")
{appStripe=null, permActions=*, principalName=null, permClass=oracle.security.jp
s.service.policystore.PolicyStoreAccessPermission, principalClass=null, permTarg
et=context=APPLICATION,name=PolicySource#V2.0, codeBaseURL=file:///C:/Documents
and Settings/vishukla/Application Data/JDeveloper/system11.1.1.2.36.55.36/o.j2ee
/drs/PolicySource/-}

Programmatic Authorization Policy Mangament with OPSS

In the simplistic cases, often the authorization policy management is done using the provided tooling. OPSS provided tooling in the form of EM(GUI) and WLST (script) to manage policy.

For more advanced needs, OPSS also provides API for programmatic policy management.The Policy API is protected by codesource permission. Hence applications using the API will need to have the required permission. See the example 18.3.4.2 in FMW Security guide on the code necessary to use the API. What the example assumes is that proper policy access permission is granted before hand. I.e the application code running the example has PolicyStoreAccessPermission( "context=APPLICATION,name=applicationStripe" , "grant")

Here is the example of OPSS WLST command that needs to be run to grant the requirement Permission. Replace all bold entries with values appropriate for your environment. The first entry is the path to the application jar that is making the programmatic API call, the second bold entry is the application stripe.

grantPermission -codeBaseURL "file:/scratch/foo/abc.jar" -permClass oracle.security.jps.service.policystore.PolicyStoreAccessPermission -permTarget "context=APPLICATION,name=myAppName" -permActions "grant"

See this link for details on running FMW WLST commands.

There are two basic ways an application can use the example 18.3.4.2. One is to modify the application policy for itself, the other is to modify the application policy for another application.
The later might be the case when you have authorization management of the application structured as another application. In the second case, the code source for the second application needs to be granted the PolicyStoreAccess permission.

Fixed - eZShare app and Infinite loop in the browser

With the latest version of the App, this issue is fixed.





If you run into an infinite loop running eZShare sample app with JDev 11.1.1.2.0, a workaround is to remove the AdfFacesFilter from your app's web.xml.

ie. remove the following

AdfFacesFilter & the Filter mapping for it.

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.