[keycloak-dev] LDAP integration

Bill Burke bburke at redhat.com
Tue Mar 25 11:58:36 EDT 2014 

Getting build failures in JPA for LDAP test

On 3/24/2014 7:20 PM, Marek Posolda wrote:
> Hi,
>
> I've sent PR https://github.com/keycloak/keycloak/pull/302 with first
> version of Authentication SPI. Some key features:
> - Authentication SPI is used for validation of username+password and
> also for password updates. So all existing components like
> AuthenticationManager and AccountService are now calling Authentication
> SPI instead of directly calling realm.validatePassword or
> realm.updateCredentials.
>
> - Currently used just for username+password authentication. TOTP is
> still using RealmModel directly.
>
> - I've added 3 implementations of Authentication SPI.
> -- Model - This just delegates to realm.validatePassword and
> realm.updatePassword, so it's defacto the same stuff what we have now.
> This is the default implementation, which is used if no others are
> configured
> -- ExternalModel -- This delegates authentication to "external" realm.
> In other words, user will be able to authenticate in RealmA with
> credentials from RealmB.
> -- Picketlink -- This delegates authentication to Picketlink
> IdentityManager. I've added another abstraction
> PartitionManagerProvider, so it's possible to obtain Picketlink base
> class PartitionManager from various sources (for example from Picketlink
> subsystem). Default and only implementation of PartitionManagerProvider
> is initializing Picketlink with Ldap Identity store. Configuration of
> Ldap server is obtained from realm.
>
> - Propagation of identities: If user authenticated with Authentication
> SPI doesn't yet exists in realm, he will be "synced" and automatically
> created into realm. So for example if you configure Picketlink
> AuthenticationProvider and corporate LDAP with 5k users and then you
> authenticate with your corporate username/password, your user account is
> automatically created in realm and also all basic attributes (firstName,
> lastName, email) are retrieved from LDAP server, or from external-realm
> or whatever other authentication provider provides.
>
> - For update password, it's possible to configure that password will be
> updated just in some authentication providers. So for example, you can
> have read-only LDAP, which is used just for authentication users, but
> they can't update password here. Instead password might be updated just
> in "model" based Authentication Provider and synced into Keycloak DB, so
> next time user is able to authenticate with this changed password from
> Keycloak DB instead of the Ldap password.
>
> - Configuration looks like this:
>
> "authenticationProviders": [
>       {
>           "providerName": "model",
>       "passwordUpdateSupported": true
>       },
>       {
>           "providerName": "externalModel",
>           "passwordUpdateSupported": false,
>           "config": {
>               "externalRealmId": "trustedRealm"
>           }
>       },
>       {
>           "providerName": "picketlink",
>           "passwordUpdateSupported": true
>       }
> ],
>
>
> Picketlink provider doesn't have any configuration as it's currently
> automatically configured with LDAP server, which is configured for realm
> like this:
>
> "ldapServer": {
>       "connectionUrl": "ldap://localhost:10389",
>       "baseDn": "dc=keycloak,dc=org",
>       "userDnSuffix": "ou=People,dc=keycloak,dc=org",
>       "bindDn": "uid=admin,ou=system",
>       "bindCredential": "secret"
> },
>
> LDAP configuration is in separate "ldapServer" element as same LDAP
> config (and same PartitionManager) will be used for Authentication SPI
> and in the future for other things (like Sync SPI)
>
>
> - Before this, we had just KeycloakSessionFactory as only
> application-scoped component. But with adding Authentication SPI and
> Picketlink+LDAP support, we may need more components (for example IDM
> PartitionManager, which is intended to be application-scoped component).
> Hence I've introduced KeycloakRegistry, which is simple Map of
> application-scoped components. And it's attribute ServletContext instead
> of KeycloakSessionFactory. Currently this registry contains just
> KeycloakSessionFactory and PartitionManagerRegistry (in case that LDAP
> is used). It's quite simple, but sufficient for current needs...
>
> - For LDAP testing, I've reused some stuff from Picketlink+Picketbox and
> added embedded ApacheDS server into unit tests and testsuite.
>
> - If you're ok with everything and merge this, I can follow with adding
> support for configuration Authentication providers and LDAP into admin
> console (right now it's possible just through JSON). And then possibly
> Sync SPI for the batch syncing of stuff from/to Sync providers (like
> LDAP server) or other Beta1 priorities from the wishlist :)
>
> Cheers,
> Marek
>
> On 14.3.2014 16:31, Stian Thorgersen wrote:
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>
>>> Cc: keycloak-dev at lists.jboss.org
>>> Sent: Friday, 14 March, 2014 3:21:08 PM
>>> Subject: Re: [keycloak-dev] LDAP integration
>>>
>>>
>>>
>>> On 3/14/2014 11:15 AM, Stian Thorgersen wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: keycloak-dev at lists.jboss.org
>>>>> Sent: Friday, 14 March, 2014 2:12:20 PM
>>>>> Subject: Re: [keycloak-dev] LDAP integration
>>>>>
>>>>> Don't we need to have LDAP as a user store?  Won't companies have a user
>>>>> LDAP store they want to point Keycloak to?  If you have an Auth SPI
>>>>> only, then you'll still need to register the users with Keycloak.
>>>> The idea with the authentication would be similar to social login. On first
>>>> login a user would be created internally in Keycloak, and there would be a
>>>> link to the user in LDAP. It would provide us with something relatively
>>>> simple without the fuzz. Social login requires registration to be enabled
>>>> for new users, but that shouldn't be required to create users that "links"
>>>> to an LDAP store.
>>>>
>>>> We can even investigate allowing multiple authentication providers for a
>>>> single realm. For example if a user exist in Keycloak you can check if
>>>> there is a LDAP link, if there is authenticate with LDAP, otherwise with
>>>> Keycloak. If no user exist, check with the other configured authentication
>>>> providers if one exists.
>>>>
>>>> In the second round we can worry about syncing, or alternatively by using
>>>> LDAP directly for users/role-mappings. I'm not 100% convinced, but I
>>>> believe the syncing approach is the simpler and probably better solution
>>>> to "federation".
>>>>
>>> So, all user updates (password, attributes, otp, etc...) will be stored
>>> in Keycloak and then synced with LDAP?
>> Can be yes, the Sync SPI needs to be flexible enough to specify what should be synced. It may also only be a one-way sync. Some examples:
>>
>> * Full sync with LDAP - if a user is added/changed in Keycloak it will be updated in LDAP, same other way around. This includes everything we can sensibly store in LDAP. It will also sync role mappings.
>> * Read only sync with LDAP - for whatever reason the admin doesn't want to let Keycloak write back to the LDAP server. In this case we'd read changes from LDAP, but not write changes back.
>> * Write only of users - for example if an application wants to have user profiles (excluding passwords, otp, etc.) in a relational database that can be queried directly by the application. This can be done by implementing the Sync SPI, and they can obviously change the way a user is represented by transforming it during the sync.
>>
>> This is most likely a stupid idea, but could we use the same syncing solution to sync between a cache and the db?!?
>>
>>> Bill
>>>
>>> --
>>> 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
>
> _______________________________________________
> 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

More information about the keycloak-dev mailing list