Re: [keycloak-dev] LDAP integration

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(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>> To: keycloak-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev