What is SCIM?

SCIM is a standard protocol for accessing identity information (users, roles, etc), including querying, retrieval, create, update and delete. The latest version of SCIM, SCIM 2.0, has been defined in a series of RFCs: RFC 7642, RFC 7643 and RFC 7644. What does SCIM stand for? Originally it was an acronym for “Simplified Cloud Identity […]

Oracle Unified Directory 11gR2PS3 Very Large Static Groups

This post is about OUD and extremely large static groups where membership numbers exceed hundreds of thousands or even millions; yes I said millions.  I have been using Directory Services for over 15 years and the response I typically have for a customer that wants to use very large static groups is don’t do it.  Then I steer […]

Improve Oracle Unified Directory 11gR2 Search Performance with Index Entry Limit

Introduction I am always looking for great tips that give big values; this one is no exception. This article is to help you understand how to tweak the index called “Index Entry Limit” to reap some dramatic ldapsearch performance improvements. I explain what this index is about, some of my own test results, how to determine the […]

Chained LDAP Authentication in OAM 11g

Introduction In this post, we look at a simple way to configure a chained LDAP authentication scheme in OAM 11g R2. This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. All […]

Part 2: Advanced Apache JMeter Stress Testing OAM and LDAP

Introduction In “Part 1: How To Load Test OAM11g using Apache JMeter” I talked about an example plan that could be used to load test OAM11g, which included some common configuration elements, some samplers for login, authorization, logout, and some listeners that provided result analysis.   In Part 2, I wanted to expand on an […]

OAM LDAP connections through firewalls

Introduction In a previous post, we discussed some of the complications that can occur when a firewall is placed between WebGates and OAM Servers in a typical deployment. This post follows on from that discussion, to explore an analogous topic- firewalls between the OAM Server and the LDAP Identity Store. This post is part of […]

Where has your LDAP connection pool gone?

Introduction You have deployed Oracle BPM and decided to run some load tests against it. You’re concerned, among other things, about the behavior of your backend LDAP server under peak times, whether it’s going to be able to handle the load or not. You check the security providers settings in Weblogic Server and see you […]

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 […]

Password Policy in OAM 11g R2

One of the features in the new 11G R2 (or 11.1.2) release of Oracle Access Manager that’s been most eagerly anticipated is the support for password policy within the OAM product; that is, the ability for OAM itself to support a subset of pass…

Achieve Faster WebLogic Authentications with Faster Group Membership Lookups

In my last post  I wrote about the complicated and timely process of determining all of a user’s group memberships when an LDAP namespace includes nested and dynamic group memberships. I wrote about how you can simplify and speed up getting a user’s group memberships through the use of a dynamic “member of” attribute and specifically the orclMemberOf attribute in OID.

Today I’d like to extend this discussion to WebLogic server authentications.

A Review of LDAP Authenticators and Groups

As I’ve written about in the past, as part of the authentication process, LDAP authenticators do a search to determine what groups the user is a member of which in turn get used in determining the group memberships and roles for the JAAS subject and principals.

By default the WebLogic LDAP authenticators follow the long time consuming process I laid out in my last post for determining group memberships with nested groups. First, it searches all your groups to figure out which groups your user is directly a member of. Then for each of those groups, it searches all your groups again to see which of those groups your user is a member of.

It will continue to search your groups with the results of each subsequent search until you reach the configured maximum level of nested memberships that you want to pursue or all the searches come back empty.

Only it is actually quite a bit “worse” than that because for some reason when the authenticator finds a group within a group it doesn’t just use the DN of that group in the next search, it takes the name of that group based on the “group name attribute” setting in the authenticator and then does a search to find the group’s DN all over again. So, for every group found in a search of memberships for the user there will be 2 new LDAP searches performed. One to get the user’s DN again and one to get the groups that group is a member of.

In my post on tuning LDAP authenticators, I wrote about the importance of tuning the settings governing group membership searches in the authenticator and specifically about limiting the depth of the searches for nested group membership.

Speeding Things Up

Today, I’d like to cover how-to dramatically speed up this process by letting the directory do all the work for you. This is achieved by configuring the authenticator to take advantage of the dynamic ‘member of’ (orclMemberOf in the case of OID) attribute that I wrote about in my last post.

The setting that enables this behavior is in the Dynamic Groups section of the provider specific configuration for LDAP authenticators and is called User Dynamic Group DN Attribute. When configured the LDAP authenticator will skip all searches (for both direct and nested memberships) of dynamic groups. Instead it will add roles (group principals) to the user for every group returned by the LDAP directory (OID) in the value of the specified attribute.

Here is what you need to know about this setting:

1) When configured the authenticator will add roles (group principals) to the user for every group returned by the LDAP directory (OID) in the value of the specified attribute.
 
2) Despite the fact that the setting is part of the Dynamic Group section of the authenticator configuration, the authenticator will add roles for every group returned as part of the value of the attribute, regardless of whether that group is a static group or dynamic group.

3) That being said, the authenticator will still perform a search of memberships for all static groups even when the User Dynamic Group DN Attribute is defined. It will not however perform a membership search of dynamic groups; instead it assumes all dynamic group memberships are captured by the attribute value.

Note especially that the authenticator will still perform a full search of nested static groups even when User Dynamic Group DN Attribute is defined; even though the orclMemberOf attribute in OID includes static group memberships.
Putting It All Together
So, to dramatically improve your WebLogic authentication performance with nested groups I recommend that you configure your authenticators as follows:

1) Enter the appropriate LDAP attribute name for the value of User Dynamic Group DN Attribute based on the type of directory you are authenticating against.. Appropriate values include orclMemberOf for OID, memberof for DSEE, and ismemberof for AD.

2) Set the value of GroupMembershipSearching to limited. The default value is unlimited.

3) Set the value of Max Group Membership Search Level to 0. This will make the authenticator not perform searches for nested group memberships and limit it to performing a single search to find the users direct group memberships. Again, we will be relying on the value of the attribute specified in User Dynamic Group DN Attribute to give us the nested searches.

4) If you want to even eliminate the direct group membership search you can specify an empty Group Base DN. Note here that the Group Base DN must exist or you’ll get an error and a failed authentication. However, it can be empty. So, you can create cn=fakegroupbase as a sibling of cn=Groups,dc=example,dc=com.

5) If you recall in my previous post I mentioned that using the orclMemberOf attribute can result in duplicate listing when nested memberships are returned multiple times, once for each group that the user belongs to that is a member of another given group. Because of this, you’ll probably want to check the Ignore Duplicate Membership option in the authenticator.

Below is a screen shot of an OID authenticator configured with these options:

Fast Group Membership Lookups in OID with the orclMemberOf Attribute

If you utilize nested and dynamic groups (and especially nested dynamic groups), then it can take a lot of effort and time to calculate all of a user’s group memberships in an LDAP directory.

First you have to search for the user and find the user’s DN. Then you have to search all your groups to figure out which groups your user is directly a member of. Then for each of those groups you have to search all your groups again to see which of those groups your user is a member of.

You have continue to search your groups with the results of each subsequent search until you reach the maximum desired level of nested memberships that you want to pursue or all the searches come back empty. All the while you have to keep yourself out of infinite loops created by repeating memberships such as when two groups are members of each other.

Many LDAP directories simplify things through a virtual “member of” attribute which is a virtual multi valued attribute containing all of the groups a user is a member of through both direct and indirect means.

It may have escaped your notice, but OID joined the party fairly recently (in 11.1.1.4 I believe) and now supports such an attribute. The attribute’s name is orclMemberOf. You can read all about the attribute here; but suffice it to say it is a dynamic multi valued attribute containing the groups to which a member belongs.

The membership includes both direct membership and indirect membership from nested groups. It also includes membership from dynamic groups and dynamic nested groups based on labeleduri.

The attribute value is computed during a search and is not stored. This means you will not see orclMemberOf populated in an LDAP data browser including ODSM. Further, the value is not returned by default in searches. You have to explicitly request it. Lastly, orclMemberOf cannot be used in a search filter.

One nice little additional feature thrown in is that the aliases of memberof and ismemberof are supported for compatibility with code written for compatibility with Active Directory and Oracle Directory Server Enterprise Edition (DSEE) / SunOne / IPlanet.

Below is a sample search with results for a specific user where I request and receive the value(s) of orclMemberOf.  You will also notice that nested memberships are returned multiple times, once for each group that the user belongs to that is a member of another given group.  So, watch out for that.

In a future post, I’ll discuss how you can use the orclMemberOf attribute to greatly speed up authentication into WebLogic and Fusion Middleware Products such as SOA Suite and WebCenter which utilize WebLogic’s security framework.

[oracle@oam1 bin]$ ./ldapsearch -h oam1.example.com -p 3060 -D cn=orcladmin -w Oracle1_g -b “cn=Users,dc=example,dc=com” -L -s sub -v “uid=tim.doyle” memberOf

ldap_open( oam1.example.com, 3060 )

filter pattern: uid=tim.doyle

returning: memberOf

filter is: (uid=tim.doyle)

dn: uid=tim.doyle,cn=users,dc=example,dc=com

memberof: cn=administrators,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=nyusers,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=nestgrp1,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=oaamcsrmanagergroup,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=oaamenvadmingroup,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=oaamruleadministratorgroup,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

memberof: cn=product support group,cn=groups,dc=example,dc=com

memberof: cn=groupofgroups,cn=groups,dc=example,dc=com

1 matches

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>

5 minutes or less: Indexing Attributes in OID

I’ve written this short post as just a note to myself quite some time back. Since I had to rely on it quite a couple of times, I thought it would be worth sharing it with our readers.

It may be too basic to some people, but I am sure others out there had, are having or will have issues when running searches with LDAP filters against OID (Oracle Internet Directory), especially if those filters refer to custom attributes. The information presented here is certainly available in OID Administration Guide at Managing Directory Schema chapter, but it still might be a little bit scattered.

First and foremost: an attribute is only searchable in OID if it is indexed. This is definitely not the case of any your brand new custom attributes.

Any search containing a non-indexed attribute in the ldap filter will return something like:

> ldapsearch -h localhost -p 6501 -D "cn=orcladmin" -w welcome1 -b "cn=users,ou=mycompany,dc=com"–s sub "assistant=kathy"

ldap_search: DSA is unwilling to perform
ldap_search: additional info:
LDAP Error 53 : [LDAP: error code 53 - Function Not Implemented, search filter attribute assistant is not indexed/cataloged]

Second, directly from OID Administration Guide, About Indexing Attributes section:

You can index only those attributes that have:

The error message above is straightforward. But how do you create an index for the attribute?

There are 3 ways to index attributes in OID: i) using ODSM (Oracle Directory Services Manager), ii) using ldapmodify or iii) using the catalog tool.

ODSM and ldapmodify are only good if you have just defined the attribute and there’s still no data associated with it. Only values added after the index creation are indexed.

The safest approach is running OID’s catalog tool, because it indexes all existing attribute values.

1) Indexing attributes using ODSM:

 

ODSM_IndexingAttr

Here I’ve randomly picked a non-indexed attribute, assistant. The Indexed checkbox (pointed by the blue arrow) is read-only. You actually have to click on the button pointed by the red arrow first.

2) Indexing attributes using ldapmodify:

 

Create a small ldif file as the one below and run ldapmodify using the –f argument.

dn: cn=catalogs 
changetype: modify
add: orclindexedattribute
orclindexedattribute: assistant

> ldapmodify –h <host> –p <port> –D <admin user dn> –w <password> –f <ldif file>

3) Indexing attributes using the catalog tool:

 

a) Set the ORACLE_HOME environment variable to the your IDM ORACLE_HOME installation. If you’ve accepted the names given to you by the Oracle Installer, this value is typically $MW_HOME/Oracle_IDM1. The catalog tool is found under $ORACLE_HOME/ldap/bin

b) Set the ORACLE_INSTANCE environment variable to your IDM instance installation. If you’ve accepted the names given to you by the Oracle Installer, this value is typically $MW_HOME/asinst_1. Under $ORACLE_INSTANCE you should find a tnsnames.ora under the config folder. This is where the catalog tool gets your database connection details.

c) Run

$ORACLE_HOME/ldap/bin/catalog connect=”OIDDB” add=true attribute=”assistant”

 

If you want to delete an existing index:

$ORACLE_HOME/ldap/bin/catalog connect=”OIDDB” delete=true attribute=”assistant”

where OIDDB is the actual tnsname defined in your IDM instance tnsnames.ora file.

Oracle WebCenter and Dynamic Groups from an External LDAP Server (Part 2 of 2)

This blog post will cover how to get dynamic groups to work with Oracle WebCenter without having to use an External Oracle Virtual Directory instance.

Background information on Dynamic Groups and Oracle WebCenter could be found on the Part 1 of 2 blog post. It also covers how the OVD DynamicGroups Plug-in works as well as its use with an external OVD instance.

WebCenter’s user creation, authentication, and authorization is managed using Oracle Platform Services Security (OPSS). The OPSS API queries the LDAP server for groups with users identified by the uniquemember objectclass. The DynamicGroups Plug-in works by monitoring returned LDAP objects and detects objects where the memberurl attribute is present, it automatically processes any memberurl values and adds the results to the uniquemember attribute.

Oracle WebCenter and Dynamic Groups from an External LDAP Server (Part 1 of 2)

Oracle WebCenter and Dynamic Groups from an External LDAP Server (Part 1 of 2)

Do you have some dynamic groups on your Directory?

Are you puzzled on how to get these privileges into your WebCenter Portal/Spaces/Content -a.k.a. UCM?

This blog post will cover what works and how to fix what doesn’t work yet so that you could have your dynamic-group-based memberships on your WebCenter products.

OIM 11g & LDAP Synchronization

Since the first OIM 11g release, one of the frequently asked questions about OIM 11g is:

  • Should I configure OIM with LDAP synchronization or should I deploy a LDAP connector?

Since earlier versions, OIM provides connectors for the most popular LDAP systems: Oracle Internet Directory (OID), Oracle Directory Server EE (formerly Sun Java Directory/iPlanet), Novell eDirectory and Microsoft Active Directory (AD).

With OIM 11g, a new feature called LDAP synchronization was introduced. OIM uses this feature to synchronize its users and roles base to a LDAP system. This synchronization is bidirectional and it uses scheduled jobs/reconciliation engine to pull changes from LDAP and event handlers to push data to LDAP.
But if OIM already provides a connector for most of the industry LDAP servers, why provide a feature like LDAP Synch? Different customer’s business requirements, customer feedbacks and also some technical reasons led Oracle to develop this feature and make it available out-of-the-box in the product.


Going back to the fundamental question of this post: which one should I use? And the answer is, as usual, IT DEPENDS. It really depends upon the project requirements and their alignment with the different approaches functionalities and technical details.

But before you start saying “I do have my requirements, but I still don’t know which one to use”, let’s review the main differences between these two implementation approaches. With some knowledge about the main differences and the project requirements in hands, certainly it will be easier to make a decision.

  • LDAP Synchronization is a mandatory piece for the OIM-OAM integration (in the current 11.1.1.x releases). So if you are planning to integrate these products and make full use of the password lifecycle management features provided by the integration, LDAP Synch is a MUST. 
  • LDAP Synchronization is data oriented approach. Although it is possible to configure attribute mapping, basic synchronization rules and some other minor things, in the end, it is all about data: users and roles being synched behind the scenes from/to the LDAP server. The synchronized LDAP account is NOT in the users’ accounts list in OIM.
  • Connector is a process oriented approach. In this approach, one can make full use of OIM features like request/approvals based provisioning, access policy based provisioning, modification requests. A user will see, among his/her accounts, the LDAP account and he/she can take actions from there.
  • Reporting and auditing will contain information about the LDAP account only if a LDAP connector is implemented.

There are other technical details and functionalities that may be considered, but the topics above are the basics and first ones that you can use to help on the decision.

Using the Database as a Policy Store for SOA 11g

 
As more and more customers of SOA 11g move to production, we have been
asked often about the recommendations for a PolicyStore for SOA 11g in
production. This post addresses the various policy store options,
helps evaluate the pros and con…

Tuning WebLogic LDAP Authentication Providers

I’ve been involved in a fair amount of activity over the last month involving customers who want or need to tune their WebLogic LDAP authentication providers for a production environment.

Too often I have seen customers simply lacking in awareness to the fact that the authentication providers can and should be tuned from their default settings. The fact is that the default values in the LDAP authentication providers are better sized to development environments (and in some cases the development environments of 5 years ago) then they are to today’s production environments. So, the first step is awareness that the authentication providers include setting related to cache performance, connection management, and handling of group lookups that can and should be tuned in order to maximize the performance of your applications.

So, in this post I’d like to go through the authentication provider settings that affect performance, discuss what each setting does, and discuss what some guidelines and how these differ from the defaults.

First, let’s briefly discuss how to find the settings you’ll want to tune. Login to the WLS admin console, on the left hand side under domain structure click security realms and then “myrealm”. From there, click on the providers tab and select the LDAP authentication provider that you want to tune. Once you are in the authentication provider configuration screen you’ll want to look in the “Provider Specific” and “Performance” tabs to modify the settings we are about to discuss. We will also discuss one setting that is located under the “Performance” tab of “myrealm” (or whatever you have named your active security realm) itself.

If all goes well you should see a screen that looks something like this after clicking the provider specific configuration tab:

In discussing the tuning of LDAP authentication providers, I like to divide the settings into 3 categories: LDAP connection settings, cache settings, and group lookup settings.  If you’d like to follow along with what the documentation says you can do so here: http://download.oracle.com/docs/cd/E21764_01/web.1111/e13707/atn.htm#i1216261

Connection related settings:
Connection Timeout Limit – The maximum time in seconds to wait for the connection to the LDAP server to be established. The default is set to 0 which means that there is no maximum time limit. Note that this setting only comes into play when the authenticator is trying to open up a new connection in its pool of connections to the directory.

Connection Retry Limit – The number of times the server will attempt to connect to the LDAP server if the initial attempt fails. The default is 1. Again this setting applies only to situations where the authenticator is trying to open up new connections.

Now you may ask what happens if the connection timeout limit is reached and all retry attempts fail. The answer is that the authenticator will simply give up on the current request that it is trying to open a connection to handle and return a failure. Subsequent requests will be serviced from the available pool of connections until a new one must be opened again at which time the process will repeat itself.

I could be wrong but I see no good reason why one would want to wait forever. What you want to avoid is a cycle of death situation where degradation in LDAP performance is handled poorly and leads to things backing up more than they have to in the authentication provider. The specific values that you should go with for these settings are fairly environment specific in that they depend on your directory and network infrastructure but I think that 120 seconds for the Connection Timeout Limit and 5 for the Connection Retry Limit are good starting points.

Cache related settings:
Cache TTL and Cache Size

There are two cache settings on the “provider specific” tab of most LDAP authentication providers. These are Cache TTL and Cache Size. These setting refer to a “user related” cache in the authentication providers that cache the DN lookup that translates login names to full LDAP distinguished names and possibly caches some common attribute values following the lookup. I must stress that the authentication providers do not cache username and passwords. Real username/password authentication always results in a call to the directory. With that out of the way:

Cache TTL – is the time-to-live of entries in the cache in seconds. The default is 60 which seems low to me. I would consider upping this to 5 minutes and going from there.

Cache Size – is the size of the cache in kilobytes. The default is an absurdly low 32 KB. The per-entry size of this cache is low but I don’t think upping this to 2-4 MB would hurt.

The exception to the above recommendation would be a situation where you really don’t expect an individual user from hitting the authentication provider twice in a fixed period of time. In this case I would still up the Cache size some but might leave the TTL along at 60 seconds.

Principal Validator Cache

The Principal Validator Cache is actually a setting associated with the entire realm rather than the authentication provider and is configured in the “performance” tab of the realm itself. There are two settings associated with the cache: Enable WebLogic Principal Validator Cache and Max Weblogic Principals in Cache. It is enabled by default with the max number of principals defaulting to 500.

This cache is mentioned in the documentation in vague terms as something that can improve performance and indeed it is a fairly mysterious construct. What this cache does is cache signed Abstract Principals which are used in RMI calls when a Principal Validation Provider is being used.

The long and short of it is that this cache won’t have too much affect for most people and even in situations where it will be heavily hit, it is common for the validations to be associated with a limited number of service accounts. So, for the post part you can just leave these settings as is. However, don’t be afraid to bump up the number of cached principals, the default setting is very low considering the hardware you are likely to be running WLS on in production.

Group lookup related settings:

One of the most important, if not the most important piece of tuning you can do to a WLS LDAP authenticator is to change the Group Membership Searching from unlimited to limited and set the Max Membership Search Level to an appropriate value. Not only will this improve your performance, it will prevent you from encountering a loop that prevents users from logging in when two groups are members of each other. I blogged extensively about these two settings in a previous post entitled Weblogic, LDAP Authenticators, and Groups.
Rounding out the group lookup related settings are a group of settings that can be found in the performance tab of LDAP authentication providers.

These settings all deal with the group membership hierarchy cache. This cache stores the results of recursive membership group lookups or put another way it stores what groups are members of other groups.

The settings for this cache include a check box to enable the cache which is called Enable Group Membership Lookup Hierarchy Caching, a setting that controls the size of the cache called Max Group Hierarchies in Cache, and a setting that controls the time-to-live (in seconds) of cache entries called Group Hierarchy Cache TTL.

I recommend that you enable this cache if you utilize nested groups. I recommend that you set the Max Group Hierarchies in Cache to a value larger than the total number of groups in your directory. Finally, I recommend that you set the Group Hierarchy Cache TTL to a safe appropriate number. The default is 60 seconds which will improve performance, catch changes to the hierarchy fairly quickly, but still result in a fair amount of recursive group lookups. If you up this value to 5 minutes (300 seconds) which should still be safe for most people who aren’t doing funky things with dynamic groups then you should be able to improve performance a little more with no downside.

Conclusion

Tuning of WLS LDAP Authenticators is an overlooked component of successful WLS production deployments. Taking just a little time to change the LDAP authenticator performance related configuration settings from default values to values which are appropriate for your production environment can result in a much faster and more stable system.

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.

Extending the OID 11g schema via ldapmodify

I recently said the following to someone in an IMversation: ldapsearch and ldapmodify are about 10 times better than a stupid GUI because you can script everything.it’s like the difference between knowing SQL and having to use TOAD or Access (*shudder…