[keycloak-dev] Remove IDM entirely or keep Picketlink federation provider?
mposolda at redhat.com
Wed Apr 8 17:05:51 EDT 2015
Sure. For option 2 I meant to remove the PL IDM dependencies from
distribution, but just keep the example with federation provider, which
will be installed on demand (just if someone needs to migrate his PLIDM
DB to Keycloak).
But for now, I've just forked needed Picketlink IDM code into
federation/ldap module and removed PL IDM dependencies. I've created
separate JIRA for migration, so we can look at it later when it's
I've removed some Picketlink IDM layers like PartitionManager,
IdentityManager etc and keep just LDAP Identity store. There is still
space to remove more abstractions though. I will need to re-visit it
again anyway during work on LDAP enhancements.
I did not remove picketlink dependencies from packaging as it seems they
are still needed by SAML. At least SAML examples are still using
Picketlink libraries on SP side. Are we going to fork SAML SP code as well?
On 8.4.2015 16:03, Bill Burke wrote:
>>>> Or should I simply go with (1) and don't care about the migration for now?
>>> >>As 2 can't do roles as well it's not really that useful. Also, since IDM is so flexible I can't see us providing one that works for everyone (if anyone?! at all). So maybe what we should do is to provide an example that users can fork/modify?
>> >Yeah, so maybe adding new example into examples/providers for that?
>> >I can try to do something by tomorrow, but not sure if I catch it. And
>> >next week I would like to start on persistent client grants. I guess
>> >it's not an issue to possibly postpone this to some later release?
> I think it will help us tremendously in product if we have zero PL IDM
> dependencies. As we discussed in meetings, Picketlink is not going to
> be upgraded in EAP7 and is a few versions back of the latest Picketlink.
> Keycloak LDAP integration currently has dependencies on latest and
> greatest Picketlink.
More information about the keycloak-dev