[security-dev] Undertow / IdentityManager and Digest Authentication
pmuir at redhat.com
Tue Apr 30 09:22:34 EDT 2013
PicketLink IDM has no dependencies, it's just two jars - -api and -impl.
On 30 Apr 2013, at 14:21, Bill Burke <bburke at redhat.com> wrote:
> Disregard my previous email. After looking at your linked code Shane,
> and reviewing the email thread I had with you guys awhile back, I
> realize why you have what you have. Thanks for your patience!
> BTW, maybe Undertow should reconsider using Picketlink IDM API directly.
> You might end up implementing the same thing and that would be a
> shame. Don't you think Picketlink could be refactored enough to reduce
> On 4/30/2013 8:58 AM, Shane Bryzak wrote:
>> What PicketLink stores for digests is the latter  (in no situation do
>> we ever store plain text passwords). There are essentially two methods
>> for validating and managing credentials in the IdentityManager 
>> (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  to the
>> IdentityManager.validateCredentials() method, which is essentially a
>> wrapper around a Digest  (which should look quite familiar). The
>> actual implementation of the validation logic can be found in
>> DigestCredentialHandler .
>> 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.
>>> 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.
>>>> 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
>>>>> 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: -
>>>>> 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.
>>>>> Darran Lofthouse.
>>>>> security-dev mailing list
>>>>> security-dev at lists.jboss.org
>>>> security-dev mailing list
>>>> security-dev at lists.jboss.org
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>> security-dev mailing list
>> security-dev at lists.jboss.org
> Bill Burke
> JBoss, a division of Red Hat
> security-dev mailing list
> security-dev at lists.jboss.org
More information about the security-dev