[security-dev] Undertow / IdentityManager and Digest Authentication

Shane Bryzak sbryzak at redhat.com
Tue Apr 30 08:58:57 EDT 2013

What PicketLink stores for digests is the latter [1] (in no situation do 
we ever store plain text passwords).  There are essentially two methods 
for validating and managing credentials in the IdentityManager [2] 
(three if you count one extra overloaded method):

void validateCredentials(Credentials credentials);
void updateCredential(Agent agent, Object credential);

There is no API method for retrieving an actual credential value so by 
design credential storage is quite secure.

To briefly summarise how things work for a digest authentication in 
PicketLink; we would pass in an instance of DigestCredentials [3] to the 
IdentityManager.validateCredentials() method, which is essentially a 
wrapper around a Digest [4] (which should look quite familiar).  The 
actual implementation of the validation logic can be found in 
DigestCredentialHandler [5].



On 30/04/13 22:26, Darran Lofthouse wrote:
> As there is going to be an integration layer between Undertow and
> PicketLink IDM I think the main requirement for PicketLink IDM is going
> to be: -
>    - Where PLIDM has access to plain text passwords for a specified
> account and using the specified digest algorithm generate the digest for
> the username, realm and password separated by colons.
>    - Where PLIDM is storing pre-prepared digests for a specified account
> look up the pre-prepared username, realm, password digest for the
> algorithm specified.
> This latter option relates to something I brought up a while ago where a
> single credential could be associated with an account in a number of
> different formats - what this means is that the Digest algorithms can
> potentially go beyond MD5 to use stronger digest algorithms.
> The pre-prepared digests do offer some protection but PLIDM would still
> be responsible for storing them securely to provide protection against
> accidental disclosure.  The most important thing however is that we do
> not need the plain text passwords to be passed onto the Undertow or SASL
> classes handling the actual authentication.
> Regards,
> Darran Lofthouse.
> On 30/04/13 12:56, Shane Bryzak wrote:
>> Looks pretty straight forward - what do you need from the PicketLink
>> side for this?  The PLIDM implementation should be quite simple, I can
>> help out with it if required.
>> Shane
>> On 30/04/13 19:24, Darran Lofthouse wrote:
>>> I have been saying for a while that I need to raise a discussion
>>> regarding the verification of Digest based requests against an
>>> IdentityManager.
>>> At the moment this is predominantly needed for Undertow although there
>>> is also a need for same with SASL.
>>> The following document describes the proposed use of the Undertow
>>> IdentityManager API and the requirement for the implementation i.e. what
>>> we would need from PicketLink IDM once wrapped in the WildFly integration: -
>>> https://community.jboss.org/wiki/Undertow-IdentityManager-DigestAuthentication
>>> The three methods on the IdentityManager interface previously used for
>>> Digest based authentication will all be removed.
>>> An identity manager that can provide this capability will also be
>>> compatible with SASL based authentication without needing to be aware of
>>> the actual verification requirements within SASL.
>>> Regards,
>>> Darran Lofthouse.
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20130430/3920076d/attachment.html 

More information about the security-dev mailing list