[keycloak-dev] Authentication SPI

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 13 October, 2014 7:33:53 PM
> Subject: Re: [keycloak-dev] Authentication SPI
> 
> 
> 
> On 10/13/2014 1:23 PM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 13 October, 2014 4:37:34 PM
> >> Subject: Re: [keycloak-dev] Authentication SPI
> >>
> >> We should discuss whether we need to reshuffle our prioritization.
> >> Also, personally, I don't want to be stuck with all the integration work
> >> we have to do with Tomcat, Jetty, BRMS, etc. :)
> >
> > Fair enough, I reckon one adapter each this time around then let's take a
> > break? Highest priority should be what's needed for xPaaS I think (so
> > UberFire, BMRS, Fuse, Fuse Fabric, etc.).
> >
> 
> Tomcat needs to be in there too.
> 
> > I was still going to do adapter(s), but look at design/architecture for
> > this at the same time. I reckon a properly designed Authenticator SPI
> > could let us do federation (openid connect, saml, kerberos, etc.),
> > password-less logins (fingerprint) and more multi-factor (sms, email,
> > hardware tokens). It should also allow us to be future proof whenever
> > there's new authentication mechanisms (for example why can't a browser
> > prove your identity? that could give you sso to everything web!).
> >
> 
> Not sure they all fall under the same SPI.  You got authentication via
> user input (passwords, OTP), identity brokering (SAML, OIDC, Social
> login, kerberos), authentication via non-user-input (kerberos,
> cert-auth, our auth cookie).

I agree, I'm not sure if it's best to design it as one SPI with a lot of "options" or as multiple more bespoke SPIs.

> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>