[keycloak-dev] How would you handle an external user store?

[Bill Burke]

On 7/9/2014 3:02 AM, Marek Posolda wrote:
>> UserProvider.verifyCredentials(User user, Credentials... credentials)
> AFAIR many SSO servers like CAS allow easy way for users to plug their
> authentication mechanism. If only way to do this in Keycloak is to
> implement whole UserProvider interface, it looks a bit like overhead to
> me. For authentication purposes only, people need just to implement
> "getUserByUsername" and eventually "getUserByEmail", but for example
> they don't need "getUserById"or "getUserBytAttribute"

Provide a base class like UserProviderDelegate.  Default implementation 
delegates to local UserProvider storage for each UserProvider method. 
Our default LDAP impl overrides getUserByUsername, getUserByEmail, and 
verifyCredentials.  addUser() would eventually be overriden to work with 
the Sync API.


>>
>> If LDAP only verifies password, then do an LDAP query, otherwise
>> delegate to the local UserProvider.
>>
>> If the local User is modified, then wouldn't it be prudent for the
>> LDAPUserProvider to wrap return User instances so that it could
>> register sync events?  Sync events that would trigger the update to
>> get back to the LDAP server eventually?
>>
>> IMO, UserProvider is the *perfect* place to implement a Sync API. Out
>> of the box, we would have an LDAPUserProvider which you could
>> configure in the admin console.  i.e. specify connection parameters
>> and attribute mappings.  Anything beyond that common use case would
>> have to be written by the user.
> I agree that UserProvider is good place to call authentication or
> register sync events. Just not sure if it's good to mandate people to
> implement whole UserProvider interface if they want just subset of it
> (like only authentication related methods)...

Picketlink IDM API separates credential storage and security metamodel. 
  AuthenticationProvider mixes these concerns.  From reading our user 
list, it seems that users want to delegate user+credential storage.  I 
didn't see any questions regarding just credential storage.

AuthenticationProvider also doesn't provide a means for Keycloak to 
manage LDAP users.  The user actually has to log in once before Keycloak 
can manage that user.

>>
>>> As I said LDAPUserProvider doesn't make much sense to me, so it's not
>>> needed to configure in 2 places. AFAIK in next KC version, the plan for
>>> stuff like SMTP and LDAP is to remove it from realm configuration and
>>> move it to keycloak-server.json . And also the possibility to configure
>>> stuff from keycloak-server.json in admin console UI.
>>>
>>
>> If you move LDAP config to keycloak-server.json then you remove the
>> notion of Keycloak being able to have multiple and distinct realms.
>> Same goes with SMTP.  You might want to use different email/password
>> for email login for different realms.
>>
> I think the plan here is to have something like "datasources" .
> Basically you can have configurations like "LDAPConfig1" or
> "SMTPConfig1" at keycloak-server.json level and then each realm can
> point just to this name. This will allow that 2 realms can share same
> SMTP/LDAP configuration without repeating stuff, but also it will still
> be possibility to use different configuration by each realm if they want
> to.
>

Not convinced that ldap or smtp config would ever be shared between 
different realms.  I think the usual deployment will be one realm with 
the master realm disabled.

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