[keycloak-dev] auth spi design requirements and initial steps

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 11 May, 2015 3:29:13 PM
> Subject: [keycloak-dev] auth spi design requirements and initial steps
> 
> Some generic requirements that will effect the design.
> 
> 1. Authenticator should be able to be optional per user. i.e. OTP can be
> optionally set up by the user
> 2. Multiple authenticators should be resolvable per form. i.e. password,
> terms and conditions, captcha, and otp could be entered in on one page.
> 3. Non form based authenticators should be able to bypass any screens if
> they are the only authenticators. i.e. CLIENT_CERT and KERBEROS.
> 4. Autheticators need to be able to send challenges after initial
> request, i.e. Kerberos
> 5. Clients should be able to specify which Authenticators they require
> 6. You should be able to attach policies to an Authenticator which
> allows you to do things like, don't do OTP if you are coming from IP
> address where you last logged in.

Bypassing OTP shouldn't be based on IP. Instead when you do OTP there should be an option to not ask for OTP next time, which sets a cookie. Reasoning behind this is:

1. It's how Google does it ;)
2. IP address for most users are dynamic, and also often shared
3. User should choose not to use OTP next time. This is important as user could be login from a public machine, a friends machine, etc.

> 7. Authenticators should be able to plugin in a JAX-RS service that can
> handle requests for them.
> 8. Authenticators should be able to specify their display/input page
> 9. Authenticators can have a "user setup" pages.  One for
> login/registration, one for account service, and one for admin console.
>   Yuck!

Other things:

* Password-less authentication mechanisms (finger scanners, etc.)
* Other multi-factor mechanisms (FIDO, SMS, email)
* Multiple multi-factor mechanisms for one account (for Red Hat I've got both Google Authenticator and dongle, I use both day to day, but it's also nice to have a backup)
* "Detached" flows - for example verify email sends an email with a link, login with email would send a login link, etc..

> 
> 
> 
> 
> Design implications:
> * I think we need to have a AuthenticatorForm as well as an
> Authenticator interface.
> * Authenticators would be associated with a AuthenticatorForm.  This
> allows support for multiple Authenticators for one form post.
> * AuthentictorForms would have an action URL that accepts form input.
> This form input URL would be referenced by the form name
> /auth/realms/{realm}/authenticate/forms/{form-name}
> * AuthenticatorForms would have a name and input/display page.  The
> display page URI can be a relative uri pointing to a theme template, a
> relative uri that points to an Authenticators JAX-RS service, or an
> external URI.
> * A User, per authenticator can be in a SETUP_REQUIRED state.  This
> allows the user to bypass the authenticator and go straight to
> authenticator setup.
> * CredentialModel will need generic attributes.
> 
> Steps?
> 
> I'm gonna get some abstraction working first with Kerberos, OTP, and
> Password.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>