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

Any chance of saving config in a single json file (maybe one per-realm), instead of in the database. That would be more than sufficient as long as the server is single-tenant and there's only a handful applications. For config I mean things like: Realm: * Name * Email settings * Require email validatation * Social settings * List of applications * ... Application: * Name * Management URI, redirect URIs * ... That would make it a lot simpler for devs to manage the server more like a traditional server if they want to. ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Friday, 1 November, 2013 2:22:25 PM > Subject: [keycloak-dev] implement JPA model > > FYI, I'm currently implementing a JPA model. Will switch to that > instead of Picketlink when its done. > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

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.

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

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.

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

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.

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

On 11/4/2013 11:05 AM, Anil Saldhana wrote: > 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. > Anil, what exactly are you trying to tell me? That there's some mythical "unified developer experience" I'm missing out on? An experience that currently doesn't exist at all, even in Wildfly? An experience that you're promising for WF9? What is Keycloak supposed to do until then?

What's frustrating is that our data model is simple. So simple it only takes one or two days to write a JPA or Mongo implementation for. I just refuse to spend weeks and weeks like I did this summer wading through Picketlink code and/or waiting for next next patch to be released to make Picketlink usable. Until this magic Picketlink "unified developer experience" comes to fruition, we're doing our own backend.

From mobile

> On 11/4/2013 10: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 ;) You are rewriting history. My requests last summer were to make the existing PLIDM API usable. i.e. adding removing partitions. Don't try to hang the complexity of PLIDM on me... -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 11/4/2013 11:05 AM, Anil Saldhana wrote: > 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. > Anil, what exactly are you trying to tell me? That there's some mythical "unified developer experience" I'm missing out on? An experience that currently doesn't exist at all, even in Wildfly? An experience that you're promising for WF9? What is Keycloak supposed to do until then?

What's frustrating is that our data model is simple. So simple it only takes one or two days to write a JPA or Mongo implementation for. I just refuse to spend weeks and weeks like I did this summer wading through Picketlink code and/or waiting for next next patch to be released to make Picketlink usable. Until this magic Picketlink "unified developer experience" comes to fruition, we're doing our own backend.

Pedro, with all due respect, we already use Picketlink. What we're doing is swapping it out until there is an advantage to use it again. Right now there are only disadvantages and the fact it can't run in Wildfly is a blocker. I'll be committing the JPA model later today.

On 11/5/2013 7:32 AM, Pedro Igor Silva wrote: > I think most of the frustrating feeling you got was because you're trying to reuse the Basic Model. > > https://github.com/keycloak/keycloak/tree/master/model/picketlink/src/mai... (If I'm not wrong) > > The Basic Model is a simple and ready to use domain model that can be used to enable very quickly most of IDM capabilities. But you're not tied to this model at all, as you can always provide your own and make it PL enabled. > > When designing an application like yours, I believe the best thing to do is start by writing your own model. And then provide the necessary annotations to enable PL on top of it. > > The idea behind the JPA store is not restrict your design decisions when modeling your domain model, but integrate with it. > > Give me a chance and I can enable PL in your model, so you still get your model the way you want. > > ----- Original Message ----- > From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Monday, November 4, 2013 2:53:48 PM > Subject: Re: [keycloak-dev] implement JPA model > > On 11/04/2013 10:25 AM, Bill Burke wrote: >> On 11/4/2013 11:05 AM, Anil Saldhana wrote: >>> 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. >>> >> Anil, what exactly are you trying to tell me? That there's some >> mythical "unified developer experience" I'm missing out on? An >> experience that currently doesn't exist at all, even in Wildfly? An >> experience that you're promising for WF9? What is Keycloak supposed to >> do until then? > I am saying try to use the PL IDM API for the basic model. That would > automatically reduce your work when WF9 will use the IDM natively for its > user stores. Basically you can just reuse the integration work done in > WF9 for IDM configuration. KeyCloak would not have to do anything. > > Right now for JBossAS7, EAP6.1+ and WF8, PicketLink IDM exists as > an external library. The IDM subsystem does work for AS7,6.1 but has > not yet been updated for WF8. But KeyCloak as a web application should > focus on the IDM API for the basic model. >> What's frustrating is that our data model is simple. So simple it only >> takes one or two days to write a JPA or Mongo implementation for. I >> just refuse to spend weeks and weeks like I did this summer wading >> through Picketlink code and/or waiting for next next patch to be >> released to make Picketlink usable. Until this magic Picketlink >> "unified developer experience" comes to fruition, we're doing our own >> backend. > Ok. If you have your JPA model in a KeyCloak branch somewhere, we can > take a look at it and make suggestions.

On 11/5/2013 11:30 AM, Anil Saldhana wrote: > On 11/05/2013 07:06 AM, Bill Burke wrote: >> Pedro, with all due respect, we already use Picketlink. What we're >> doing is swapping it out until there is an advantage to use it again. >> Right now there are only disadvantages and the fact it can't run in >> Wildfly is a blocker. I'll be committing the JPA model later today. > We are updating WildFly with the PicketLink subsystem that contains IDM > configuration, this week. Can you please provide a list of disadvantages > of using PicketLink? A lot of people/teams collaborated on the subsystem > design. It will be beneficial if KeyCloak can wait a bit on the PL. Give > us a chance. :) Disadvantages: * Performance. can tweak more performance with a back-end that is specific to our metamodel. * Bolek seems to think importing and syncing with LDAP/AD is a better approach than federating LDAP/AD directly. An approach you just don't support and probably won't support for a long time. * PL IDM API requires upfront declaration of federation model. But its more of lack of advantages: * With PL-JPA, I have to define JPA entities *ANYWAYS*. So, instead, avoid the complexity (and bugs) of PL and just implement our own datamodel in JPA. Simpler, easier to maintain. Something that is more proven and reliable.

* PL-File plugin isn't very useful (or usable considering it doesn't suport transactions). Only reason we'd want a file-based storage would be to have a human-readable readonly-file specific to our data model so admins could edit it directly.

Honestly, the PL_IDM_API vision and architecture scares me a bit. its not a security solution, its a persistence mapping solution. An immature persistence mapping solution. If I wanted a federated persistence solution, why wouldn't I just use Teiid? And work with Teiid to make it more consumable? Combine this doubt with random blocker bugs that pop up makes me want to retire our PL backend until it makes sense to bring in back in.