[keycloak-dev] implement JPA model

[Anil Saldhana]

On 11/04/2013 09:50 AM, Bolesław Dawidowicz wrote:
> 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.
Agreed. :)
>
>> 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.
>>>>>>