Where has your LDAP connection pool gone?

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 have an LDAP Authenticator (or some specialization, like OVD Authenticator, for instance) with an ldap pool size set to 50 connections. But your test reveals that many more than 50 connections gets open in your LDAP server. You change that number, redo your tests, but the behavior doesn't change at all. Then you get worried about the LDAP connection handling performed by the Weblogic authenticator.

This post is to tell you, as far this scenario goes, there's nothing wrong with it. In fact, for this specific scenario, you're looking at the wrong place for your connection pool settings.

Oracle BPM, as well as SOA, WebCenter, UCM (Universal Content Management), IPM (Imaging Processing Management) and others use something called User/Role API to communicate with LDAP stores. Whenever these components need to assert a user identity or query user/group/attribute information, they go through User/Role API. It is an abstraction built on top of JNDI to ease the access to Directory servers. You can connect to any LDAP server supported by WLS authenticators and use the very same set of APIs to retrieve and write data without having to resort on JNDI, regardless of the LDAP server you connect to.

Webgate Reverse Proxy Farm

Some of our larger deployments are seeing the benefits of centralizing their Webgate deployments onto a server farm. This post discusses some of the architecture and recommendation when deploying such an architecture.

First, what is a Webgate farm or Webgate Reverse Proxy farm? A Webgate farm is:

• A series of web servers that are clustered on the basis of their protected applications.
• These servers protect the same set of applications. It is not unheard of to create multiple farms for different sets of applications, say internal/external applications.
  
• This architecture acts as a reverse proxy to back end applications.

Some things to consider when deploying this architecture:

• Which team manages the proxy farm? Will it be the Security team or maybe the infrastructure team. Working knowledge of the farm infrastructure as well as proxy configuration is crucial.
• Web server type. Any web server that WebGate supports will work. Many of our customers use Oracle HTTP Server (OHS) or Apache which has good support for virtual hosting and reverse proxy configuration.

Some benefits in deploying a centralized Webgate farm:

• Adding patches/upgrading is easier knowing where the servers are as opposed to the application owner; Security team may not have access.
• Adding more servers and/or upgrading servers is easier in a clustered environment.
• Aside from Web-Gates protecting applications, the web server reverse proxy configuration defines which applications to expose. This provides additional security preventing inadvertent access.

Configuration considerations:

• Use a single Web-Gate profile for all servers in the farm. It is highly recommend that you use a single Webgate profile for all servers on the farm; otherwise you may see cookie decryption errors if the load balancer is not configured correctly.
  
• Use 'SERVER_NAME' for the preferred host value when using Apache/OHS and use 'HTTP_HOST_HEADER' for all other web servers. This is used for virtual hosting.  For more info on Host IDs take a look at this post.
  

Use Case: Internal/External Webgate Scenario

Let's say you have an internal facing application where both internal and external users are allowed access.  Well the easiest implementation is to only allow access through the DMZ.  This means that internal users must go back out to the DMZ to gain access.  Done.

Now let's say the requirement is that internal users must access the site internally and external users through the DMZ.  In 10g it was relatively easy to set this up (see diagram below).  All that was needed is two sets of Webgates; one within the DMZ and a second internally.  Once authenticated the ObSSOCookie is easily consumed by any of the Webgates shown below; as long as the same OAM infrastructure supported both internal and external users/applications.

In 11g, the cookie model is quite different as you an read here.  Supporting the above use case will not work out-of -the-box; nor is it recommended.  However it can be done with some caveats:

• Set a user defined parameter in the Webgate configuration, filterOAMAuthnCookie=false
• The Webgate profile for all Webgates depicted must be the same.

By default, the OAM_Authn cookie will not be passed along in the HTTP payload for security reasons; however, setting the parameter 'filterOAMAuthNCookie' to 'false' removes this condition.  Also keep in mind that the Webgate profile must be the same for both sets of Webgates in order for Single-Sign-On (SSO) to work.  This may not be feasible depending on your topology/requirements.

The recommended approach in 11g is to create a new end-point for the application.

Notice the distinction, we again decouple the Webgate from the application and create another Webgate Proxy farm (internally).  Why?  In 10g it was feasible for the Webgate plug-in to reside on the same web server as the application; it was also possible to have a single transaction going through two Webgates.  In 11g, this is not recommended; a single transaction should never pass through two Webgates.

A first look at POST data preservation in OAM 11g R2 PS1

In this post, we have a quick look at POST data preservation, a new feature introduced in the 11g R2 PS1 (or 11.1.2.1) version of Oracle Access Manager. We'll explain the problem that this feature solves and walk through a simple example explaining how to configure and use the feature. 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.

Part 1: How To Load Test OAM11g using Apache JMeter

Exciting, it is Go Live day, the system goes online, everything seems ok for a while, and then Kerplunk!  Thousands of things could have happened and everyone scrambles to figure it out.  What went wrong?   My first question is, “Was a proper load test completed?”  Yes, Load Test.  Functionally the software may have worked, but under a heavy load issues can start bubbling up.  If you have been there like I have many times you know what I am talking about.  Situations like this could be avoided? 

This is where this article comes in.  I have learned the hard way that load testing can provide a lot of great feedback to determine issues whether it be the software, the design, the deployment, or the architecture.  The bottom line is if you do not have fancy software like HP Load Runner, the poor mans version, Apache JMeter, can come to the rescue.  JMeter is FREE, well documented (As much as any other software at least), and there are tons of blogs and articles on JMeter since it has been around for quite a while.  JMeter can also do much more beyond HTTP type of load testing.  I would love to cover even more about JMeter, but unfortunately I have to focus this article to a basic load test that works with OAM11g.   Minimally, I hope this article at least gets you started and even excited to learn more about this great tool.

OIM Reset Password Customization Example

Out-of-the-box, the OIM reset password functionality is available to system administrators, and to delegated administrators who have administrative privileges on users’ accounts and have the ‘reset password’ privilege assigned to them. The data of the user who is having his/her password reset plays no role on how this functionality is presented to delegated administrators.

This post shows a way of having password reset functionality behaving differently depending on the end user data. This post is another post of the OIM Academy series, to check the series click here.
Before going further, it is important to mention that there is a need to first understand the OIM UI customizations concepts. Apart from the OIM documentation available here, you can also check this example and this post.