8:51 a.m.
On 12/6/2012 8:32 AM, Darran Lofthouse wrote:
> The main idea is decouple from the IDM the logic to store,
load and validate credentials. That should be done by some client API like PicketLink
Core, PicketBox or some other authentication API. The IDM can provide some built-in
implementations for PasswordCredentialHandler or X509CertificateCredentialHandler, for
example.
>
> Another possible benefit is that the IDM does not need to know about how
credentials/handlers are configured.
>
> The handler can just use the IdentityManager to store the credentials, using
user's attributes or something like that.
>
> Let's say we want to perform a username/password authentication:
>
> Client Code
>
> UsernamePasswordCredential credential = new
UsernamePasswordCredential("username","passwd");
> PasswordCredentialHandler credentialHandler = new
PasswordCredentialHandler(credential);
>
> if (identityManager.validateCredential(credentialHandler)) {
> User user = identityManager.getUser(credential.getUsername);
>
> // continue with the authentication
> } else {
> // handle bad user
> }
>
> Now, let's say we want some some authentication that requires several
steps (otp authentication using username + password + token):
>
> OTPCredential credential = new OTPCredential("username",
"passwd"); // the user can also provide the token. no challenge.
> OTPCredentialHandler credentialHandler = new
OTPCredentialHandler(credential);
>
> if (identityManager.validateCredential(credentialHandler)) {
> // valid user, token was already provided by the user
> } else if
(credentialHandler.getStatus().equals(OTPCredentialHandler.TOKEN_CHALLENGE)) {
> // tell the user that we also need the token to perform the
authenticatin
> } else {
> // handle bad user
> }
>
> Makes sense ?
I like this, for the scenarios I have mentioned where additional
processing is required beyond just authentication the supplied
CredentialHandler can now be involved.
CredentialHandlers will require access to sensitive attributes of a user
but we also have the ability here to detect that it is within the
"identityManager.validateCredential" call to only allow at that point.
First off, I think User should be a parameter to your validate() method.
Second, I think this idea was floated around previously (months ago). I
liked the idea of a typed interface for credential handling, and the
separaation of concerns, but now that I'm actually prototyping an
REST-based IDP, I'm having second thoughts about a typed interface. In
my prototype, the IDP may dynanmically generate a login.html form based
on the credential types required by the realm. It doesn't know whether
or not the credential type is a password, OTP, mother's maiden name, or
whatever, it just needs to know to ask the user for a bunch of inputs.
Same thing goes with validation. Client-cert only validation adds an
addtional complication as the IDP wouldn't even need to display a login
form.
I think it should be something more like this:
public interface CredentialType implements Serializable {
CredentialHandler getHandler(User user, IdentityManager manager);
}
public interface CredentialHandler {
boolean validate(User user, Object[] credentials, IdentityManager idm);
}
public interface IdentityManager {
CredentialType[] getCredentialTypes(User user);
}
The above gives the consumer of this IdentityManager API a lot of
flexibility. The IDM API library would still provide a core set of
CredentialHandler implementations and a default implementations for
various CredentialTypes, but a consumer could easily provide extensions
that stored additional metadata. For example
public interface FormCredentialType {
String getDescription(Locale locale);
String getFormInputLable(Locale locale);
String getFormInputVariableName();
String getFormInputType();
String getFormInputSize();
}
public class PasswordFormCredential extends PasswordCredentialType
implements FormCredentialType {
...implmentation of FormCredentialType
}
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com