On 5/2/2013 9:47 PM, David M. Lloyd wrote:
Throwing fuel on this, though I ought to know better.
I think there is an important distinction here between an identity store
which also happens to hold credentials, and an authentication system
like PAM or JAAS which has the ability to *verify* credentials. I've
seen PicketLink IDM described in this thread in both ways.
Do you (the security team) have a clear idea which direction you are
trying to move in? If you're working towards a full authentication
system, be warned that you're biting off a really major chunk of
technology - even PAM (which is arguably one of the most widespread
authentication mechanisms around, and is part of the X/Open SSO
standard) cannot directly support Kerberos (!) due to API limitations
for example. You cannot plausibly pursue this path without
understanding just about every authentication scheme in existence, which
is clearly not yet the case judging from the content of this thread.
There are *hundreds* of schemes that would have to be considered to
design a meaningful API that was substantially better than what JAAS
already offers.
If you're going for a pure identity store, I'd say you're taking on a
much more realistic burden, but you must be ready to accept that while
authentication systems like JAAS (or PAM) can talk *to* the identity
store using custom modules, the identity store could never realistically
be used as the frontend to something like PAM or other external
authentication systems which do not give full access to credentials.
What you'll be making is simply a strongly-typed API to a database,
usable only as a backend to actual authentication systems like JAAS and
protocols like SASL, FTP, HTTP, SSH, etc.
I don't think its so black and white. No reason Picketlink can't offer
both a credential verification API as well as a credential lookup API.
If your protocol requires access to the secret and the underlying
identity store can't provide it, then you can't use that protocol with
that identity store. Simple as that...
For more complex thirdparty integration situations, IMO, you're just
better off doing the integration directly. As we've seen with JAAS, any
generic authentication API can make your life really difficult.
Seems to me like you guys have to accept one or the other path, and
stick with it. Don't try to be an identity store that looks and acts
somewhat like an authentication system or else you're just going to end
up with awkward API constructs and half-baked concepts. Separate your
concerns clearly: the IDM is the IDM, the authentication system is the
authentication system.
+1. Start refactoring IDM into a set of optional building blocks.
Maybe a good first step would be to move the validation() apis within
IDM interface into a separate credential validation service interface?
IMO, you also really need to start thinking about how you want to
configure things. Otherwise, Picketlink isn't going to be very useful
and 3.0 isn't going to be usable.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com