How to Create a Flattree Plugin in OVD 10g (Doc ID 457865.1)

Last updated on SEPTEMBER 15, 2016

Applies to:

Oracle Virtual Directory - Version 3.0.3 to 10.1.4.2 [Release 3.0.3 to 10gR3]
Information in this document applies to any platform.
EVENT~PLUGINS; JAVAPLUGIN; NAMESPACE; ORACLE~VIRTUAL~DIRECTORY; SHOWABOUTPLUGINDIALOG;


Goal

As per the OVD documentation,

FlatTree plug-in performs dynamic mapping of the virtual directory tree.
FlatTree, as its name implies, flattens a directory source so that all entries appear directly under the adapter's root.
This plug-in operates in two deployed modes. It can be deployed as part of any existing adapter to flatten
the existing namespace. Or, it can be deployed as part of a Custom Adapter deployment. By using the
"adapter" parameter, the adapter will fetch data from the designated adapter representing it as part of
the custom adapter's namespace. Note that when configured this way, the adapter root object is NOT
defined. This is useful if you want to overlay multiple adapters on top of a parent adapter without
creating duplicate parent nodes.

Configuration Parameters :

Criteria defines an LDAP filter which restricts the entries that can be searched for through this plugin.
For example, if criteria was set to (objectclass=user), then only "user" objects would be returned through this plug-in.
If not defined, then the plug-in will assume data will be retrieved through its parent adapter.
When defined, adapter must be the name of another adapter in the Oracle Virtual Directory
configuration. When defined, the plug-in will pull data from the other adapter and map the
entries to its parent adapter's root. When running in this mode, the root object is not returned;
only the child entries are returned.

Example Scenario:

Assume that we have an LDAP adapter, named AD1_TEN which have :

root: ou=ad1,cn=Users,dc=oracle,dc=com
remote base: ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com

Search output when executed directly against the backend LDAP Server:
 

C:\>ldapsearch -h ten -p 389 -D "administrator@test3.ro.oracle.com" -w ***** -s sub -b "ou=enterp,dc=test3,dc=ro,dc=o racle,dc=com" objectclass=* dn

ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com
ou=uk,ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com
ou=acc,ou=uk,ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com
cn=tom,ou=acc,ou=uk,ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com
ou=fin,ou=uk,ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com
cn=mike,ou=fin,ou=uk,ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com
--- other lines not displayed----


Search output when executed against OVD

C:\>ldapsearch -h spreda-ro -p 4391 -D "cn=admin" -w **** -s sub -b "ou=ad1,cn=users,dc=oracle,dc=com" objectclass =* dn

ou=ad1,cn=users,dc=oracle,dc=com
ou=uk,ou=ad1,cn=users,dc=oracle,dc=com
ou=acc,ou=uk,ou=ad1,cn=users,dc=oracle,dc=com
cn=tom,ou=acc,ou=uk,ou=ad1,cn=users,dc=oracle,dc=com
ou=fin,ou=uk,ou=ad1,cn=users,dc=oracle,dc=com
cn=mike,ou=fin,ou=uk,ou=ad1,cn=users,dc=oracle,dc=com
---- other lines not displayed----


Goal 1:

Users from AD have DN's like:

cn=tom,ou=acc,ou=uk,ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com
cn=mike,ou=fin,ou=uk,ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com

In OVD, the corresponding DN's are :

cn=tom,ou=acc,ou=uk,ou=ad1,cn=users,dc=oracle,dc=com
cn=mike,ou=fin,ou=uk,ou=ad1,cn=users,dc=oracle,dc=com

The goal is to have the DN's as shown below for users in OVD

cn=tom,ou=ad1,cn=users,dc=oracle,dc=com
cn=mike,ou=ad1,cn=users,dc=oracle,dc=com

This can be solved using a flattree plugin, plugin deployed as part of existing adapter to flatten the existing namespace.

Goal 2:

Users from AD have DN's like:

cn=tom,ou=acc,ou=uk,ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com
cn=mike,ou=fin,ou=uk,ou=enterp,dc=test3,dc=ro,dc=oracle,dc=com

In OVD, the corresponding DN's are :

cn=tom,ou=acc,ou=uk,ou=ad1,cn=users,dc=oracle,dc=com
cn=mike,ou=fin,ou=uk,ou=ad1,cn=users,dc=oracle,dc=com

This is realised through a LDAP adapter.

The goal is to have the following DN's for users under other adapters in OVD
 
cn=tom,dc=test,dc=oracle,dc=com
cn=mike,dc=test,dc=oracle,dc=com

In order to achieve this, we use a Local Store Adapter (LSA) which will have root like "dc=test,dc=oracle,dc=com"

Solution

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms