[security-dev] Undertow / IdentityManager and Digest Authentication

[Bill Burke]

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