11:12 a.m.
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
7:51 a.m.
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
8:56 a.m.
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
3:20 a.m.
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
3749
days inactive
3752
days old
3 comments
2 participants
participants (2)
-
Bill Burke -
Stian Thorgersen