On 02/05/13 08:39, Stuart Douglas wrote:
> 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
The particular situation I was thinking of was the EL vulnerability we
had in Seam a few years ago (which I won't go into detail as this is a
public list). Essentially it allowed arbitrary code execution, meaning
that the beans of an application could be accessed and invoked directly
while bypassing the view layer altogether. I'm not so concerned about
malicious code in the application, I believe that's beyond the scope of
our responsibility here however I am concerned about developers that may
decide to expose the IdentityManager (as a @Named bean or otherwise)
without understanding the ramifications of doing so. Basically the
intent is to prevent them from shooting themselves in the foot, perhaps
I am being overcautious here but the motivation is to limit as much as
possible the number of attack vectors for compromising a
PicketLink-secured application.