[keycloak-dev] Remove IDM entirely or keep Picketlink federation provider?

[Marek Posolda]

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 
required: https://issues.jboss.org/browse/KEYCLOAK-1198

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?

Marek

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.