Web Center Integration with OES via OVD

Introduction

Web Center is Oracle’s strategic direction for Portal customers. WebLogic Portal will still be supported for the time being but it is expected to gradually be replaced by Web Center. Currently, WebLogic Portal and Oracle Entitlements Server can be integrated by configuring the WLS Security Module from OES. It is even possible to accomplish the integration having OES be completely dedicated to providing role information without intervening in the authorization process of WLP. However, the same is not true for Web Center and OES. This article describes a prototype implementation of such an integration using OVD as an intermediary between Web Center and OES. Web Center can be configured to delegate its authentication to an LDAP based Authentication Provider, which in this case can be OVD. OVD has advanced customization capabilities that allow exposing a wide variety of data sources as if they were LDAP directory services. This capability of OVD is the corner stone of the WC-OES integration demonstrated in this implementation.

Overview

For starters, I would like to spend a little time describing the architecture and the various components playing a part in the solution. Oracle Virtual Directory (OVD) is an Oracle Product part of the Oracle Identity Management suite of products. OVD provides an elegant solution to the problem of integrating multiple heterogeneous data sources presenting them as a consolidated view which can be consumed by an LDAP client. This capability allows us to expose OES data in a way that can be consumed through Out of the Box mechanisms available in Web Center. This is the main principle that we keep in mind for this implementation. The way in which we accomplished this integration is by configuring a Custom Adapter which is a concept in OVD’s world that represents a non-LDAP source of data to be exposed as an LDAP like tree hierarchy. The functionality of the Custom Adapter is implemented within a plug-in configured to be attached to the Custom Adapter. The following diagram shows the high-level architecture of the solution:

Fig. 1 – Integration Architecture for WC – OVD – OES products

As described in the previous picture, Web Center connects to OVD to authenticate users and extract Group membership information. OVD connects to OES using the OES Entitlements Plug-in to extract all available roles filtered by a configurable Application Context Name so only relevant roles are included in the results; or to test if a given user is a member of a particular role. OES applies the role policies to an identity previously asserted.

As you can also see, WebCenter’s Policy Store is kept in OID. It could have been kept in OVD if a Local Store Adapter was configured to allow OVD to store data itself. OID also stores the actual users that can login to WebCenter Spaces console.

Now, let’s take some time to discuss the responsibilities of each component within the context of the solution so you can understand better the design of this implementation and be able to effectively extend it, if such requirement would come your way. As we already mentioned the following components are involved:

• OVD Custom Adapter: This is a configuration element you define in OVD’s Administration interface (Oracle Directory Services Manager) ODSM. This interface can be accessed directly through its own URL or by logging in to Enterprise Manager. By simply adding an adapter of Type: Custom Adapter we have a place holder for the Groups that will be returned by OVD when WebCenter queries for them.
• OVD Custom Plug-in for OES: This is a Java implementation of OVD’s public interfaces and API’s. The implementation leverages OES BLM and Java APIs to extract the information from OES in response to WebCenter’s queries. The plug-in itself has the following components:
• Plug-in Wrapper: This component is responsible for initializing the plug-in and its methods are invoked by OVD a various stages of OVD server initialization and operation. This component is responsible for loading the Spring Application Context containing the configuration for all the components of the solution.
• Plug-in Implementation: This component is configured in the Spring Application Context configuration XML file. This component is the one holding the actual implementation of the methods defined by OVD’s published interfaces. The Plug-in Wrapper described above delegates the calls to this component.

• DataRetriever: This is an interface defined by my implementation; it is not part of OVD or OES API’s. The purpose of this interface is to encapsulate the contract between OVD and the Data Source the DataRetriever interacts with. This way, we can decouple OVD’s required data format from the intrinsic workings of the data source providing that data.
• FilterExecutor: This is another interface I defined as part of my implementation. This interface defines the contract for the components that will directly interact with OES in response to LDAP queries coming from the clients, in this case WebCenter. OES doesn’t understand LDAP patterns and URLs, so these components also act as mediators, parsing the LDAP queries to extract the pieces of information needed to invoke OES APIs. Each FilterExecutor registered in the configuration responds to specific LDAP queries. All filter executors are configured in a chain of filters all of them having the chance to process the incoming LDAP query. If the filter executor doesn’t understand the query coming in then simply won’t generate any results, so the query goes to the next filter executor down the chain. A single FilterExecutor can potentially process various types of queries; it is up to the FilterExecutor developer to write the filter executor to process only one or several LDAP queries.

Implementation Details

Now it’s time to talk about the implementation aspects of this integration. The Spring framework was selected to simplify the configuration of the components involved in the implementation and to allow easy customization of features of this implementation.

OESDataRetriever

This component encapsulates the functionality associated with OES.

The properties specified in the definition of this bean are passed at construction time. In this particular case OVD provides the means to specify System Properties as Java Options via the opmn.xml file, which contains the class-path and the Java Options required by OES. In the process, we came across a limitation on the size of the class-path value specified in opmn.xml. To overcome this limitation we decided to create a JAR file that will contain a MANIFEST with a class-path parameter with the list of required JAR files for OES libraries.
The following listing shows its configuration:

In other integrations, a custom class loader has been introduced to isolate the libraries and classes used by OES and its clients to avoid conflicts with any libraries which the product OES is being integrated with may have dependencies upon. However, OVD seems to have a dependency on the System Class Loader to load all the required classes for modules running within OVD processes. Therefore, the introduction of a custom class loader was not feasible. So the MANIFEST file depicted above was a nice alternative to the custom class loader and also, as already explained, allowed us to overcome the opmn.xml value size limitation.

WCOESIntegrationPlugIn

This component is the OVD plug-in implementation invoked by the OVD Plug-in wrapper called by OVD itself.

This bean has a very simple configuration. It is passed a list of Beans that implement the FilterExecutor interface. Each one of these process a particular LDAP query issued against OVD.

All filter executors have a reference to OESDataRetriever bean passed in their “retriever” property. The executors parse the LDAP query and determine which methods from the OESDataRetriever should be called.

OESDataRetriever makes calls to Wrapper classes for the OES Java and BLM API’s. These wrapper classes were created from the Java SSM Samples included with OES distribution. Similar objects have been used in other integrations described in other postings of this blog.

The following data flow diagram describes the implementation of this integration:

Fig. 2 – Implementation WC-OVD-OES Integration

Filter Executors

Now, let’s take a look at the filter executors and what they do in this implementation.

The allGroupsFilterExecutor responds to the following LDAP queries: (objectClass=*) and (|(objectclass = groupofuniquenames)(objectclass=groupofurls)). Then it communicates with OES using the BLM API Wrapper to extract all the roles existing in OES filtered by Application Prefix. Also the role AuthenticatedUser is removed from the list of returned roles since it is not a real role policy. The list of Roles is then converted to LDAP Groups and returned to the requesting client.

The isUserMemberOfGroupFilterExecutor responds to the following queries: (&(uniquemember=)(cn=)). This is to test if a user is a member of a group. The query to be processed here comes from the configuration of the OVD Authentication Provider and can be modified from the WebLogic Admin Console of the WebCenter Domain. This is defined in the static membership filter parameter of the configuration.

The webcenterGroupsSearchFilterExecutor responds to the following queries: (&(cn=)(objectclass=groupofuniquenames)). This filter is also defined in the configuration of WebLogic Security Realm in the OVD Authentication provider.

Summary

In summary the integration is based on a plug-in written for OVD which transforms the Role Policies configured in OES into Groups apparently static in nature but in reality are totally dynamic.

The implementation makes use of Spring to configure its various components.

The main components of this implementation are categorized as follows:

• Data Retriever: Responsible to interact with the external system that will supply the data that OVD will expose as LDAP groups.
• OES API Wrapper: This component is a session façade to OES through the JAVA API exposed by OES.
• OES BLM API Wrapper: This component is a session façade to OES’s BLM API.
• Filter Executor: Components in this role parse the incoming LDAP queries and potentially process the query to get the results and return them to OVD which in turn will return them to the calling client.

To self-contain the class loading and make sure the right libraries (jar files) were loaded the class-path argument of a MANIFEST file was utilized to isolate OVD’s class loading from the Plug-in’s class loader.