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(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)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(a)redhat.com>
>> To: keycloak-dev(a)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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com