On 5/1/2013 7:26 PM, Anil Saldhana wrote:
On May 1, 2013, at 5:54 PM, Bill Burke <bburke(a)redhat.com> wrote:
>
>
> On 5/1/2013 6:39 PM, Stuart Douglas wrote:
>>
>> 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?
>
> I'll give you another one: What does IdentityManager.updateCredential()
> do? Does it allow you to update a password? If so, you're saying that
> its ok to change a password, but not read it from the store?
>
Applications cannot and should not read the password from the store via the
IdentityManager API.
And yet you do this indirectly through a handler to implement Http Digest.
In the case of ldap store, the ldap store does cred operations. IDM
does not have access to the cred read from the store.
Then in this case, the read of the credential would fail. If a protocol
required raw access to the credential (i.e. Digest, Amazon S3, even
OAuth1), it would not be able to work with the LDAP store.
In the case of databases, such facilities does not exist- for this
reason, we have an spi which normal applications do not care. Only in advanced cases such
as yours, do we need to deal with credential handler constructs.
The Advanced cases are already the norm and being demanded by users.
going to become the norm because the current "normal" JBoss applications
are screaming for the advanced cases...
As Stuart said, unless the JVM is running with a Java Security
Manager, it is a Wild West. There is no real security in terms of trusted/untrusted code.
Maybe you should read all of Stuart's response instead of just the small
part that validates your argument?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com