[keycloak-dev] can we get away with federating user/cred only?

[Stian Thorgersen]

If we could create a plugin mechanism to add UI bits specific to a SPI providers that'd be great.

Haven't thought about this to much, but something like:

* Social providers can provide instructions for configuration
* Authenticator providers can provide they're own UI screens for configuring
* TOTP providers can provide configuration instructions for account mngtm and login screens
* ...

All it needs is that an SPI can return a html fragment, and some way of making the UI pluggable. This is definitively something I'd be keen on looking at if I could find the time. Or maybe, just maybe, this could be another reason to move to UberFire (including the need to integrate into WildFly console some day)?

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Wednesday, 29 January, 2014 2:56:08 PM
> Subject: Re: [keycloak-dev] can we get away with federating user/cred only?
> 
> interface AuthenticatorDelegate {
> 
>     boolean isAuthenticated(UserModel user, Credential... credentials)
> throws UnsupportedCredentialType;
> 
>     void updateCredential(UserModel user, Credential oldCred, Credential
> newcred) throws UnsupportedCredentialType;
> 
> }
> 
> 
> I was thinking we'd offer a Picketlink IDM API one.  THe admin console
> would allow you to upload a PL config file through this SPI interface:
> 
> interface AuthenticatorDelegateFactory {
> 
>     Set<String> getSupportedCredentialTypes();
>     AuthenticatorDelegate create(MediaType mediaType, byte[] configBytes);
> 
> }
> 
> Or, alternatively we could put a nice UI on top of PL to configure LDAP.
> 
> 
> 
> 
> 
> On 1/29/2014 8:51 AM, Stian Thorgersen wrote:
> > When it comes to enterprises I think having multiple options to best
> > integrate into whatever ecosystem they already have in place.
> >
> > With that in mind, when possible I think syncing to/from LDAP would be
> > great. Keycloak store would in most cases provide more information than
> > the LDAP store in those cases. For example role mappings.
> >
> > If we design a sync SPI that would allow users to do their own to integrate
> > with whatever they currently have. Be it LDAP, a relational database, or
> > any other solutions. The SPI could have a read only, as well as a
> > read/write option.
> >
> > Also I think it makes sense to add support auth brokering. Again through an
> > auth SPI. I imagine this would work by letting a realm use a different
> > source to validate credentials. A very crude auth SPI could look like:
> >
> >    public boolean isAuthenticated(String username, Credential...
> >    credentials) {
> >    }
> >
> > Some auth providers could only work for some credentials. For example an
> > LDAP could be used to verify the username/password, then Keycloak to
> > verify TOTP, while roles and other user profile data retrieve from the
> > Keycloak store.
> >
> > The same auth SPI could be used to add support for additional OTP
> > mechanisms (email, smtp, yubikey, you name it).
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Monday, 27 January, 2014 5:12:48 PM
> >> Subject: [keycloak-dev] can we get away with federating user/cred only?
> >>
> >> Can we get away with federating user and credentials only?  Only store
> >> those in LDAP/AD?  Would sure make our lives a lot easier and this may
> >> cover 80% of deployments that need it?
> >>
> >> --
> >> 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>