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