[security-dev] JPA?

Tue Jun 11 19:15:27 EDT 2013

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

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com