Re: [security-dev] JPA?

I thought what we were discussing here is removing the dependency on JPA for the RDBMS backend plugin when deploying picketlink to Wildfly? On 6/11/2013 7:12 PM, Shane Bryzak wrote: > We do provide a JPA entity model, and it's already in a standalone Maven > module. We're labeling it as a "sample" schema, and by no means > recommending it as any kind of default. It's simply there to give > developers an idea of what's possible - we're also planning to give a > separate example as a quickstart, and on top of that the PicketLink test > suite will include a variety of identity schemas. > > On 12/06/13 09:05, Bill Burke wrote: >> JPA is completely orthogonal to what you want to do here. Either users >> will want to write custom identity types that want to leverage the >> back-end abstraction that Picketlink provides, or they will be >> implementing the appropriate SPI interfaces so that the Picketlink APIs >> can be used on top of their own custom storage mechanisms. >> >> If you want to provide a JPA entity model, it should be a separate maven >> module and not something the RDBMS store should be built on top of. >> That's my opinion, and I'm sticking to it for now. >> >> >> On 6/11/2013 6:34 PM, Shane Bryzak wrote: >>> Sorry Bill, but that's nonsense. In Seam, the Identity bean (now part >>> of the PicketLink API) was a core component of most applications, at >>> least those that required any type of security. I agree with your >>> statement that developers won't be using the "PicketLink data model" to >>> develop their applications, this is something that's largely hidden >>> behind more developer-friendly abstractions. What PicketLink will do >>> though is work with an existing application model to enable more fluid >>> integration between them. Once PLINK-130 is complete we can perhaps >>> give some more illuminating examples, but to summarise, you'll be able >>> to define your own identity classes (rather than use the ones built-in >>> to PicketLink) complete with custom attributes - for example, your >>> application might require a User class that has properties (attributes) >>> for addresses and contact details, which would actually be persisted via >>> corresponding entity beans within the application. The changes we're >>> working on now will allow this and more. >>> >>> On 12/06/13 08:15, Bill Burke wrote: >>>> Most non-framework developers, even Seam ones, will never see the >>>> Picketlink API. Most will be picking pre-made widgets and assemblying >>>> these widgets together through configuration or the management console. >>>> Most Framework developers will want to write plugins that are usable >>>> with any storage back end, this also means no JPA. >>>> >>>> I think you're fooling yourself if you think app developers are going to >>>> use the Picketlink data model to developer their applications. If >>>> anything users are going to have existing models and security >>>> infrastructure they need to integrate with. >>>> >>>> On 6/11/2013 6:03 PM, Shane Bryzak wrote: >>>>> Of course there is, close to 100% of the developers that use/used Seam >>>>> would have been using JPA. Remember that the identity model will for >>>>> many use cases also tie into the application model, in fact the >>>>> refactoring that I'm working on for PLINK-130 will help to strengthen >>>>> this connection. >>>>> >>>>> On 12/06/13 07:04, Bill Burke wrote: >>>>>> How exactly does JPA give users more control over their data than JDBC? >>>>>> Also, I'm sorry, but I just don't believe you that there is this large >>>>>> contingent of app deveopers that want JPA. >>>>>> >>>>>> On 6/11/2013 4:57 PM, Anil Saldhana wrote: >>>>>>> Bill, application developers will care about JPA vs JDBC if they want >>>>>>> greater control on things like roles, groups etc. While container driven >>>>>>> security is good for many applications, a large contingent of app >>>>>>> developers just want greater control on determining the roles/groups of >>>>>>> users authenticating to their app. >>>>>>> >>>>>>> On 06/11/2013 03:53 PM, Bill Burke wrote: >>>>>>>> JPA vs. JDBC isn't a choice, users won't care. Why would app developers >>>>>>>> care either? They should be using management interfaces or the upcoming >>>>>>>> sso server to manage their domains. >>>>>>>> >>>>>>>> On 6/11/2013 4:39 PM, Anil Saldhana wrote: >>>>>>>>> Jason - I will let others chime in their thoughts. >>>>>>>>> >>>>>>>>> We want to support as many Identity Store implementations as possible. >>>>>>>>> We implemented a File Store implementation mainly to aid its usage as >>>>>>>>> the default identity store implementation in WildFly. >>>>>>>>> I have no issues in providing an additional JDBC identity store >>>>>>>>> implementation. It just gives the users more implementations to choose from. >>>>>>>>> >>>>>>>>> From application developers perspective, I think the balance still >>>>>>>>> swings toward JPA. But for Wildfly core authentication using PicketLink >>>>>>>>> IDM, for database backends, JDBC makes sense. >>>>>>>>> >>>>>>>>> It will be at least a couple of months before we attempt a JDBC >>>>>>>>> implementation due to 2.5.0 release. That is why I placed the JIRA issue >>>>>>>>> fix to be 2.5.1. I think this works for Wildfly roadmap. >>>>>>>>> >>>>>>>>> On 06/11/2013 03:14 PM, Jason Greene wrote: >>>>>>>>>> I thought it best to move the discussion on undertow to here. >>>>>>>>>> >>>>>>>>>> Anil opened a JIRA to investigate: >>>>>>>>>> https://issues.jboss.org/browse/PLINK-190 >>>>>>>>>> >>>>>>>>>> My concerns are: >>>>>>>>>> >>>>>>>>>> - Initialization Time (JPA has always been expensive in this area) >>>>>>>>>> - Dependency chain problems (if this forces the app server (which at some point might not be limited to Java EE) to have a big chunk of EE just to support database auth) >>>>>>>>>> - Potential increase of memory usage? (in particular if we end up with hibernate using infinispan as a cache which is then double cached at the auth level) >>>>>>>>>> >>>>>>>>>> I guess the main reason for the switch from JDBC is to avoid supporting various DB dialects. However, the following is also true: >>>>>>>>>> >>>>>>>>>> - ANSI SQL-92 is supported by almost everyone, and it allows for portable DML >>>>>>>>>> - IDMs have very simple relational layouts and queries >>>>>>>>>> - It's easy to abstract queries to allow customization by a user >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>