For the first round of LDAP integration we will only focus on authenticating with LDAP. This will work by adding an Authentication SPI. It will provide two methods, verify user password and update user password. We'll have two implementations of this, Keycloak Model and LDAP (via PicketLink). It should be possible to configure which Authentication SPI provider is used by a Realm through the admin console. This will include setting up configuration for the LDAP server. Second round (which will have a low priority for beta1, so will most likely be postponed to after the 1.0.Final) will be to add a Sync SPI. This will support one-way and two-way of syncing data from an external resource into the Keycloak model. It will support resource that allows registering listeners for events (for near real-time syncing) as well as interval based pulling when this is not possible. JIRA issue for this is: https://issues.jboss.org/browse/KEYCLOAK-316 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

----- 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".

----- 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

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(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 >