[security-dev] JPA?

Darran Lofthouse darran.lofthouse at jboss.com
Wed Jun 12 05:47:35 EDT 2013


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
>


More information about the security-dev mailing list