LDAP Load Balancing And Timeouts

It's been ages since I posted anything despite the fact I have lots to say. The last few months have been extraordinarily busy and challenging (and not necessarily in a technical way).

Some colleagues have pointed out that I have aged significantly in recent times. It is true that the hair on my chin has gone from grey to white and that the hair around my temples is severely lacking in any kind of hue. It seems that my work-life balance has gone slightly askew.

Balancing brings me rather neatly on to the topic of LDAP Load Balancing. I say Load Balancing though what I really mean to say is providing a mechanism for assuring availability of Directory Servers for IBM Security Identity Manager. My preference is for load to go to one directory server which replicates to a second directory server which can be used should something go awry on the primary.

So, what's the best way to ensure traffic routes to the correct directory server and stays stuck to that directory server until something happens? Well, that's the domain for the F5 BIG-IP beast. Or is it.

There is plenty of documentation around the web that states that one should tread carefully when attempting to use these kind of tools to front a directory server (and IBM Tivoli Directory Server in particular). In recent dealings, I've observed the following which is worth sharing:

Point 1
Be careful of the BIG-IP idle timeout default of 300 seconds. Any connection that BIG-IP thinks is stale after 300 seconds will be torn down. (You should see how a TDI Assembly Line in iterator mode behaves with that without auto-reconnect and skip-forward disabled!)

Point 2
Be careful of the TCP connection setup and seriously consider using Performance Layer 4 as the connection profile on the BIG-IP. A 50% increase in throughput was not atypical in some of my recent tests.

Point 3
Ensure that the default settings for LDAP pool handling are updated in ISIM's enRole.properties file. In particular, pay attention to the following:

enrole.connectionpool.timeout
enrole.connectionpool.retryCountForSUException

The timeout should be set just a little below the BIG-IP's idle timeout. The retryCountForSUException should be set to ensure that ISIM reconnects should the BIG-IP device tear-down the connection regardless of the timeout.

And with those tips, you should have a highly available infrastructure with a level of tolerance.

WebSEAL Landing Page Personalisation

Creating a Landing Page for WebSEAL authenticated users can be a useful technique for ensuring a consistent user experience, providing a means of delivering messages to end users and providing a personalised experience. This does not mean that you have to invest in a heavy-weight portal product to provide this functionality, though.

Simple ASPs, JSPs, PHP scripts, PERL scripts and any number of other scripting technologies can be used to greet the user and personalise the landing page without resorting to performing a lookup in the credential store for information. How can we do that? Well, to reuse a well-known modern-day philosopher's phrase, it's simples!

WebSEAL can pass the User ID of the user to the protected landing page in an HTTP header called IV_USER. We can pick this up as follows:

PERL
#!c:/perl/bin/perl
my $user = $ENV{"HTTP_IV_USER"};

JSP
<%
String user = request.getHeader("iv-user");
%>

ASP
<%
user = Request.Headers["iv-user"];
%>

PHP
<?php
$user = $_SERVER['HTTP_IV_USER'];
?>

Note: The names of the HTTP Header will vary depending on the scripting technology being used.

So now I have my User ID, I can make use of this information in my page to say something like "Welcome sswann". I nice touch, I'm sure you will agree.

But of course, WebSEAL can be so much more powerful that that. It can also send IV_GROUPS out of the box which will be the groups that the user is a member of. With this information, we could build a list of hyperlinks that are available to that user. In code/pseudo code, that could look like this:

String groups = request.getHeader("iv-groups");
if (groups.indexOf("administrators") >-1) {
   // Show a link to the administrator's application
}
if (groups.indexOf("auditors") >-1) {
   // Show a link to the auditor's application
}

Wonderful, you might think, with the obvious next question being "what else can I do?"

Well, we could add any attribute assigned to the user object in the TAM LDAP as a similar HTTP header object. To do so, though, is a two-step process:

Step 1: WebSEAL Configuration
Let's assume that we want to make the forename and surname for our user available to our landing page. We need to configure WebSEAL to retrieve these attributes from the LDAP and make them available within the credential. To do so, the WebSEAL configuration file needs updated as such:

[aznapi-entitlement-services]
TAM_CRED_ATTRS_SVC = azn_ent_cred_attrs

[aznapi-configuration ]
cred-attribute-entitlement-services = TAM_CRED_ATTRS_SVC

[TAM_CRED_ATTRS_SVC]
person = azn_cred_registry_id

[TAM_CRED_ATTRS_SVC:person]
tagvalue_credattrs_sn = sn
tagvalue_credattrs_givenname = givenname

Step 2: Junction Configuration
Next we need to ensure that we pass these attributes to our landing page. On the WebSEAL junction hosting this "personalised" landing page, we would perform the following pdadmin commands:

pdadmin> object modify /WebSEAL/webseal_instance/junction_name set attribute HTTP-Tag-Value credattrs_sn=surname
pdadmin> object modify /WebSEAL/webseal_instance/junction_name set attribute HTTP-Tag-Value credattrs_givenname=forename

Now, we can extract the HTTP header variables for forename and surname and provide a "Welcome Stephen Swann" message because these header attributes will be passed to our landing page process:

String surname = request.getHeader("surname");
String forename = request.getHeader("forename");

We haven't had to perform any lookups in a data repository and our landing page can be kept very simple indeed with just a couple of lines of scripting.

Mid-Range Systems Analysis

Mid-range systems are great, aren't they? Chuck a few hundred unix boxes at an infrastructure and horizontally scale to your heart's content.

Great theory... However, there seems to be a perception that having hundreds of servers "complicates" the infrastructure and fractures the understanding of the end-2-end process. I suppose that is one way to look at the issue - the route a transaction can take from a browser (for instances) through content switches, firewalls, load-balancers, proxies, application servers, messaging systems and on to mainframes (and beyond?) can be one of millions of possible routes. How can you troubleshoot and troublesome transaction in this case?

All is not lost, however.

Just because the architecture requires 10 proxy servers spread over multiple sites doesn't necessarily complicate matters. If we look at the infrastructure as having a proxy "service" which is made up of a number of identical components then the architecture looks less complicated immediately. The key is ensuring each box is identical.

There are any number of CVS systems available - some open source, some very expensive. (In the enterprise environment, open source is still to scary!). However, CVS systems are only of any use if the development process demands (and enforces) its use. This often isn't the case and it is astonishing how identical servers, under close examination, are never really that identical.

Anyway... the enterprise may well have a team to look after the proxy service, a separate team to look after the application service, another team to look after the database service, the directory service, the security service, etc. If a transaction goes awry - which team is responsible for tracking down the fault? Each team automatically becomes defensive about their "service" and resolution can be tricky! This is usually exacerbated by the fact that often the teams don't know what the end-2-end process is and (therefore) the implications of their actions.

So... who joins up the infrastructure? Unix administrators? No! Application Server administrators? No! My answer would be... those people in the enterprise who are genuinely interested in the architecture, interested in the end-2-end process and are in a position to have an influential impact on each service owner. In other words, it is the personality that seems to make a difference rather than the position in the organisation hierarchy.

Just my tuppence worth for today... Next up, I want to have a go at the Unix v Windows debate! Won't that be fun?

Why Joined Up Thinking...

...... because it seems to me that there is a distinct lack of "joined-up thinking" within the enterprise environment!

Business units work independently of one another and the glue that joins them together (ie. Technology) is too intent on hitting deadlines and coming in on budget to recognise their responsibility to actually act as a glue and.... join-up the business strategy.

Am I being harsh? From what I have seen in recent months/years, I don't believe so - to the extent that I have finally started a blog to record my thoughts on this particular subject.

I hope the postings will amuse you; stimulate you; strike a chord with you; but most of all... will help you avoid the same mistakes in the future.