Re: [security-dev] JPA?

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 >>>>>>>>> >>>>>>>>> >>>>>> _______________________________________________ >>>>>> security-dev mailing list >>>>>> security-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/security-dev >>>>>> >>>> _______________________________________________ >>>> security-dev mailing list >>>> security-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/security-dev >>>> >> _______________________________________________ >> security-dev mailing list >> security-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev >> _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev