[keycloak-dev] implement JPA model

[Bolesław Dawidowicz]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



-- 
Bolesław Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead