On 4/30/2013 4:54 PM, Shane Bryzak wrote:
There's two options here; the first one is to store the private
key as
an attribute which then makes it a piece of cake to retrieve the value:
Attribute<PrivateKey> attrib =
user.<PrivateKey>getAttribute("mysecret");
PrivateKey key = attrib.getValue();
The other option is to implement your own CredentialHandler as mentioned
previously. The design decision to insulate the actual credential
values from the API was intentional, and at the moment the only time
they are exposed to the API is when they are created for the very first
time. With there seemingly being a major password hack on the news
every week it is in our best interest to reduce the number of attack
vectors that make this kind of thing possible, hence the decoupled
design.
Think about what you're saying here.... The credential isn't protected
at all because the code that is invoking the validation already has the
credential. Its just not verified. For two-way SSL its even more
pointless because you're validating the client with public certificates.
There's also certain credentials, i.e. a TOTP secret key, in which the
credential can't be stored as a hash. So, isn't it possible for a
malicious programmer to register a malicious Handler so they can get
access to whatever information they want?
I guess I'm back to suggesting that anything should be queryable that's
stored in the IDM. I do remember your chained IDM usecase, maybe
instead of a validation() API a visitor API would be better?
public interface IDM {
void accept(IdmVisitor visitor);
}
public interface IdmVisitor {
void visit(SecurityContext context, IdentityStore store);
}
Then somebody could still do whatever they wanted and be aware of the
chaining. Credential validation fits into the visitor pattern as well.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com