ICS to OIC Migration

Introduction Oracle Integration Cloud (OIC) and Integration Cloud Service (ICS) are iPaaS offerings from Oracle. ICS was released back in 2015 has now been superseded by OIC. Customers on ICS can choose to be on ICS or migrate to OIC to take advantage of new features and services built into OIC. The comparison of ICS […]

Getting Groovy with Oracle Data Integrator: Automating Changes after Upgrading ODI or Migrating from Oracle Warehouse Builder

Introduction Oracle now provides a migration utility to convert your existing Oracle Warehouse Builder (OWB) mappings to Oracle Data Integrator (ODI) mappings. As customers started to go through this migration effort, we realized that some post migration scripts could help update the migrated repository. Once we had the scripts, we realized they could also be […]

JCAPS MIGRATION TOOL RELEASED!

Introduction I’m happy to announce that Oracle has just released the Java CAPS Migration Tool under Controlled Availability to Oracle customers and certified partners. Oracle customers, partners and consultants can now migrate JCAPS artefacts and intellectual property to Fusion Middleware, often saving several “person decades” of redesign and recoding. What’s more, the tooling and methodology cover the […]

OAM 11g: The Policy Migration Strategy

Introduction The purpose of this post is to provide some tips when planning a policy migration from Oracle Access Manager (OAM) 10g to OAM 11g.  Before you begin, I recommend that you install the latest Bundle Patch (BP).  At the time of this writing, the latest BP for OAM 11gR2PS1 is patch 16872730.  Installing this […]

Several ADF apps to one single OPSS policy stripe

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.

Users and Groups migration: a handy JDeveloper feature

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:

applicationMenu

UsersAndGroupsMigration 

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:

DeployingViaJDev

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','<weblogic-password>','t3://<server>:<port>')
> cd('<folder-where-your-ldif-file-is-kept>')>
> cmo.importData('DefaultAtn', '<your-ldif-file>', 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.

DefaultAuthenticatoSetupWLS

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@