Intruduction

Some of Oracle BPM 11g customers have reported performance issues when trying to login to BPM Workspace with an external LDAP as an identity store. While each customer could have a different issue that caused the slow down, the process of identifying the issue usually is the same. Having a good understanding of how the Workspace, libOVD, external LDAP and WLS embedded LDAP work together will help quickly identify the problematic area.

This is the first of a series posts which are intended to shed some light on the interactions between BPM Workspace, libOVD and LDAPs. Information in this post is obtained by analyzing a series of libOVD trace logs.

System components

– SOA BPM 11g PS5 with BP7
          This is what the last customer I worked with is using. A comparison to PS6 and 12c in Workspace login behavior will be published in separate posts.
– Oracle DB XE 11g
– ODSEE (Oracle Directory Server Enterprise Edition) 11.1.1.7.0

Patches

Must have the following patches in addition to BP7

17315336

Configuration

– In bpmdomain/config/fmwconfig/jsp-config.xml

   <serviceInstance name=”idstore.ldap” provider=”idstore.ldap.provider”>
      …
      <property name=”virtualize” value=”true”/>
      <property name=”use.group.membership.search.config” value=”INDIRECT_ONLY”/>
      <property name=”OPTIMIZE_SEARCH” value=”true”/>
      …
   </serviceInstance>

– Configure an IPlanet Authenticator named “ODSEE” in WLS and restart the server
– After restart, a new LDAP adapter is automatically (when virtualize=true) configured based on the information in WLS IPlanet Authenticator in bpmdomain/config/fmwconfig/ovd/default/adapters.os_xml

– In bpmdomain/config/fmwconfig/ovd/default/adapters.os_xml, add a DynamicGroup plugin to the new LDAP adapter and make other changes according to the following.

   <ldap id=”ODSEE” version=”0″>
      <root>dc=migration,dc=test</root>
      …
      <pluginChains xmlns=”http://xmlns.oracle.com/iam/management/ovd/config/plugins”>
      <plugins>
         <plugin>
            <name>UserManagement</name>
            …
         </plugin>
         <plugin>
            <name>DynamicGroup</name>
            <class>oracle.ods.virtualization.engine.chain.plugins.DynamicGroups.DynamicGroups</class>
            <initParams>
               <param name=”fetchBothStaticAndDynamicGps” value=”true”/>
               <param name=”transformdn” value=”true”/>
               <param name=”usersearchbase” value=”dc=migration,dc=test”/>
            </initParams>
         </plugin>
         <plugin>
            <name>VirtualAttribute</name>
            …
         </plugin>
         <plugin>
            <name>HideEntry</name>
            …
         </plugin>
      </plugins>
      <default>
         <plugin name=”UserManagement”/>
         <plugin name=”DynamicGroup”/>
         <plugin name=”VirtualAttribute”/>
         <plugin name=”HideEntry”/>
      </default>
   </pluginChains>
   …
   <dnAttributeList>
      …
      <!– the following two attributes are added for dynamic groups –>
      <attribute>description</attribute>
      <attribute>departmentNumber</attribute>
   </dnAttributeList>
   …
</ldap>

– Add libOVD trace logging in bpmdomain/config/fmwconfig/servers/AdminServer/logging.xml
      <logger name=’oracle.ods.virtualization’ level=’TRACE:32’/>

   Trace output is in domains/bpmdomain/servers/AdminServer/logs/AdminServer-diagnostic.log.

   Please note that I am using AdminServer as my SOA server. If a different server name is used in your environment, the log file location and name will be different.

– In 11g PS6, new Access logging feature is added to libOVD. We will look at that feature in a separate post in the new future.

Start-up

By looking at libOVD initialization process, we can get a good idea about the usage of different libOVD configuration files.

– Load schemas
      Just like a regular LDAP server which has a predefined set of schemas out of the box, libOVD comes with a set of schema files in the form of xml files bundled inside the jar files. These schemas are what exposed to the client applications. A mapping between the libOVD schema and backend LDAP schema is provided automatically out of the box.

– Load global plugins defined in bpmdomain/config/fmwconfig/ovd/default/server.os_xml
      — GenericMapper
               The GenericMapper plugin is used to translate libOVD out of the box schema to an external LDAP such as ODSEE schema. The out of the
box mapping is defined in domains/bpmdomain/config/fmwconfig/ovd/default/mappings.os_xml. One example is a libOVD attribute named “login” is
mapped to “uid” in ODSEE.
      — MlsFilter
      — UniqueEntryPlugin

The global plugins are the first ones to be added to overall plugin chains. Plugins defined in individual LDAP adapter (in adapters.os_xml)
are added to the chain later.

– Load adapters defined in bpmdomain/config/fmwconfig/ovd/defaultadapters.os_xml 

      This is a two step process:
         — Load routing rules for each defined adapter, which include:
                  — Inclusion rules
                  — Exclusion rules
                  — Priority
                  — Criticality (not sure what exactly it means)
            — Load plugins defined for each adapter

– Register MBean: the final step in libOVD initialization
      — objectName com.oracle:type=OVD,context=default,name=ServerConfig
      — objectName com.oracle:type=OVD,context=default,name=MappersConfig

Adapters

libOVD has two default out of the box adapters named “Schema” and “Root“. An intelligent guess for the “Schema” adapter would be that it is for query libOVD schema definitions. The purpose of the “Root” adapter is unclear from the diagnostic logs. Neither of the two adapters shows any impact in test cases. The Schema adapter has a suffix of “cn=schema“, and the Root adapter has a suffix of “” (blank).

In my testing scenario, there are two adapters defined in the bpmdomain/config/fmwconfig/ovd/defaultadapters.os_xml file. The first adapter is named “DefaultAuthenticator” and the second one is “ODSEE“. They are the sames names defined in WLS realm. The DefaultAuthenticator is for the embedded LDAP in WLS, and the ODSEE is the iPlanet authenticator.

It is common practice to use different search bases for users and groups. As a result, libOVD will create two separate suffixes for each LDAP adapter. In this case, libOVD will define a total of 4 adapters (or suffixes to be more accurate):

      Adapter#DefaultAuthenticator, suffix: ou=people,ou=myrealm,dc=bpmdomain
      Adapter#ODSEE, suffix: ou=people,dc=migration,dc=test
      Adapter#GROUP-DefaultAuthenticator, suffix: ou=groups,ou=myrealm,dc=bpmdomain
      Adapter#GROUP-ODSEE, suffix: ou=groups,dc=migration,dc=test

Adding the Schema adapter to the beginning of the adapter chain and the Root adapter to the end, there are now a total of six adapters (suffixes). With the global plugins and individual adapter plugins, a chain of adapters and a chain of plugins are formed as the following:

      Adapter#SchemaAdapter, suffix: cn=Schema
          plugins:
               GenericMapper
               MlsFilter
               UniqueEntryPlugin
      Adapter#DefaultAuthenticator, suffix: ou=people,ou=myrealm,dc=bpmdomain
          plugins:
               GenericMapper
               MlsFilter
               UniqueEntryPlugin
               DynamicGroup
               VirtualAttribute
      Adapter#ODSEE, suffix: ou=people,dc=migration,dc=test
         plugins:
               GenericMapper
               MlsFilter
               UniqueEntryPlugin
               UserManagement
               DynamicGroup
               VirtualAttribute
               HideEntry
      Adapter#GROUP-DefaultAuthenticator, suffix: ou=groups,ou=myrealm,dc=bpmdomain
         plugins:
               GenericMapper
               MlsFilter
               UniqueEntryPlugin
               DynamicGroup
               VirtualAttribute
      Adapter#GROUP-ODSEE, suffix: ou=groups,dc=migration,dc=test
         plugins:
               GenericMapper
               MlsFilter
               UniqueEntryPlugin
               UserManagement
               DynamicGroup
               VirtualAttribute
               HideEntry
      Adapter#RootAdapter, suffix: “”
         plugins:
               GenericMapper
               MlsFilter
               UniqueEntryPlugin

Overall Query Procedure

When a LDAP query is received, libOVD runs the query against the routing rules for each suffix in the chain to select the matching suffixes. Then the actual query takes place in each selected adapters. We will look at the Workspace login process in details in the next post.

All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission