[security-dev] Undertow / IdentityManager and Digest Authentication

[Bill Burke]

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