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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev