[security-dev] JPA?

[Jason Greene]

So it sounds like we all agree that JPA only makes theoretical sense as a per-application scope construct, and not something that would ever be used by a container. However, it still seems like this introduces a big leak in the abstraction. If the application is controlling and mixing the authentication data with application data, then it seems the value offered by a picket link JPA backend isn't so useful, and perhaps it gets in the way.

Would it not be more flexible to simply let applications implement a set of hooks, and be responsible for retrieving the data themselves, using the application's EntityManager? I mean if it is their schema, than it is their schema. This would then also support other non-JPA based stores (e.g. maybe the application is using some kind of grid store).

On Jun 12, 2013, at 6:22 AM, Pete Muir <pmuir at redhat.com> wrote:

> Late to the discussion, but I think Darran is exactly correct, and this just shows why pluggable identity stores are critical. And why we need to provide a good range of sample identity store implementations out of the box.
> 
> By default, something like Undertow will want a very lightweight identity store, to make it very easy to set up out of the box, and keep dependencies light. JDBC or flat files is perfect for that.
> 
> Some users will have existing corporate identity stores that they want to plug in to (e.g. LDAP, ActiveDirectory), and they will want to plug all things that use identity into that (Undertow, RESTEasy, their application logic) into that.
> 
> Other users won't have existing corporate identity stores, or not want to connect to them (think of the myriad of different identities you can end up with today in large companies when people don't integrate systems properly). For them, JPA can be a good answer for creating a custom schema.
> 
> We've also touched on the orthogonal issue of whether people will use the PL API directly for identity management. I think there are different classes of users here - some will, and some won't. It depends on what your app does, and whether you prefer to use declarative or programmatic authorisation (and hence access to roles), and what other systems you need to integrate with.
> 
> In summary, I think we can provide a JDBC store *additionally* to the JPA store (which already exists BTW). I think it's another good standard to support in this area.
> 
> On 12 Jun 2013, at 05:47, Darran Lofthouse <darran.lofthouse at jboss.com> wrote:
> 
>> One thing we need to achieve once all of this is finished is a single 
>> unified security solution for the whole of WildFly.
>> 
>> Having said that I don't think it is unreasonable that PicketLink IDM 
>> running within an application server process may have additional 
>> capabilities provided we have equivalents like the JDBC store for the 
>> management processes running within the host controller process.
>> 
>> Regards,
>> Darran Lofthouse.
>> 
>> 
>> On 11/06/13 21:39, 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

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat