Sun versus IBM Identity Management

Stuart Jansen sjansen at
Mon Feb 14 21:26:28 MST 2005

On Mon, 2005-02-14 at 15:48 -0700, Erik R. Jensen wrote:
> The company I work for is in the process of finding an identity management
> solution that suits our needs. It has come down to two options. Option #1
> is to go with IBM, using their IBM Directory Server, Tivoli Access
> Manager, Tivoli Identity Manager. Option #2 is to go with Sun using Sun
> Directory Enterprise Server, Identity Manager and Access Manager. Either
> direction, we will probably deploy on Linux and I expect the costs to
> exceed 500k.
> We are primarily an IBM shop and need the identity management solution to
> tie in with Oracle Apps, Oracle HR, WebSphere Portal, WebSphere Commerce,
> Lotus Domino, Active Directory, NT Domains, AS/400 authentication and
> provide as much single sign on as possible for the large number of
> applications we run on our WAN.

I don't have experience over the same range, but perhaps I can add
something useful. I helped to implement and maintain an upgrade to the
identity/access management of intranet Web applications for ~30,000
users. (Read: RY for BYU.)

Try to stick to only centralizing identity. User ID, name, roles, etc.
Unless absolutely impossible, use the actual application to control
access. Doing otherwise, in my experience, leads to fragile, in-bred
rules and reduced security. In other words, create classes like "active
employee" and "consultant", then have the application respond to those
classes instead of using an access manager.

Hopefully the rest of what I have to say isn't news:
* All vendors are liars.
* Don't forget to think about how updates will be handled.
Unfortunately, the product we used required upgrades approximately every
6 months. We weren't able to handle that well. Adding insult to injury,
the only good reason to upgrade (other than ensuring we were using a
"supported" version) seemed to be the opportunity to take advantage of
new bugs.
* Three years from now, are you likely to decide to switch to a
different vendor? What decisions are you making now that will make that
impossible in the future?
* Why do you want SSO? It isn't always appropriate. For example, BYU
eventually realized that POP passwords (plaintext) should not be the
same as the password used to change employee direct deposit information.
* All vendors are liars.

Stuart Jansen       sjansen at       aim:StuartMJansen
A: No.
Q: Should I include quotations after my reply?
  see also:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : 

More information about the PLUG mailing list