[security-dev] JPA?

Tue Jun 11 19:05:01 EDT 2013

How about for a SCIM POST request?

http://www.simplecloud.info/specs/draft-scim-api-01.html#create-resource

On 12/06/13 08:39, Jason Greene wrote:
> You lost me. I don't understand why an application needs an abstraction (picketlink API) if they are also coding against the data raw.
>
> On Jun 11, 2013, at 5:34 PM, Shane Bryzak <sbryzak at redhat.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20130612/bf2baa19/attachment.html 