[security-dev] Undertow / IdentityManager and Digest Authentication

Stuart Douglas sdouglas at redhat.com
Wed May 1 18:39:59 EDT 2013


> It's not a farce at all, CredentialHandler implementations are
> *trusted*.  Opening up credential storage for everything to be read via
> the IdentityManager API in my opinion is greatly irresponsible.

I don't really buy this argument. You basically have two different 
scenarios:

1) Trusted code, no security manager: In this case you are confident 
that all the code in your app server is not malicious.

In this case if you have the identity manager handing out credentials 
the only way that it will leak is via programming error (e.g. the writer 
of a login mechanism decides it would be a good idea to log the 
credential being used). The thing is though that this can happen even 
with the CredentialHandler based design, it does not protect you from 
accidental credential leakage on the behalf of the mechanism authors.

If you ever have any malicious code end up in your app server it will be 
able to get the credentials anyway, by simply registering a handler or 
using reflection. With no security manager your whole app server is 
compromised.

2) Not fully trusted code with security manager: In this case you have 
to rely on your security manager and appropriate permission checks in 
the code that returns the credentials. Basically it is up to the user to 
configure appropriate security manager permission (and up to us to make 
sure we have appropriate permission checks in place).

Even though not handing out the credentials directly may feel more 
secure, I don't think it actually is, unless you have a scenario that is 
not covered above?

Stuart



>
>> So, basically, we're going to have to write protocol-specific Credential
>> and CredentialHandlers, correct?  How will this look at deployment time?
>>     At runtime?  Who registers the Handlers and the Credential->Handler
>> mapping?  The IDM Subsystem config?  The domain config?  The web-app
>> config?  All the above have an effect on class loader boundaries and the
>> set up and configuration of class Modules and class loader visibility.
>>
>>
>
> There's essentially two use cases that we need to support; the first one
> is configuration of credential handlers at the IDM subsystem level, the
> second is configuration at application deployment time. Obviously an
> application-specific CredentialHandler will only be valid for as long as
> the application is deployed.  We most likely need to implement some
> protection for class loader boundaries as you mentioned, but it's early
> days still for the IDM subsystem so these tweaks are to be expected.
> The main thing for now is that we understand the use cases, which I
> believe we already have covered.
>
> What our disagreement boils down to is whether or not we should be
> exposing the raw/secret credential values via the IdentityManager API.
> We could continue going back and forth with essentially the same
> arguments but so far neither of us seem to be swayed one way or the
> other - what I'd like is to hear some opinions from some other people.
> Should we or should we not be making user credentials queryable?
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev


More information about the security-dev mailing list