[security-dev] Undertow / IdentityManager and Digest Authentication

[Shane Bryzak]

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:

IdentityManager.validateCredentials() -> 
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:

IdentityManager.validateCredentials() -> 
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 
application logic.

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.
>
>