[keycloak-dev] implement JPA model

[Anil Saldhana]

On 11/04/2013 09:58 AM, Bolesław Dawidowicz wrote:
> On 11/04/2013 04:46 PM, Bill Burke wrote:
>>
>> On 11/4/2013 10:13 AM, 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.
>>> 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.
>>>
>> The problem with Picketlink IDM is that it is not a security solution.
>> It is a general purpose persistence solution.
> I think this is the main question to ask. Is it? I have impression that
> it was not meant to be but it kinda ended being used like this down the
> road.
>
> Maybe part of current issues is that PLIDM is abused as general purpose
> persistence solution. From the perspective of JPA store design I'm quite
> sure it will never be efficient one.
>
> Just to be fair... Looking back in time a lot of complexity was
> introduced into PLIDM by your request Bill ;) And they even code named
> one of the releases like that :) It is obvious that to generic, abstract
> and flexible solutions cannot be profiled and tuned to cover every
> possible scenario. Maybe it is a good moment to take a step back and
> look at what IDM store can and what it simply cannot cover in a proper
> way. We should agree on expectations. I guess we can all agree that it
> should be able to provide base IDM model storage and things like LDAP
> integration.
I would not blame Bill or anyone on this. Companies have failed implementing
a one-size-fits-all IDM solutions. But we want to be successful with our 
IDM project.
We did try to cater to Bill's requirements and had a beta release for 
his requirements.
It did introduce some complexity which can be rectified by some great 
user documentation.

What I cannot accept is Bill's refusal to look at what we are trying to 
tell him and cop out
in the guise of timelines. The PL team has very limited time in engaging 
in lengthy email
discussions but we are willing to help in any manner if the team shows 
interest in listening
to us.

>
>> You're basically
>> reinventing JDO/Hibernate, and, honestly, are repeating and fixing the
>> same mistakes that were made with those solutions years and years and
>> years ago...
>>
>> You can't really have a uniform dev experience beyond user/credentials
>> because well, Keycloak and other technologies have a lot more metadata
>> that needs to be stored beyond the simplistic OOTB WF security model.
>>
>>>     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.
>> The current Resteasy OAuth solution can use any security domain defined
>> in AS7 and EAP6.x.  We'll want to do something similar with Keycloak so
>> that it can be deployed as a solution in existing AS7, EAP6, WF8, and
>> EAP7 environments.  We're not waiting for Picketlink IDM to come on line
>> and be integrated with WF9 and EAP8.
>>
>
>