[security-dev] Undertow / IdentityManager and Digest Authentication

[Darran Lofthouse]

Thanks Shane,

That probably does cover what I need quite well then and for Digest at 
least I don't think we compromise your Credential protection.

I will try and mock up some form of Digest 'credential' and 
CredentialHandler that covers what I need for Undertow and SASL and then 
we can look at it again in a little more context.

Regards,
Darran Lofthouse.

On 01/05/13 09:57, Shane Bryzak wrote:
> On 01/05/13 17:03, Darran Lofthouse wrote:
>> The problem I see with this is that the CredentialHandler that gets
>> implemented has to take on the task of leaking the Credential, in this
>> case I think we should verify on the response message as that is
>> generated after the call to verify.
>>
>> Ideally the Credential I pass into the IDM needs to look similar to the
>> one I provided on the initial Undertow article - to be able to generate
>> a header to verify the integrity of the message (or even to properly
>> implement {SLG}-sess) I need the appropriate hashed value.
>>
>> Alternatively I may have one additional option for me but I don't think
>> it covers Bill's scenario (Also I think other projects may be missing
>> from the discussion such as JBossWS although they probably would require
>> the same as Bill).
>>
>> One thing I may be able to do in a CredentialHandler is create the
>> appropriate MessageDigest instance and push the pre-prepared digest
>> straight into it - this MessageDigest could then be passed to the
>> Credential being verified - the calling code could then have access to
>> the MessageDigest.  That way the calling code would have what it needs
>> without actually being exposed to the stored Credential.
>
> This is definitely how I would recommend implementing this scenario.
> The Credentials object that is passed into CredentialHandler.validate()
> is a great place to pass state back and forth between the
> CredentialHandler and the caller.
>
>>
>> This way the HTTP specific portion of verification can still live
>> outside the IDM which I believe is still the correct location for it.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 30/04/13 21:54, Shane Bryzak wrote:
>>> There's two options here; the first one is to store the private key as
>>> an attribute which then makes it a piece of cake to retrieve the value:
>>>
>>> Attribute<PrivateKey> attrib = user.<PrivateKey>getAttribute("mysecret");
>>> PrivateKey key = attrib.getValue();
>>>
>>> The other option is to implement your own CredentialHandler as mentioned
>>> previously.  The design decision to insulate the actual credential
>>> values from the API was intentional, and at the moment the only time
>>> they are exposed to the API is when they are created for the very first
>>> time.  With there seemingly being a major password hack on the news
>>> every week it is in our best interest to reduce the number of attack
>>> vectors that make this kind of thing possible, hence the decoupled
>>> design.  Also, I don't consider writing your own CredentialHandler
>>> implementation a hack, in fact we have a quickstart for it as it is
>>> something we expect many of our developers to have to do themselves.
>>>
>>>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>