[security-dev] Undertow / IdentityManager and Digest Authentication
sbryzak at redhat.com
Thu May 2 23:53:16 EDT 2013
We take a hybrid approach to authentication, at least in terms of
backend identity stores. As a feature of PicketLink IDM, authentication
itself is a first class citizen, however you're right about the
challenges in regards to hundreds of authentication schemes and so our
design has had to adopt an abstract approach to supporting (or at least
making it possible to support) such a large variety of authentication
technologies. In the case of all authentication requests we delegate
the request to the underlying identity store first and foremost. What
happens from there depends on the particular implementation details,
however it may be helpful if I describe a couple of the authentication
scenarios that we currently support, and the SPIs provided by PicketLink
to enable them.
Let's start with LDAP - as we all know it provides an authentication
mechanism itself, which is simply to bind to the directory using the
provided credentials. The sequence of events is as follows:
LDAPIdentityStore.validateCredentials() -> lookup CredentialHandler
implementation for the provided credential ->
LDAPPlainTextPasswordCredentialHandler.validate() -> perform bind
operation on LDAP server with provided credentials -> return result to
LDAPIdentityStore -> return result to IdentityManager
Arguably we could do away with LDAPPlainTextPasswordCredentialHandler
and just implement the authentication logic in LDAPIdentityStore itself,
since there are no other credential types supported by LDAP. This is a
good example though of just how customizable authentication is - the
LDAPIdentityStore.validateCredentials() implementation is not forced to
use the CredentialHandler SPI, it is free to do a straight delegation
and pass-through the authentication request to the backend identity
store. In fact this is exactly what we'd do if we were to implement an
IdentityStore to support Kerberos or other such authentication protocol.
Another example we have is FileBasedIdentityStore. This is a file-based
identity store implementation that as the name suggests persists
identity state to the file system. Unlike LDAP, it doesn't provide a
native authentication function and so any authentication logic must be
defined by PicketLink. Here's the sequence of events when
authenticating with a username and password, and the passwords are
stored as salted hash values:
FileBasedIdentityStore.validateCredentials() -> lookup CredentialHandler
implementation for username/password credentials ->
PasswordCredentialHandler.validate() -> cast FileBasedIdentityStore as
CredentialStore -> CredentialStore.retrieveCurrentCredential() ->
compare stored hash value with hash calculated from provided password ->
return result to FileBasedIdentityStore -> return result to IdentityManager
As you may be able to tell from this sequence of events,
FileBasedIdentityStore also implements the optional interface
CredentialStore (JPAIdentityStore also implements this interface too)
which allows access to the underlying raw credential values, in this
example the password hash and salt values. This allows us to reuse
CredentialHandler implementations - as long as the configured
IdentityStore supports the CredentialStore interface then it will be
supported by PasswordCredentialHandler.
The combination of delegating authentication to the IdentityStore
implementation, providing an optional CredentialHandler SPI, and
allowing identity stores to expose their credential values (where
available) via the CredentialStore interface means that we can
effectively support a wide spectrum of authentication technologies,
whether provided natively by the identity backend or defined by
On top of this, with the latest changes wrangled out of the discussion
between mainly Bill and myself the stored credential state (where
supported) will also be available for additional operations, such as
response signing, etc.
Hope this helps to clarify things.
On 03/05/13 11:47, 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.
> 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.
More information about the security-dev