9:50 a.m.
On 11/04/2013 04:13 PM, Anil Saldhana wrote:
On 11/04/2013 03:45 AM, Bolesław Dawidowicz wrote:
> On 11/01/2013 04:17 PM, Anil Saldhana wrote:
>> Bill,
>> this is just a cop out.
>>
>> You very well know this is just going to create more headache
>> if ever KeyCloak is integrated into Wildfly. :)
>>
>> In future versions of WF (starting WF9), we want to make use of PL IDM
>> for the user stores across the subsystems. That is the reason we are
>> implementing a JDBC store implementation in addition to the JPA store when
>> a database is involved.
> How are you going to handle store implementation compatibility? JPA one
> exposes great deal of flexibility by letting you to map your own
> entities and shaping the model. I assume JDBC implementation will be
> much more constrained and enforcing the model? I wonder what are the
> odds that two applications reuse same identity store implementation if
> they go beyond very basic schema.
>
> Going along this line... benefit for KC would be to integrate with IDM
> storage that is already in place - JDBC one that you are implementing
> would be natural fit to integrate with WF. Would be good to know the
> limitations in advance to adapt.
I think part of the struggles is that KC tries to use PLIDM as a general
purpose store. With main pain points around too much flexible schema and
storing nearly everything there - which I guess was never intend of the
IDM store. I would reduce the usage of IDM in KC to just base IDM model
and keep all remaining info in a separate store. .
KeyCloak shouldn't be constrained by IDM store. However I see several
advantages in keeping PLIDM integration - and really at least for the
core User/Profile/Role/Group model (with tier/partition if needed)
- Reusing already populated store defined by application in WildFly/EAP
- LDAP integration provided by PL
- Additional store implementations
- If KeyCloak is deployed on a server and maintains user store it should
be accessible by external applications. Would be perfect to do it with
unified API - the one advertised in WF, promoted with Quickstarts and etc.
The biggest issue I see lies in the abstract nature of current JPA store
- Its biggest advantage of being possible to adapt to already deployed
schema and define very flexible model is also main course. I fear that
other implementations will differ in the extend to which PLIDM API is
supported. It would be best if we limit complexity of model used by KC
in IDM store and secure compatibility with majority of store
implementations.
Basically I'm for proper abstraction and not overloading IDM store. This
way we can have several options.
- Bill can follow with his general purpose JPA store.
- PLIDM integration is still achievable - for IDM data
- Parts related to config or IDM can be migrated to other store
implementaitons like Mongo (doesn't matter if via PL APIs or not).
For us the last option is critical. We need to keep flexibility for
other storage implementaiton in the future. Still it should be possible
to split and cover config, realm, app and idm data separately as it
doesn't make sense to reimplement everything.
JDBC implementation is mainly for deeper WF integration. So if we
standardize on PicketLink IDM across WF, then KeyCloak can reuse it
to provide uniform dev experience.
From a standalone KC perspective, I think it makes sense to
integrate with PL IDM, to reuse across app servers/runtimes. The IDM
API is pretty standardized across the teams here
while the implementation (file, JPA, JDBC,LDAP) can be plugged in.
>> Unfortunately KeyCloak implementing its own JPA model will just increase
>> the technical debt when we deal with an integrated system such as WildFly
>> from a developer user experience perspective. :(
>>
>> Regards,
>> Anil
>>
>> On 11/01/2013 10:02 AM, Bill Burke wrote:
>>> Keycloak is designed right now so that we can easily swap out
>>> persistence engines.
>>>
>>> I can't wait for PL 2.5.3 to be released so I can use it with Wildfly.
>>> I'll have a JPA model done by today so I can start bundling and testing
>>> Keycloak with Wildfly tomorrow. We'll revisit Picketlink again in the
>>> next Keycloak release to see if it makes sense to take advantage of its
>>> LdAP/AD integration. Right now though, I think we can get the biggest
>>> performance improvements from maintaining our own persistence engine and
>>> by putting targeted caching in front of it.
>>>
>>>
>>> On 11/1/2013 10:22 AM, Anil Saldhana wrote:
>>>> And I fall off the chair.
>>>>
>>>> On 11/01/2013 09:22 AM, Bill Burke wrote:
>>>>> FYI, I'm currently implementing a JPA model. Will switch to
that
>>>>> instead of Picketlink when its done.
>>>>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bolesław Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead