In OPSS Artifacts Life Cycle in ADF Applications, I’ve explained how to change the default behavior for migration of authorization policies when deploying applications. Revisiting it, I’ve said that one can specify the MERGE value for jps.policystore.migration param-name in weblogic-application.xml and that is particularly useful in some deployments where more than one application have to share the same policy context (or policy stripe).
A real use case is when a customer wants to hide the concept of how a system is partitioned across ADF applications for security administrators. Most of the times, a security administrator is interested in the policies of the system as whole. This article explains how it can be done.
Before going further, some definitions:
- Policy Store: repository of policies comprising one or more application policy stripes and code-based grants. There’s only one policy store per WLS domain.
- Policy Stripe: set of application policies to which one or more applications bind to. One application binds to only one policy stripe.
Clarifying a little bit more, take the following system-jazn-data.xml snippet, the OOTB policy store in WLS domains. In such case, system-jazn-data.xml itself represents the policy store, while OrderEntry#V2.0 and OrderCapture#V2.0 are the policy stripes, defining an application-level scope for authorization policies. In default mode, OrderEntry application does not have access to application policies in OrderCapture#V2.0 policy stripe, and vice-versa.
<?xml version='1.0' encoding='utf-8'?>
<jazn-data>
<policy-store>
<applications>
<application>
<name>OrderEntry#V2.0</name>
<app-roles>
...
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
<application>
<name>OrderCapture#V2.0</name>
<app-roles>
...
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
</applications>
</policy-store>
</jazn-data>
When we develop an ADF application in JDeveloper and enables ADF security, the authorization policies you create go into a workspace-level jazn-data.xml under a stripe name that has the same name as the application itself, as show below. Let’s say our application is called OrderEntry. In jazn-data, we would have:
<?xml version='1.0' encoding='utf-8'?>
<jazn-data>
<policy-store>
<applications>
<application>
<name>OrderEntry</name>
<app-roles>
...
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
</applications>
</policy-store>
</jazn-data>
Then if you do nothing and just deploy the application, the policies get migrated to the runtime policy store under an application policy stripe named OrderEntry#V2.0. For our mental sanity, the V2.0 comes from the Weblogic-Application-Version property in the MANIFEST.MF, but this is not the topic of this article.
Now what happens if we want to have OrderEntry and OrderCapture binding to the same policy stripe, say OrderMgmt? We need to add some properties to some deployment descriptors:
1) in weblogic-application.xml:
<application-param>
<param-name>jps.policystore.applicationid</param-name>
<param-value>OrderMgmt</param-value>
</application-param>
Such information is used only at deployment time. It basically tell the OPSS listeners to migrate application policies in jazn-data.xml to OrderMgmt policy stripe in the runtime policy store. In this scenario, the version number is not appended to the stripe name.
2) in web application’s web.xml:
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>enable.anonymous</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>remove.anonymous.role</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>application.name</param-name>
<param-value>OrderMgmt</param-value>
</init-param>
</filter>
Here I have added the init-param application.name to the JpsFilter definition. The param-value must match the value defined in weblogic-application.xml. This information is used only at runtime. It tells the JpsFilter where to bind to when looking for authorization policies. As the JpsFilter intercepts all requests for the Faces Servlet (javax.faces.webapp.FacesServlet), it establishes the policy store context for every request to an ADF artifact.
By repeating this very same configuration across your applications, you can bind any number of applications to the same policy stripe, i.e., the same authorization context and expose a single and consolidated view of your authorization policies to security administrators.
