UDDI , JES, and what, exactly?

Two questions: How does identity (ideally single sign on) work in Solaris (mainly 10)? We can't figure out which 3-10 pieces of Sun's JES we need to do single sign on. LDAP I get but what else do we need?

What the hell good is a UDDI server? I see it as roughly equivalent to a root DNS server (the world won't need a lot of them) but it seems to me you need to know most of what you'd get from it in order to find what you need (the web service you want) anyway.

Signed:

Over caffinated
in javaland

I'm confused too, and I've installed several versions of Sun's identity management stuff.

On the positive side, we can deal with the UDDI question fairly easily. Back in the late ninties there were people who thought there was money to be made making program widgets available for use across the web - use somebody's netbean, send them six cents, kind of thing. Naturally that needed a services directory and so UDDI (Universal Description, Discovery, and Integration) was born.

That died, of course, but a few years later Microsoft thought it was going to turn XML into "a programming language for the web" and UDDI got a bit of boost. That hasn't panned out either, so UDDI has more recently been touted for use in an identity management framework.

Sun adopted it early on because some of its Project liberty partners thought Microsoft meant it, and now UDDI forms a standard part of virtually every inter-operability suite out there. There are situations where the standard can be useful - if, for example, you wanted to implement a "services oriented architecture" (a buzz phrase continuing the generalization from Unix daemon to Microsoft server) the UDDI protocol can work well with basic identity management to point user PCs at the right sockets without further sign-on formalities.

Part one of your question is a lot harder to answer in large part because I find single sign on solutions inherently very confusing. Basically you have two choices with Solaris 10 - implement the most recent version of the traditional single sign-on within a community of trusted machines (including containers) or implement a single identity management scheme.

The former approach, now based on kerberous token passing between machines and an LDAP database, is the logical successor to the original Sun yellowpages (NIS/NIS+) solution. It's still clutzy (but at least it's not federated identity!) and it's still fairly easy to implement - just follow through the manual ( System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) or check bigadmin for a step by step guide that fits your environment.

If, however, you want a full blown identity management scheme that extends beyond your business walls to control transactions from outside, I think what you need is the Java identity management suite: Sun Java System Identity Manager, Sun Java System Access Manager, and Sun Java System Directory Server (Enterprise Edition).

I say "I think" because I've only used this stuff after loading the entire Sun Java Enterprise System - something I'd suggest you do too because it's a lot simpler and can be cheaper.

It's cheaper because Sun has an enterprise licensing deal that is so well defined it can mean almost anything your salesman wants it to.

It's simpler because the install process puts everything in "the right place," with the right ownerships and permissions according to the defaults assumed in the code - so you don't have to guess which file, which version name, which oddball permissions, or which unique file ownership expectations are causing your problems.