The importance of “orclguid” in Oracle Virtual Directory

Introduction This post will discuss the steps to configure the orclguid within Oracle Virtual Directory (OVD).  It is especially important when integrating OVD with Oracle Access Manager (OAM) and Weblogic Server (WLS).  I see many customers omitting this configuration which leads to errors in OAM.   Main Article All Lightweight Directory Access Protocol (LDAP) repositories […]

Configuration of Users/External Roles Relationship in OES 11G for a Database Identity Store

Introduction Recently I worked with a customer who wanted to use their existing database that is tied to other applications as the identity store for OES11G implementation. We all know that for OES 11G, the Identity Store must be an LDAP based directory. So to address this use case we took the help of  OVD.  […]

Creating a Custom OVD Plugin

1. Introduction In a recent engagement, I worked with a customer that had a business requirement where they needed to create and expose to their application two computed LDAP attributes, based on the value of an existing attribute. For instance, let’s say the original attribute is “myCorpID” and its value could be something like “23451588-IT […]

OAM/OVD JVM Tuning

Over the past few weeks I’ve been involved in several performance tuning exercises involving OAM and OVD.  I thought it would be helpful if I created a post sharing the process I use to analyse and improve performance in OVD and OAM. The scenario …

LibOVD: when and how

LibOVD, introduced in FMW 11.1.1.4, is a java library providing virtualization capabilities over LDAP authentication providers in Oracle Fusion Middleware. It is delivered as part of OPSS (Oracle Platform Security Services), who is available as part of the portability layer (also known as JRF – Java Required Files). In other words, if you are a JDeveloper, WebCenter, SOA or IAM customer, you already have libOVD.

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.

1. When

 

LibOVD is primarily designed to work as an embedded component for FMW components who need to look up users and groups across distinct identity providers. If you had a chance to look at this post, you already know the User/Role API can take into account only one authentication provider.

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

2. How

 

LibOVD is activated when you set the property virtualize=true for the identity store provider in jps-config.xml:

<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:

 SettingVirtualize_1

Then use the Add button to add the property.

SettingVirtualize_2

When you enable the virtualize flag, a new folder structure along with some files are created under $DOMAIN_HOME/config/fmwconfig folder.

libOVD_folders

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

 

Within a single adapter, in order to search across both users and groups search bases, libOVD sets the adapter’s root to be the common base between them. For example, let’s say users and groups search bases are defined as cn=users,dc=us,dc=oracle,dc=com and cn=groups,dc=us,dc=oracle,dc=com, respectively. In this case, the adapter’s root is set to dc=us,dc=oracle,dc=com.

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 11.1.1.6: 14693648
  • FMW 11.1.1.5: 14919780
  • FMW 11.1.1.4: 14698340

4. Managing libOVD

 

libOVD can be managed via wlst.sh. When connected, type

> help(‘OracleLibOVDConfig’)

and check the available commands.

5. Debugging libOVD

 

To debug libOVD, create a logger for oracle.ods.virtualization package in your server’s logging.xml file. Here’s a snippet.

<logger name=‘oracle.ods.virtualization’ level=‘TRACE:32’>

 <handler name='odl-handler'/>
</logger>

OVD 11g LDAP Error 2 : Bad LDAP Filter

Hi everyone, just a quick post on an issue I encountered with OVD 11g (11.1.1.2) and how it handles LDAP filtering.

For this post let’s use the following DN as our example:

“cn=OVD (11g), dc=us, dc=oracle, dc=com”

This is a perfectly valid DN, however, it has been discovered that DNs with parenthesis have issues within OVD.Within the logs you may see “Bad LDAP Filter” errors:

! com.octetstring.vde.util.DirectoryException: LDAP Error 2 : Bad LDAP
Filter.
at com.octetstring.vde.util.ParseFilter.parse(ParseFilter.java:291)…

You may have guessed that the solution is to encode the ‘cn’ attribute.Here is a description of how to encode as described in RFC 2254.

 

If a value should contain any of the following characters

 

CharacterASCII value

—————————

*0x2a

(0x28

)0x29

\0x5c

NUL0x00

 

the character must be encoded as the backslash ‘\’ character (ASCII

0x5c) followed by the two hexadecimal digits representing the ASCII

value of the encoded character. The case of the two hexadecimal

digits is not significant.

So using the above example, the ‘cn’ should now be encoded as follows: “cn=OVD \5c2811g\5c29”.So when creating entries into your LDAP repository, make sure you encode the backslash ‘\’ character and both parenthesis ‘()’ as described above.

I know what you are thinking.What if I already have thousands of users that contain these special characters?I’m certainly not going to go back and encode the ‘cn’ for each user!Well, for that there is a patch coming out to address this problem.As of this writing the solution has been identified and is due out for 11.1.1.4.

Error message “Can not resolve hostname for interface any” from opmnctl

I ran into a problem with opmnctl on one of the many virtual machines and I know that someone else out there will have the same problem. This was a machine with the Identity Management bits (OID, OVD and OIF) that I had just patched up to 11.1.1.5. Whe…

Using the x.509 Attribute Sharing profile responsibly

I’m back, rested and I’ve had some time to think about the crazy (clever?) OVD adapter I wrote for last week’s PoC. You know, the one that lets you do a search for certdn= the user’s certificate DN and it makes a SOAP call over to OIF to get the user …

My first custom OVD adapter

For a PoC I have been working on I wrote a (demo quality) OVD adapter that I thought might be interesting for others.

In my PoC I had OIF, OAM, OVD and DSEE and OES. In the main use case a user can come along to the SP with an x.509 certificate issued by an issuer known to the SP. The SP is expected to do the normal certificate authentication “stuff” (crypto operations, CRL & OCSP checking) and then make authorization decisions for URLs based upon the user identity including information about the user that the SP doesn’t get in advance. To get that information the SP will need to make SAML attribute requests to an IdP.

Out of the box OAM and OIF support this use case via the Oracle Access Manager AuthZ Plug-in. That plug-in makes calls to OIF which in turn goes and gets the necessary attributes from the right IdP. This is great and answers most of the requirement.

The missing bit is that this customer wanted to go further… much, much further. They want to make very fine-grained authorization decisions deep down in their applications (by calling OES). And they want OES to make its decisions based on the attributes coming from the IdP.

My first plan was to write an equivalent to the OAM x.509 Attribute Sharing plug-in for OES. It should have taken me all of a couple of hours start to finish including deploying it in the PoC environment. Naturally I thought to myself “That’s not all that interesting. Why don’t you do something more clever?”. I blame too much caffeine and inadequate sleep for that thought.

Everything in the environment (OAM, OES, WebLogic and a few other things) already make LDAP calls to get user info and make authorization decisions. Why not hide all of the SAML stuff down in OVD. Then there’s only one place that needs to talk to OIF.

Click through to see what I did.

First some background. The X.509 Attribute Sharing Profile is a little known profile that allows something inside a Service Provider to ask the Service Provider to ask the Identity Provider to get some attributes about the user.

So it’s a “two hop” operation. Something like OAM would make a call to the local SAML Service Provider which includes the DN of the x.509 certificate. The local Service Provider takes that DN and looks though its configuration to figure out which IdP is responsible for the user. The SP then makes a conventional SAML attribute retrieval from the IdP and returns it.

As I mentioned in the intro Oracle ships a plug-in for OAM to make that call. I could have just written the same thing for OES. Had I done that I’d have been done in an hour or maybe a couple of hours if it took longer than expected. Then I could have had a nice dinner and shared a bottle of wine with the sales guy and followed that up with a good night’s sleep.

But where’s the fun in that?

What I decided to do instead was hide the XASP call inside OVD. OAM would do a search for a user with the certdn set to the DN of the certificate. My plug-in would see that search, make the XASP call, build up a fake record in memory, squirrel it away in a cache and return it back to OVD. The caller would see a regular LDAP record and can retrieve attributes of that record.

Any other apps calling OVD via LDAP can execute a search against the directory and my plug-in should return the right record.

Here’s what that looks like in practice…

The environment looks like this:

Here’a a search looking for mail= someone that it has never seen before. In this case my plug-in doesn’t find the user in its cache and since it doesn’t have a certificate DN it can’t make an XASP call. Consequently the search result won’t return any users:


$ ldapsearch -x -w welcome1 -b ou=ismyidentity,ou=People,dc=us,dc=oracle,dc=com 'mail=sara.i@ismyidentity.com'
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: mail=sara.i@ismyidentity.com
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

Here’s an example search with a Certificate DN. When I make this LDAP call the plug-in makes an XASP call and remaps all of the attributes from SAML into their LDAP names:


$ ldapsearch -x -w welcome1 -b ou=ismyidentity,ou=People,dc=us,dc=oracle,dc=com 'certificatedn=CN=Sara.I,OU=ismyidentity,O=Oracle,C=US'
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: certificatedn=CN=Sara.I,OU=ismyidentity,O=Oracle,C=US
# requesting: ALL
#

# sara.i@ismyidentity.com, ismyidentity, People, us.oracle.com
dn: mail=sara.i@ismyidentity.com,ou=ismyidentity,ou=People,dc=us,dc=oracle,dc=
com
certificateDN: CN=Sara.I,OU=ismyidentity,O=Oracle,C=US
clearanceLevel: S
cleared: T
sn: O
mail: sara.i@ismyidentity.com
displayName: sara
postalCode: USA
givenName: Sara
uid: sara.i
obuseraccountcontrol: ACTIVATED
obver: 10.1.4.0
cn: Sara.I
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: oblixOrgPerson
objectclass: authorizationPerson

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

If you repeat the first query again my plug-in returns the same record:


$ ldapsearch -x -w welcome1 -b ou=ismyidentity,ou=People,dc=us,dc=oracle,dc=com 'mail=sara.i@ismyidentity.com'
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: mail=sara.i@ismyidentity.com
# requesting: ALL
#

# sara.i@ismyidentity.com, ismyidentity, People, us.oracle.com
dn: mail=sara.i@ismyidentity.com,ou=ismyidentity,ou=People,dc=us,dc=oracle,dc=
com
certificateDN: CN=Sara.I,OU=ismyidentity,O=Oracle,C=US
clearanceLevel: S
cleared: T
sn: O
mail: sara.i@ismyidentity.com
displayName: sara
postalCode: USA
givenName: Sara
uid: sara.i
obuseraccountcontrol: ACTIVATED
obver: 10.1.4.0
cn: Sara.I
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: oblixOrgPerson
objectclass: authorizationPerson

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Before you go further a warning: If you’re going to try this at home make sure you test if for scalability. It’s not entirely clear that this will scale up to thousands of concurrent users. OAM and OVD will easily support that, as will OIF (as both the SP and IdP). But the entire architecture relies on SOAP calls over the Internet and those are notoriously latency heavy. As a result the initial access by a user will be relatively slow and that could cause any number of issues. If a large percentage of your users visit for only a short time those problems will be worse.

Want to follow in my footsteps? First start with the samples available from the samples page at Oracle.com. You’ll need the WSDL for the x.509 Attribute Sharing Profile service from the OIF docs. Then find yourself a caching mechanism – perhaps something like Coherence?You’ll also want to read my previous post on caching OVD’s Entry object.

Other than that it’s all pretty straightforward.

If you’re interested in my source code let me know in the comments. If there’s enough interest I’ll put it on samplecode.

Behavior of the OVD “Entry” class

As part of a demo I’m doing this week I wrote a custom OVD adapter and (for various reasons) included my own logic to cache the results between LDAP calls. Along the way I discovered behavior that perplexed me and probably shortened my life by days t…

Quick tip: OVD – Providing namespace translation for DN attributes

Breaking off the ADF/OPSS series…

OVD (Oracle Virtual Directory) guru Mark Wilcox gave me this really helpful tip that it’s worth sharing. It can save you folks quite a bit of headache.

Scenario: you have configured an OVD authentication provider in WLS, but you cannot login with any user from OVD in WLS Console, even the user being a member of an Administrators group in the backend LDAP directory. When you try it, you end up with an “Authentication Denied” error. And if you login into WLS Console in the “normal” way (i.e., using weblogic user from Default Authenticator provider) you don’t see the OVD users memberships. These two problems are definitely related.

Solution: you need to change the LDAP adapter definition in OVD a bit. Connect to ODSM (Oracle Directory Services Manager), retrieve your adapter, click on the General tab and add uniquemeber as one of DN Attributes, as shown:

image

OVD translates all attributes listed as DN Attributes. Translation here means converting the backend repository (in this case OID) namespace into the adapter’s namespace. In this example, OID namespace is dc=us,dc=oracle,dc=com, while adapter’s is ou=oid,dc=us,dc=oracle,dc=com. Without the translation, uniquemembers of a group would end up being cn=<user>,dc=us,dc=oracle,dc=com. With the translation, they align nicely with the adapter’s namespace: cn=<user>,ou=oid,dc=us,dc=oracle,dc=com.

No need to restart anything. You should now be able to see users memberships as well as login in WLS Console with administrators users defined in the OVD authentication provider.

Note: this has been done in Oracle Identity Management 11g PS2.