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

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

Also, IMO, JDBC is more flexible if users need to massage queries or have different table mappings.

On 6/11/2013 4: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 >>> >>>

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

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

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

Hmmm on second though are you saying that the use case is supporting mapping of custom user typed to extra security metadata? If so wouldn't you want that to be generic and work regardless of the data store (ldap, etc)? Sent from my iPhone On Jun 11, 2013, at 5:39 PM, Jason Greene <jgreene(a)redhat.com&gt; 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(a)redhat.com&gt; 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

And what does that have to do with JPA? On 6/11/2013 7:08 PM, Shane Bryzak wrote: > The point is that we don't want to define the identity schema in stone; > we want to allow the developer to be able to do that (if they choose > to), and we want the developer to be able to integrate that identity > schema with their application schema (once again, if they choose to). > Our main goal here is to not preempt the requirements for an > application's identity model. > > On 12/06/13 08:54, Jason Greene wrote: >> Hmmm on second though are you saying that the use case is supporting mapping of custom user typed to extra security metadata? If so wouldn't you want that to be generic and work regardless of the data store (ldap, etc)? >> >> Sent from my iPhone >> >> On Jun 11, 2013, at 5:39 PM, Jason Greene <jgreene(a)redhat.com&gt; 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(a)redhat.com&gt; 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 > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev >

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

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

On 12/06/13 09:15, Bill Burke wrote: > I thought what we were discussing here is removing the dependency on JPA > for the RDBMS backend plugin when deploying picketlink to Wildfly? > > That's how the thread started, but then it veered into a discussion about what application developers care about. 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. From your perspective, this might be sufficient to meet your own requirements however Anil and the security team have to look at the bigger picture. Not every developer is going to use PicketLink in the exact same way. _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

Anil already responded to this in his very first reply: On 12/06/13 06:39, Anil Saldhana wrote: > But for Wildfly core authentication using PicketLink > IDM, for database backends, JDBC makes sense. I agree with him (and Jason), it absolutely does make sense to use JDBC for the PicketLink subsystem in Wildfly. On 12/06/13 09:32, Bill Burke wrote: > It wasn't a tangent discussion, Jason asked, "do we have to depend on > JPA?" You guys inferred that to do this application model sharing > you're talking about, JPA is required... > > On 6/11/2013 7:24 PM, Shane Bryzak wrote: >> On 12/06/13 09:15, Bill Burke wrote: >>> I thought what we were discussing here is removing the dependency on JPA >>> for the RDBMS backend plugin when deploying picketlink to Wildfly? >>> >>> >> That's how the thread started, but then it veered into a discussion >> about what application developers care about. >> >> 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. >> From your perspective, this might be sufficient to meet your own >> requirements however Anil and the security team have to look at the >> bigger picture. Not every developer is going to use PicketLink in the >> exact same way. >> >> _______________________________________________ >> 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

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 -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

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

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(a)jboss.com&gt; 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(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

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(a)redhat.com&gt; 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(a)jboss.com&gt; 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(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 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat