LibOVD provides limited virtualization capabilities when compared to its big brother OVD (Oracle Virtual Directory), who is a full-blown server implementing the LDAP protocol with far more advanced virtualization features, including OOTB support for LDAP and database backend servers, advanced configuration for adapters, out-of-box plug-ins as well as a plug-in programming model allowing for almost limitless possibilities in transforming data and connecting to external data sources.
Take SOA’s Human Workflow component, for instance. Customers frequently have an external identity store, like OID or Active Directory, holding the application end users and related enterprise groups. But they also often want to keep Weblogic’s embedded LDAP server for administration accounts, like weblogic user. Or they simply have an LDAP server in the US and another one in Brazil and want to bring all those users together. Using User/Role API alone is not enough.
That does not mean libOVD can be used only by FMW components. It is ok that your custom applications employ libOVD and that’s a given once you enable libOVD for a given domain. However, do not expect any of those features only available in OVD. A common mistake is expecting libOVD to work with a database authenticator. LibOVD is only for LDAP authenticators.
Another use case for libOVD is known as split profile, where information about the same identity exists in more than one LDAP-based identity store and your applications need a consolidated view. More information here: http://docs.oracle.com/cd/E21764_01/core.1111/e10043/apidvirtual.htm#CIHDGFIC
<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider"> <property name="idstore.config.provider" value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/> <property name="CONNECTION_POOL_CLASS" value="oracle.security.idm.providers.stdldap.JNDIPool"/> <property name="virtualize" value="true"/> <property name="OPTIMIZE_SEARCH" value="true"/> </serviceInstance>
It is possible to hand-edit jps-config.xml, but I recommend that you use Enterprise Manager to set it up, because the minimum mistake in jps-config.xml can get the WLS domain into a non-startable state.
Note: Unless your application makes explicit usage of a different JPS Context, this is domain-wide set up, impacting all applications deployed in that domain, both from authentication and user/group lookup perspectives.
Enabling libOVD using Enterprise Manager:Navigate to the domain Security Provider Configuration screen and click the Configure button, as shown:
Then use the Add button to add the property.
When you enable the virtualize flag, a new folder structure along with some files are created under $DOMAIN_HOME/config/fmwconfig folder.
Notice the default folder name: it refers to the default JPS context in jps-config.xml, which in turn refers to the idstore service instance for which libOVD has been configured.
These are familiar files to readers used to OVD. adapters.os_xml, for instance, lists the configured adapters for libOVD. An adapter is created for each authenticator listed in Weblogic’s config.xml.
3. Be Aware
Such configuration may cause a performance overhead if customers happen to have more users and groups distributed across other nodes that are also children of the common root but who are not necessarily required by the applications running on Weblogic. Wasted LDAP queries.
Notice the undocumented property OPTIMIZE_SEARCH in the jps-config.xml snippet presented before. It is the solution to the problem just described because it forces libOVD to search only within the users and groups search bases defined in the authenticator providers. No searches are performed elsewhere.
In order to take advantage of OPTIMIZE_SEARCH, make sure to get the appropriate patch for the corresponding release of FMW:
- FMW 18.104.22.168: 14693648
- FMW 22.214.171.124: 14919780
- FMW 126.96.36.199: 14698340
4. Managing libOVD
and check the available commands.
5. Debugging libOVD
<logger name='oracle.ods.virtualization' level='TRACE:32'>
<handler name='odl-handler'/> </logger>