Hash: SHA1

Is WebSphere smart enough to take multiple servers as authentication
sources or do you really need something in between to handle that
limitation in it (justifying the use of a load balancer with a VIP)? If
WebSphere cannot handle that situation and you need the load balancer
then will that load balancer be accepting the SSLized connections and
decrypting them, or will it do nothing more than layer three passing of
data to one machine or another? Do you need to handle "stickiness" to
one node or another or will WebSphere be reconnecting with a fresh
connection for every single request with no assumption about hitting the
same box or not? I assume you know how to make WebSphere accept any
given certificate since it's just a Java app like any other web
application server.

Depending on answers to the questions above there are a couple ways to
go about this.

First, the nicest way (in my opinion) is for the web application server
to know about multiple servers since it can then send requests to one
node or another depending on what happened before. This is the type of
thing that Novell/NetIQ Access Manager does with clients for similar
reasons; sessions persisted on a server need to be available by the
client over and over, and changing web servers with every connection
breaks that without special handling. This is not at all what you asked
about, though, so I'll assume WebSphere cannot do this and so you're
stuck working around it.

Second, if the load balancer is going to do the decryption then things
are a lot easier from the eDirectory side since you basically no longer
need to worry about SSL there, or else any handling you do there will be
without WebSphere knowing. This is nice because the load balancer could
understand stickiness of sessions easily since it actually sees things
on the wire. This may require a nicer (more expensive) load balancer
though. You could use any old certificate, including a third-party
certificate, for the load balancer since eDirectory really wouldn't
know/care about the original source of the requests.

Third, if the load balancer is merely going to forward traffic on
through and pay no attention other than to balance the load by some
algorithm, then the biggest consideration is probably creating an SSL
certificate for use by both/all eDirectory LDAP interfaces which has the
DNS name of the load balancer specifically int he subject line. To the
client, WebSphere in this case, the SSL certificate presented must be
trusted (you get to do that with WebSphere documentation I presume) and
must be valid (expiration, subject line, etc.) and since WebSphere sees
the client as loadbalancer.yoursite.tld the certificates actually served
up by all of the servers must be the one that has a subject line of
loadbalancer.yoursite.tld and that should be just fine.

On a random note, I do not know if LDAP Proxy is a valid tool for this,
but if so it may make life a little nicer:


Good luck.
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

eML3uDWmOmgT0a3BbS2VE8VVCRf0sHRnYMDljLB+grhNGc4+ns oF66nNjqh/kXmZ
HCWkUf9L9xzd9vwRC+g4qrx78tWsmyasugiqHSwle+jFsq4qfb 7tWMujC/bsHiut
BHBlnCwV5uw9lsPGbtY5v26ApCxA3WvJk3eats7dVa+NzTUJre oDXrZYPtK9JYMv
eR2g0bAQTSDwboyzLm7h0r3EiIP0IIYWMd9FE75pddbKl8mFXQ 5pd849JWcHJALj
i9SS8IBJQp/4xO5WMJI8bN2B0zkys8dsqhobMbwzlRPxLe8cp4+o3hFtByaKc z7W