12:23 p.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)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.).
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!).
On 10/13/2014 3:23 AM, Stian Thorgersen wrote:
> We should consider adding an Authentication SPI. This would be something
> similar to what we used to have, but should be more flexible (for example
> allow redirect to other IdPs).
>
> This could be used for:
>
> * Kerberos bridge
> * Authenticate with external IdP (SAML or OpenID Connect)
> * Add custom authentication providers
> * Additional authentication mechanisms (fingerprint, hardware keys, etc.)
>
> Same SPI could also be used for custom multi-factor authenticators. As well
> as for authenticating non-human users (cert, jwt, etc.).
>
> A realm should be able to have more than one authentication mechanism. For
> example by default users authenticate with username/password (through the
> user store), but all users with a specific email domain authenticate with
> an external IdP. At the same time a user could have one or more main
> authenticators (password, hardware devices, etc.) and one or more
> secondary authenticators (totp, hardware token, etc.).
>
> Certainly needs a lot more thinking/design, but if it's something we're
> interested in I'd like to look at it.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev