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.
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.
>>>