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

[Scott Rossillo]

Is this a reasonable time to consider how impersonation could fit into the auth SPI?


> On May 11, 2015, at 9:29 AM, Bill Burke <bburke at redhat.com> wrote:
> 
> 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.
> 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!
> 
> 
> 
> 
> 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