[security-dev] Undertow / IdentityManager and Digest Authentication

[Boleslaw Dawidowicz]

In some cases there is no other choice. I'm not in disagreement with you here.

On May 6, 2013, at 4:01 PM, Bill Burke <bburke at redhat.com> wrote:

> How do you think users will want to protect credentials like TOTP secrets?  Thats something that will require raw access.
> 
> On 5/6/2013 9:40 AM, Boleslaw Dawidowicz wrote:
>> Right. I should have been more clear about this part. Obviously It can still be encoded. Still may not be enough for some more concerned or with specific requirements. Just pointing potential issues.
>> 
>> On May 6, 2013, at 3:36 PM, Bill Burke <bburke at redhat.com> wrote:
>> 
>>> Just because a protocol requires access to the raw credential  doesn't
>>> mean you have to store it in plain text.
>>> 
>>> On 5/5/2013 11:08 AM, Boleslaw Dawidowicz wrote:
>>>> If you decide to store passwords in plain text in DB I think you can expect users/customers complaining and I'm sure some projects and deployments will have requirements to not do so. I witnessed both scenarios. Some people have very tough integration challenges and really need to retrieve credentials. For some it is simply no go. In such cases it doesn't matter if it is a real security or just fake perception - my favorite case proving it is password masking. In portal we still keep configuration switch for it. You may need to support both scenarios.
>>>> 
>>>> I lack insight into digest scenario. However to be honest as a user I prefer when systems are not storing my credentials in plain format anywhere. Even if I know that in many cases it doesn't necessarily make them more secure.
>>>> 
>>>> Not saying that we shouldn't do it for this particular case. Still it may hit us back later.
>>>> 
>>>> On May 2, 2013, at 2:33 AM, Shane Bryzak <sbryzak at redhat.com> wrote:
>>>> 
>>>>> Bill, I'm going to concede defeat on this one, so congrats on a
>>>>> well-fought victory ;)  The one saving grace with the IdentityManager is
>>>>> that in an EE environment it is actually wrapped by a
>>>>> SecuredIdentityManager, which allows for permission checks to be defined
>>>>> for every single IDM operation.  With this in mind, it should be trivial
>>>>> to implement a permission check for credential retrieval that restricts
>>>>> it to only allow the reading of credentials for the currently
>>>>> authenticated user (or whatever other permission logic the developer wants).
>>>>> 
>>>>> So, with that in mind I propose the following additional methods for
>>>>> IdentityManager:
>>>>> 
>>>>>     <T extends CredentialStorage> T retrieveCurrentCredential(Agent
>>>>> agent, Class<T> storageClass);
>>>>>     <T extends CredentialStorage> List<T> retrieveCredentials(Agent
>>>>> agent, Class<T> storageClass);
>>>>> 
>>>>> These will essentially delegate to the underlying CredentialStore, and
>>>>> if there is none (which will be the case in an LDAP-only configuration)
>>>>> you'll get an OperationNotSupportedException.
>>>>> 
>>>>> Will this be sufficient for your requirements?
>>>>> 
>>>>> Shane
>>>>> _______________________________________________
>>>>> 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
>>> 
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com