Similar challenges exist for LDAP bindings also, since user LDAP DITs may be different. But we have to balance complexity with usability. :) On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: > Ok. I'll take a look how he took care of that. > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; > To: security-dev(a)lists.jboss.org > Sent: Wednesday, September 5, 2012 6:52:35 PM > Subject: [security-dev] PicketLink IDM JPA Identity Store > > Pedro, > Shane just referred me to the following: > > https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... > > Can you adapt your work to incorporate all facets of this Seam work? > Shane says users have varying db schema structures and the JPA > implementation in seam3 took care of the nuances. > > Regards, > Anil >

Hi guys, which line should I look? From my perspective this line https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... could be refactored to https://github.com/picketlink/picketlink-idm-restored/blob/6e63bc583fa2fa... We're able to implement our own User entity, might be interesting to add getPassword/setPassword methods, in this way this line https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... won't be needed. Just doing would be enough: public class MyCustomUser implements User { …. } myCustomUser.setPassword("…"); //think about the registration process, we don't need DTOs just to pass passwords between entities. im.createUser(myCustomUser); About this line https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... I'll refactor it and send a PR. Currently we don't have groups on AeroGear, so our method is something like: im.grantRole(adminRole, user, null); I'll refactor it to allow users without a group. Wdyt? -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile On Monday, October 8, 2012 at 1:30 PM, Anil Saldhana wrote: > I want to offer continued discussion on the JPA implementation in the > IDM project. > > The work that Pedro did is restored here in the following workspace: > https://github.com/picketlink/picketlink-idm-restored > > A testcase that is useful for JPA implementation in IDM is: > https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... > > It is the exact mirror of the LDAP implementation: > https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... > > These two implementations have very minimal user configuration. > > The challenge is when users bring in complex database schemas and LDAP > DITs into operation. But the goal of balancing complexity with > usability is a tough one. > > On 09/06/2012 10:13 AM, Anil Saldhana wrote: >> Similar challenges exist for LDAP bindings also, since user LDAP DITs >> may be different. But we have to balance complexity with usability. :) >> >> On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: >>> Ok. I'll take a look how he took care of that. >>> >>> Regards. >>> Pedro Igor >>> >>> ----- Original Message ----- >>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com >>> <mailto:Anil.Saldhana@redhat.com>> >>> To: security-dev(a)lists.jboss.org <mailto:security-dev@lists.jboss.org> >>> Sent: Wednesday, September 5, 2012 6:52:35 PM >>> Subject: [security-dev] PicketLink IDM JPA Identity Store >>> >>> Pedro, >>> Shane just referred me to the following: >>> >>> https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... >>> >>> Can you adapt your work to incorporate all facets of this Seam work? >>> Shane says users have varying db schema structures and the JPA >>> implementation in seam3 took care of the nuances. >>> >>> Regards, >>> Anil

I want to offer continued discussion on the JPA implementation in the IDM project. The work that Pedro did is restored here in the following workspace: https://github.com/picketlink/picketlink-idm-restored A testcase that is useful for JPA implementation in IDM is: https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... It is the exact mirror of the LDAP implementation: https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... These two implementations have very minimal user configuration. The challenge is when users bring in complex database schemas and LDAP DITs into operation. But the goal of balancing complexity with usability is a tough one. On 09/06/2012 10:13 AM, Anil Saldhana wrote: > Similar challenges exist for LDAP bindings also, since user LDAP DITs > may be different. But we have to balance complexity with usability. :) > > On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: >> Ok. I'll take a look how he took care of that. >> >> Regards. >> Pedro Igor >> >> ----- Original Message ----- >> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >> To: security-dev(a)lists.jboss.org >> Sent: Wednesday, September 5, 2012 6:52:35 PM >> Subject: [security-dev] PicketLink IDM JPA Identity Store >> >> Pedro, >> Shane just referred me to the following: >> >> https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... >> >> Can you adapt your work to incorporate all facets of this Seam work? >> Shane says users have varying db schema structures and the JPA >> implementation in seam3 took care of the nuances. >> >> Regards, >> Anil >> _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

The reason I advised that we base the JPA implementation on Seam's JpaIdentityStore was not one to do with pride, but because its design has been shaped by many years of developer feedback. I've got no problem with Pedro's code (I think it's quite good actually) however the design fails to address a number of requirements. Let's go through a few of them in more detail: 1. Hard coded entities This is a problem for a number of reasons. First and foremost, it doesn't allow a developer to BYO schema. Many projects share user databases, or are based on legacy systems that cannot be modified. There may be strict naming conventions in place for table and column names. It might be simply the case that the developer needs to model their schema in a particular way to meet certain business requirements. Whatever the reason, it is very clear that we cannot dictate the database schema to the developer. We can certainly make recommendations, however this should be done via documentation, and possibly in an example. 2. Partitioning This also stems from having a hard coded schema. Many projects may require users to authenticate against an LDAP directory, but authorize against a database. One of the great ideas from Bolek's original PLIDM implementation was that of FeatureSets, basically metadata which reflects which identity management capabilities a particular IdentityStore implementation supports. It allows us to store users in one identity store, and group and role memberships in another. Also, what happens when an application wants to be purely LDAP based, does Hibernate still try to create (or expect the existence of) the corresponding tables for the hard coded entity beans? What if there is no database? 3. Caching This particular feature isn't present in Seam, however the intent is to support it in PicketLink. To summarise, rather than creating a new User, Group or Role instance (or their various memberships) every single time the IdentityStore would normally need to do this, we use a single cache (distributed in the case of clustered applications) to store these identity objects and perform the lookup from the cache instead. This isn't possible to achieve when we have hard coded entities that implement the identity model interfaces. This feature requires an intricate coupling between IdentityManager, IdentityStore and the cache implementation. 4. CDI awareness We need to develop this module so that it will run in an SE environment so that the AS team (and others) can use it, however we need to also keep in mind that we need to integrate it with CDI, and the design should reflect that. JPACallback and JPATemplate seem to add unnecessary complexity which in the end still boils down to one EntityManager instance per JPAIdentityStore. I honestly think the JPAIdentityStore implementation should be stateless, in that one instance can service multiple (concurrent) requests (not to mention that configuration is an expensive operation). We also need to also keep in mind that the EntityManager could have any type of scope, with the most obvious ones being request or conversation scoped. I'm happy to discuss these further, however I hope that it's convinced everyone that we need to reconsider the current design. Shane On 09/10/12 02:30, Anil Saldhana wrote: > I want to offer continued discussion on the JPA implementation in the > IDM project. > > The work that Pedro did is restored here in the following workspace: > https://github.com/picketlink/picketlink-idm-restored > > A testcase that is useful for JPA implementation in IDM is: > https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... > > It is the exact mirror of the LDAP implementation: > https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... > > These two implementations have very minimal user configuration. > > The challenge is when users bring in complex database schemas and LDAP > DITs into operation. But the goal of balancing complexity with > usability is a tough one. > > On 09/06/2012 10:13 AM, Anil Saldhana wrote: >> Similar challenges exist for LDAP bindings also, since user LDAP DITs >> may be different. But we have to balance complexity with usability. :) >> >> On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: >>> Ok. I'll take a look how he took care of that. >>> >>> Regards. >>> Pedro Igor >>> >>> ----- Original Message ----- >>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >>> To: security-dev(a)lists.jboss.org >>> Sent: Wednesday, September 5, 2012 6:52:35 PM >>> Subject: [security-dev] PicketLink IDM JPA Identity Store >>> >>> Pedro, >>> Shane just referred me to the following: >>> >>> https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... >>> >>> Can you adapt your work to incorporate all facets of this Seam work? >>> Shane says users have varying db schema structures and the JPA >>> implementation in seam3 took care of the nuances. >>> >>> Regards, >>> Anil >>> > _______________________________________________ > 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 Oct 8, 2012, at 8:24 PM, Shane Bryzak wrote: > The reason I advised that we base the JPA implementation on Seam's > JpaIdentityStore was not one to do with pride, but because its design > has been shaped by many years of developer feedback. I've got no > problem with Pedro's code (I think it's quite good actually) however the > design fails to address a number of requirements. Let's go through a > few of them in more detail: > > 1. Hard coded entities > > This is a problem for a number of reasons. First and foremost, it > doesn't allow a developer to BYO schema. Many projects share user > databases, or are based on legacy systems that cannot be modified. > There may be strict naming conventions in place for table and column > names. It might be simply the case that the developer needs to model > their schema in a particular way to meet certain business requirements. > Whatever the reason, it is very clear that we cannot dictate the > database schema to the developer. We can certainly make > recommendations, however this should be done via documentation, and > possibly in an example. I'd like to see actual numbers on greenfield vs BYO - because if flexibility means complexity, we need to assure that we're not hurting 95% because of the 5% from my **anedoctal experience**, when adopting a framework, ppl allow for some small changes to accomodate, granted they are small.

From those looking to migrate from Seam 2 to Seam 3 when we first rolled

> > 2. Partitioning > > This also stems from having a hard coded schema. Many projects may > require users to authenticate against an LDAP directory, but authorize > against a database. One of the great ideas from Bolek's original PLIDM > implementation was that of FeatureSets, basically metadata which > reflects which identity management capabilities a particular > IdentityStore implementation supports. It allows us to store users in > one identity store, and group and role memberships in another. Also, > what happens when an application wants to be purely LDAP based, does > Hibernate still try to create (or expect the existence of) the > corresponding tables for the hard coded entity beans? What if there is > no database? > > 3. Caching > > This particular feature isn't present in Seam, however the intent is to > support it in PicketLink. To summarise, rather than creating a new > User, Group or Role instance (or their various memberships) every single > time the IdentityStore would normally need to do this, we use a single > cache (distributed in the case of clustered applications) to store these > identity objects and perform the lookup from the cache instead. This > isn't possible to achieve when we have hard coded entities that > implement the identity model interfaces. This feature requires an > intricate coupling between IdentityManager, IdentityStore and the cache > implementation. > > 4. CDI awareness > > We need to develop this module so that it will run in an SE environment > so that the AS team (and others) can use it, however we need to also > keep in mind that we need to integrate it with CDI, and the design > should reflect that. JPACallback and JPATemplate seem to add > unnecessary complexity which in the end still boils down to one > EntityManager instance per JPAIdentityStore. I honestly think the > JPAIdentityStore implementation should be stateless, in that one > instance can service multiple (concurrent) requests (not to mention that > configuration is an expensive operation). We also need to also keep in > mind that the EntityManager could have any type of scope, with the most > obvious ones being request or conversation scoped. > > I'm happy to discuss these further, however I hope that it's convinced > everyone that we need to reconsider the current design. > > Shane > > > On 09/10/12 02:30, Anil Saldhana wrote: >> I want to offer continued discussion on the JPA implementation in the >> IDM project. >> >> The work that Pedro did is restored here in the following workspace: >> https://github.com/picketlink/picketlink-idm-restored >> >> A testcase that is useful for JPA implementation in IDM is: >> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >> >> It is the exact mirror of the LDAP implementation: >> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >> >> These two implementations have very minimal user configuration. >> >> The challenge is when users bring in complex database schemas and LDAP >> DITs into operation. But the goal of balancing complexity with >> usability is a tough one. >> >> On 09/06/2012 10:13 AM, Anil Saldhana wrote: >>> Similar challenges exist for LDAP bindings also, since user LDAP DITs >>> may be different. But we have to balance complexity with usability. :) >>> >>> On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: >>>> Ok. I'll take a look how he took care of that. >>>> >>>> Regards. >>>> Pedro Igor >>>> >>>> ----- Original Message ----- >>>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >>>> To: security-dev(a)lists.jboss.org >>>> Sent: Wednesday, September 5, 2012 6:52:35 PM >>>> Subject: [security-dev] PicketLink IDM JPA Identity Store >>>> >>>> Pedro, >>>> Shane just referred me to the following: >>>> >>>> https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... >>>> >>>> Can you adapt your work to incorporate all facets of this Seam work? >>>> Shane says users have varying db schema structures and the JPA >>>> implementation in seam3 took care of the nuances. >>>> >>>> Regards, >>>> Anil >>>> >> _______________________________________________ >> 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 -- qmx _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On 09/10/12 09:54, Douglas Campos wrote: > On Oct 8, 2012, at 8:24 PM, Shane Bryzak wrote: > >> The reason I advised that we base the JPA implementation on Seam's >> JpaIdentityStore was not one to do with pride, but because its design >> has been shaped by many years of developer feedback. I've got no >> problem with Pedro's code (I think it's quite good actually) however the >> design fails to address a number of requirements. Let's go through a >> few of them in more detail: >> >> 1. Hard coded entities >> >> This is a problem for a number of reasons. First and foremost, it >> doesn't allow a developer to BYO schema. Many projects share user >> databases, or are based on legacy systems that cannot be modified. >> There may be strict naming conventions in place for table and column >> names. It might be simply the case that the developer needs to model >> their schema in a particular way to meet certain business requirements. >> Whatever the reason, it is very clear that we cannot dictate the >> database schema to the developer. We can certainly make >> recommendations, however this should be done via documentation, and >> possibly in an example. > I'd like to see actual numbers on greenfield vs BYO - because if flexibility means complexity, we need to assure that we're not hurting 95% because of the 5% > > from my **anedoctal experience**, when adopting a framework, ppl allow for some small changes to accomodate, granted they are small. This flexibility actually allows us to *simplify* the schema, believe it or not. A developer who wants the absolute most basic features is able to create a single database table to store just user, credential and attribute information, something they cannot do if we dictate the schema to them. >> 2. Partitioning >> >> This also stems from having a hard coded schema. Many projects may >> require users to authenticate against an LDAP directory, but authorize >> against a database. One of the great ideas from Bolek's original PLIDM >> implementation was that of FeatureSets, basically metadata which >> reflects which identity management capabilities a particular >> IdentityStore implementation supports. It allows us to store users in >> one identity store, and group and role memberships in another. Also, >> what happens when an application wants to be purely LDAP based, does >> Hibernate still try to create (or expect the existence of) the >> corresponding tables for the hard coded entity beans? What if there is >> no database? >> >> 3. Caching >> >> This particular feature isn't present in Seam, however the intent is to >> support it in PicketLink. To summarise, rather than creating a new >> User, Group or Role instance (or their various memberships) every single >> time the IdentityStore would normally need to do this, we use a single >> cache (distributed in the case of clustered applications) to store these >> identity objects and perform the lookup from the cache instead. This >> isn't possible to achieve when we have hard coded entities that >> implement the identity model interfaces. This feature requires an >> intricate coupling between IdentityManager, IdentityStore and the cache >> implementation. >> >> 4. CDI awareness >> >> We need to develop this module so that it will run in an SE environment >> so that the AS team (and others) can use it, however we need to also >> keep in mind that we need to integrate it with CDI, and the design >> should reflect that. JPACallback and JPATemplate seem to add >> unnecessary complexity which in the end still boils down to one >> EntityManager instance per JPAIdentityStore. I honestly think the >> JPAIdentityStore implementation should be stateless, in that one >> instance can service multiple (concurrent) requests (not to mention that >> configuration is an expensive operation). We also need to also keep in >> mind that the EntityManager could have any type of scope, with the most >> obvious ones being request or conversation scoped. >> >> I'm happy to discuss these further, however I hope that it's convinced >> everyone that we need to reconsider the current design. >> >> Shane >> >> >> On 09/10/12 02:30, Anil Saldhana wrote: >>> I want to offer continued discussion on the JPA implementation in the >>> IDM project. >>> >>> The work that Pedro did is restored here in the following workspace: >>> https://github.com/picketlink/picketlink-idm-restored >>> >>> A testcase that is useful for JPA implementation in IDM is: >>> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >>> >>> It is the exact mirror of the LDAP implementation: >>> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >>> >>> These two implementations have very minimal user configuration. >>> >>> The challenge is when users bring in complex database schemas and LDAP >>> DITs into operation. But the goal of balancing complexity with >>> usability is a tough one. >>> >>> On 09/06/2012 10:13 AM, Anil Saldhana wrote: >>>> Similar challenges exist for LDAP bindings also, since user LDAP DITs >>>> may be different. But we have to balance complexity with usability. :) >>>> >>>> On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: >>>>> Ok. I'll take a look how he took care of that. >>>>> >>>>> Regards. >>>>> Pedro Igor >>>>> >>>>> ----- Original Message ----- >>>>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >>>>> To: security-dev(a)lists.jboss.org >>>>> Sent: Wednesday, September 5, 2012 6:52:35 PM >>>>> Subject: [security-dev] PicketLink IDM JPA Identity Store >>>>> >>>>> Pedro, >>>>> Shane just referred me to the following: >>>>> >>>>> https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... >>>>> >>>>> Can you adapt your work to incorporate all facets of this Seam work? >>>>> Shane says users have varying db schema structures and the JPA >>>>> implementation in seam3 took care of the nuances. >>>>> >>>>> Regards, >>>>> Anil >>>>> >>> _______________________________________________ >>> 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 > -- qmx > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

If the goal is to make available a simple schema for just some developers that wanted it, the best way to do this is to provide an additional, optional jar file containing just the simple schema entity beans (call it picketlink-idm-defaultschema or something like this) rather than provide an entirely new implementation. This way we avoid the burden of having to maintain two implementations, and also avoid the aforementioned problem of having unwanted entity beans in the distribution for developers that don't want to use the simple schema. On 09/10/12 23:25, Anil Saldhana wrote: > I think we really need 2 implementations based on JPA and ldap each. > One implementation supports the simple/fixed schema approach and the > other implementation should be fully configurable/customizable schema > driven implementation. The configuration builders define the > implementation that is returned to the user. > > I am not game for one size fits all implementation that will send brains > in a roller coaster for simple usecases. > > On 10/08/2012 07:06 PM, Shane Bryzak wrote: >> On 09/10/12 09:54, Douglas Campos wrote: >>> On Oct 8, 2012, at 8:24 PM, Shane Bryzak wrote: >>> >>>> The reason I advised that we base the JPA implementation on Seam's >>>> JpaIdentityStore was not one to do with pride, but because its design >>>> has been shaped by many years of developer feedback. I've got no >>>> problem with Pedro's code (I think it's quite good actually) >>>> however the >>>> design fails to address a number of requirements. Let's go through a >>>> few of them in more detail: >>>> >>>> 1. Hard coded entities >>>> >>>> This is a problem for a number of reasons. First and foremost, it >>>> doesn't allow a developer to BYO schema. Many projects share user >>>> databases, or are based on legacy systems that cannot be modified. >>>> There may be strict naming conventions in place for table and column >>>> names. It might be simply the case that the developer needs to model >>>> their schema in a particular way to meet certain business >>>> requirements. >>>> Whatever the reason, it is very clear that we cannot dictate the >>>> database schema to the developer. We can certainly make >>>> recommendations, however this should be done via documentation, and >>>> possibly in an example. >>> I'd like to see actual numbers on greenfield vs BYO - because if >>> flexibility means complexity, we need to assure that we're not >>> hurting 95% because of the 5% >>> >>> from my **anedoctal experience**, when adopting a framework, ppl >>> allow for some small changes to accomodate, granted they are small. >> This flexibility actually allows us to *simplify* the schema, >> believe it >> or not. A developer who wants the absolute most basic features is able >> to create a single database table to store just user, credential and >> attribute information, something they cannot do if we dictate the >> schema >> to them. >> >>>> 2. Partitioning >>>> >>>> This also stems from having a hard coded schema. Many projects may >>>> require users to authenticate against an LDAP directory, but >>>> authorize >>>> against a database. One of the great ideas from Bolek's original >>>> PLIDM >>>> implementation was that of FeatureSets, basically metadata which >>>> reflects which identity management capabilities a particular >>>> IdentityStore implementation supports. It allows us to store >>>> users in >>>> one identity store, and group and role memberships in another. Also, >>>> what happens when an application wants to be purely LDAP based, does >>>> Hibernate still try to create (or expect the existence of) the >>>> corresponding tables for the hard coded entity beans? What if >>>> there is >>>> no database? >>>> >>>> 3. Caching >>>> >>>> This particular feature isn't present in Seam, however the intent >>>> is to >>>> support it in PicketLink. To summarise, rather than creating a new >>>> User, Group or Role instance (or their various memberships) every >>>> single >>>> time the IdentityStore would normally need to do this, we use a >>>> single >>>> cache (distributed in the case of clustered applications) to store >>>> these >>>> identity objects and perform the lookup from the cache instead. This >>>> isn't possible to achieve when we have hard coded entities that >>>> implement the identity model interfaces. This feature requires an >>>> intricate coupling between IdentityManager, IdentityStore and the >>>> cache >>>> implementation. >>>> >>>> 4. CDI awareness >>>> >>>> We need to develop this module so that it will run in an SE >>>> environment >>>> so that the AS team (and others) can use it, however we need to also >>>> keep in mind that we need to integrate it with CDI, and the design >>>> should reflect that. JPACallback and JPATemplate seem to add >>>> unnecessary complexity which in the end still boils down to one >>>> EntityManager instance per JPAIdentityStore. I honestly think the >>>> JPAIdentityStore implementation should be stateless, in that one >>>> instance can service multiple (concurrent) requests (not to >>>> mention that >>>> configuration is an expensive operation). We also need to also >>>> keep in >>>> mind that the EntityManager could have any type of scope, with the >>>> most >>>> obvious ones being request or conversation scoped. >>>> >>>> I'm happy to discuss these further, however I hope that it's >>>> convinced >>>> everyone that we need to reconsider the current design. >>>> >>>> Shane >>>> >>>> >>>> On 09/10/12 02:30, Anil Saldhana wrote: >>>>> I want to offer continued discussion on the JPA implementation in >>>>> the >>>>> IDM project. >>>>> >>>>> The work that Pedro did is restored here in the following workspace: >>>>> https://github.com/picketlink/picketlink-idm-restored >>>>> >>>>> A testcase that is useful for JPA implementation in IDM is: >>>>> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >>>>> >>>>> >>>>> It is the exact mirror of the LDAP implementation: >>>>> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >>>>> >>>>> >>>>> These two implementations have very minimal user configuration. >>>>> >>>>> The challenge is when users bring in complex database schemas and >>>>> LDAP >>>>> DITs into operation. But the goal of balancing complexity with >>>>> usability is a tough one. >>>>> >>>>> On 09/06/2012 10:13 AM, Anil Saldhana wrote: >>>>>> Similar challenges exist for LDAP bindings also, since user LDAP >>>>>> DITs >>>>>> may be different. But we have to balance complexity with >>>>>> usability. :) >>>>>> >>>>>> On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: >>>>>>> Ok. I'll take a look how he took care of that. >>>>>>> >>>>>>> Regards. >>>>>>> Pedro Igor >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >>>>>>> To: security-dev(a)lists.jboss.org >>>>>>> Sent: Wednesday, September 5, 2012 6:52:35 PM >>>>>>> Subject: [security-dev] PicketLink IDM JPA Identity Store >>>>>>> >>>>>>> Pedro, >>>>>>> Shane just referred me to the following: >>>>>>> >>>>>>> https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... >>>>>>> >>>>>>> >>>>>>> Can you adapt your work to incorporate all facets of this Seam >>>>>>> work? >>>>>>> Shane says users have varying db schema structures and the JPA >>>>>>> implementation in seam3 took care of the nuances. >>>>>>> >>>>>>> Regards, >>>>>>> Anil >>>>>>> >>>>> _______________________________________________ >>>>> 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 >>> -- qmx

And we need the simple schema implementation for authentication purposes and minimal configuration.

Hi Shane, I think I understood what you have in mind. We can have some entities mapped/configured using seam2/3 approach to provide a ready-to-use schema. Am I right ? If so, let's start something around that. And use just one jpa store instead. I agree that will be much more easier to maintain. Regards. Pedro Igor ----- Original Message ----- From: "Shane Bryzak" <sbryzak(a)redhat.com&gt; To: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; Cc: security-dev(a)lists.jboss.org Sent: Tuesday, October 9, 2012 4:49:19 PM Subject: Re: [security-dev] PicketLink IDM JPA Identity Store If the goal is to make available a simple schema for just some developers that wanted it, the best way to do this is to provide an additional, optional jar file containing just the simple schema entity beans (call it picketlink-idm-defaultschema or something like this) rather than provide an entirely new implementation. This way we avoid the burden of having to maintain two implementations, and also avoid the aforementioned problem of having unwanted entity beans in the distribution for developers that don't want to use the simple schema. On 09/10/12 23:25, Anil Saldhana wrote: > I think we really need 2 implementations based on JPA and ldap each. > One implementation supports the simple/fixed schema approach and the > other implementation should be fully configurable/customizable schema > driven implementation. The configuration builders define the > implementation that is returned to the user. > > I am not game for one size fits all implementation that will send brains > in a roller coaster for simple usecases. > > On 10/08/2012 07:06 PM, Shane Bryzak wrote: >> On 09/10/12 09:54, Douglas Campos wrote: >>> On Oct 8, 2012, at 8:24 PM, Shane Bryzak wrote: >>> >>>> The reason I advised that we base the JPA implementation on Seam's >>>> JpaIdentityStore was not one to do with pride, but because its design >>>> has been shaped by many years of developer feedback. I've got no >>>> problem with Pedro's code (I think it's quite good actually) however the >>>> design fails to address a number of requirements. Let's go through a >>>> few of them in more detail: >>>> >>>> 1. Hard coded entities >>>> >>>> This is a problem for a number of reasons. First and foremost, it >>>> doesn't allow a developer to BYO schema. Many projects share user >>>> databases, or are based on legacy systems that cannot be modified. >>>> There may be strict naming conventions in place for table and column >>>> names. It might be simply the case that the developer needs to model >>>> their schema in a particular way to meet certain business requirements. >>>> Whatever the reason, it is very clear that we cannot dictate the >>>> database schema to the developer. We can certainly make >>>> recommendations, however this should be done via documentation, and >>>> possibly in an example. >>> I'd like to see actual numbers on greenfield vs BYO - because if flexibility means complexity, we need to assure that we're not hurting 95% because of the 5% >>> >>> from my **anedoctal experience**, when adopting a framework, ppl allow for some small changes to accomodate, granted they are small. >> This flexibility actually allows us to *simplify* the schema, believe it >> or not. A developer who wants the absolute most basic features is able >> to create a single database table to store just user, credential and >> attribute information, something they cannot do if we dictate the schema >> to them. >> >>>> 2. Partitioning >>>> >>>> This also stems from having a hard coded schema. Many projects may >>>> require users to authenticate against an LDAP directory, but authorize >>>> against a database. One of the great ideas from Bolek's original PLIDM >>>> implementation was that of FeatureSets, basically metadata which >>>> reflects which identity management capabilities a particular >>>> IdentityStore implementation supports. It allows us to store users in >>>> one identity store, and group and role memberships in another. Also, >>>> what happens when an application wants to be purely LDAP based, does >>>> Hibernate still try to create (or expect the existence of) the >>>> corresponding tables for the hard coded entity beans? What if there is >>>> no database? >>>> >>>> 3. Caching >>>> >>>> This particular feature isn't present in Seam, however the intent is to >>>> support it in PicketLink. To summarise, rather than creating a new >>>> User, Group or Role instance (or their various memberships) every single >>>> time the IdentityStore would normally need to do this, we use a single >>>> cache (distributed in the case of clustered applications) to store these >>>> identity objects and perform the lookup from the cache instead. This >>>> isn't possible to achieve when we have hard coded entities that >>>> implement the identity model interfaces. This feature requires an >>>> intricate coupling between IdentityManager, IdentityStore and the cache >>>> implementation. >>>> >>>> 4. CDI awareness >>>> >>>> We need to develop this module so that it will run in an SE environment >>>> so that the AS team (and others) can use it, however we need to also >>>> keep in mind that we need to integrate it with CDI, and the design >>>> should reflect that. JPACallback and JPATemplate seem to add >>>> unnecessary complexity which in the end still boils down to one >>>> EntityManager instance per JPAIdentityStore. I honestly think the >>>> JPAIdentityStore implementation should be stateless, in that one >>>> instance can service multiple (concurrent) requests (not to mention that >>>> configuration is an expensive operation). We also need to also keep in >>>> mind that the EntityManager could have any type of scope, with the most >>>> obvious ones being request or conversation scoped. >>>> >>>> I'm happy to discuss these further, however I hope that it's convinced >>>> everyone that we need to reconsider the current design. >>>> >>>> Shane >>>> >>>> >>>> On 09/10/12 02:30, Anil Saldhana wrote: >>>>> I want to offer continued discussion on the JPA implementation in the >>>>> IDM project. >>>>> >>>>> The work that Pedro did is restored here in the following workspace: >>>>> https://github.com/picketlink/picketlink-idm-restored >>>>> >>>>> A testcase that is useful for JPA implementation in IDM is: >>>>> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >>>>> >>>>> It is the exact mirror of the LDAP implementation: >>>>> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >>>>> >>>>> These two implementations have very minimal user configuration. >>>>> >>>>> The challenge is when users bring in complex database schemas and LDAP >>>>> DITs into operation. But the goal of balancing complexity with >>>>> usability is a tough one. >>>>> >>>>> On 09/06/2012 10:13 AM, Anil Saldhana wrote: >>>>>> Similar challenges exist for LDAP bindings also, since user LDAP DITs >>>>>> may be different. But we have to balance complexity with usability. :) >>>>>> >>>>>> On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: >>>>>>> Ok. I'll take a look how he took care of that. >>>>>>> >>>>>>> Regards. >>>>>>> Pedro Igor >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >>>>>>> To: security-dev(a)lists.jboss.org >>>>>>> Sent: Wednesday, September 5, 2012 6:52:35 PM >>>>>>> Subject: [security-dev] PicketLink IDM JPA Identity Store >>>>>>> >>>>>>> Pedro, >>>>>>> Shane just referred me to the following: >>>>>>> >>>>>>> https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... >>>>>>> >>>>>>> Can you adapt your work to incorporate all facets of this Seam work? >>>>>>> Shane says users have varying db schema structures and the JPA >>>>>>> implementation in seam3 took care of the nuances. >>>>>>> >>>>>>> Regards, >>>>>>> Anil >>>>>>> >>>>> _______________________________________________ >>>>> 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 >>> -- qmx >>> >> _______________________________________________ >> 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

Since we have Pedro's simple implementation someplace, lets work out how his work (as a separate jar) can get integrated. It is probably via an auxiliary maven release. On 10/09/2012 03:16 PM, Shane Bryzak wrote: > That's exactly right. If the developer wants to use the default, simple > schema they just include the extra jar in their project, no additional > configuration necessary. > > On 10/10/12 06:09, Pedro Igor Silva wrote: >> Hi Shane, >> >> I think I understood what you have in mind. We can have some entities mapped/configured using seam2/3 approach to provide a ready-to-use schema. Am I right ? >> >> If so, let's start something around that. And use just one jpa store instead. I agree that will be much more easier to maintain. >> >> Regards. >> Pedro Igor >> >> ----- Original Message ----- >> From: "Shane Bryzak" <sbryzak(a)redhat.com&gt; >> To: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >> Cc: security-dev(a)lists.jboss.org >> Sent: Tuesday, October 9, 2012 4:49:19 PM >> Subject: Re: [security-dev] PicketLink IDM JPA Identity Store >> >> If the goal is to make available a simple schema for just some >> developers that wanted it, the best way to do this is to provide an >> additional, optional jar file containing just the simple schema entity >> beans (call it picketlink-idm-defaultschema or something like this) >> rather than provide an entirely new implementation. This way we avoid >> the burden of having to maintain two implementations, and also avoid the >> aforementioned problem of having unwanted entity beans in the >> distribution for developers that don't want to use the simple schema. >> >> On 09/10/12 23:25, Anil Saldhana wrote: >>> I think we really need 2 implementations based on JPA and ldap each. >>> One implementation supports the simple/fixed schema approach and the >>> other implementation should be fully configurable/customizable schema >>> driven implementation. The configuration builders define the >>> implementation that is returned to the user. >>> >>> I am not game for one size fits all implementation that will send brains >>> in a roller coaster for simple usecases. >>> >>> On 10/08/2012 07:06 PM, Shane Bryzak wrote: >>>> On 09/10/12 09:54, Douglas Campos wrote: >>>>> On Oct 8, 2012, at 8:24 PM, Shane Bryzak wrote: >>>>> >>>>>> The reason I advised that we base the JPA implementation on Seam's >>>>>> JpaIdentityStore was not one to do with pride, but because its design >>>>>> has been shaped by many years of developer feedback. I've got no >>>>>> problem with Pedro's code (I think it's quite good actually) however the >>>>>> design fails to address a number of requirements. Let's go through a >>>>>> few of them in more detail: >>>>>> >>>>>> 1. Hard coded entities >>>>>> >>>>>> This is a problem for a number of reasons. First and foremost, it >>>>>> doesn't allow a developer to BYO schema. Many projects share user >>>>>> databases, or are based on legacy systems that cannot be modified. >>>>>> There may be strict naming conventions in place for table and column >>>>>> names. It might be simply the case that the developer needs to model >>>>>> their schema in a particular way to meet certain business requirements. >>>>>> Whatever the reason, it is very clear that we cannot dictate the >>>>>> database schema to the developer. We can certainly make >>>>>> recommendations, however this should be done via documentation, and >>>>>> possibly in an example. >>>>> I'd like to see actual numbers on greenfield vs BYO - because if flexibility means complexity, we need to assure that we're not hurting 95% because of the 5% >>>>> >>>>> from my **anedoctal experience**, when adopting a framework, ppl allow for some small changes to accomodate, granted they are small. >>>> This flexibility actually allows us to *simplify* the schema, believe it >>>> or not. A developer who wants the absolute most basic features is able >>>> to create a single database table to store just user, credential and >>>> attribute information, something they cannot do if we dictate the schema >>>> to them. >>>> >>>>>> 2. Partitioning >>>>>> >>>>>> This also stems from having a hard coded schema. Many projects may >>>>>> require users to authenticate against an LDAP directory, but authorize >>>>>> against a database. One of the great ideas from Bolek's original PLIDM >>>>>> implementation was that of FeatureSets, basically metadata which >>>>>> reflects which identity management capabilities a particular >>>>>> IdentityStore implementation supports. It allows us to store users in >>>>>> one identity store, and group and role memberships in another. Also, >>>>>> what happens when an application wants to be purely LDAP based, does >>>>>> Hibernate still try to create (or expect the existence of) the >>>>>> corresponding tables for the hard coded entity beans? What if there is >>>>>> no database? >>>>>> >>>>>> 3. Caching >>>>>> >>>>>> This particular feature isn't present in Seam, however the intent is to >>>>>> support it in PicketLink. To summarise, rather than creating a new >>>>>> User, Group or Role instance (or their various memberships) every single >>>>>> time the IdentityStore would normally need to do this, we use a single >>>>>> cache (distributed in the case of clustered applications) to store these >>>>>> identity objects and perform the lookup from the cache instead. This >>>>>> isn't possible to achieve when we have hard coded entities that >>>>>> implement the identity model interfaces. This feature requires an >>>>>> intricate coupling between IdentityManager, IdentityStore and the cache >>>>>> implementation. >>>>>> >>>>>> 4. CDI awareness >>>>>> >>>>>> We need to develop this module so that it will run in an SE environment >>>>>> so that the AS team (and others) can use it, however we need to also >>>>>> keep in mind that we need to integrate it with CDI, and the design >>>>>> should reflect that. JPACallback and JPATemplate seem to add >>>>>> unnecessary complexity which in the end still boils down to one >>>>>> EntityManager instance per JPAIdentityStore. I honestly think the >>>>>> JPAIdentityStore implementation should be stateless, in that one >>>>>> instance can service multiple (concurrent) requests (not to mention that >>>>>> configuration is an expensive operation). We also need to also keep in >>>>>> mind that the EntityManager could have any type of scope, with the most >>>>>> obvious ones being request or conversation scoped. >>>>>> >>>>>> I'm happy to discuss these further, however I hope that it's convinced >>>>>> everyone that we need to reconsider the current design. >>>>>> >>>>>> Shane >>>>>> >>>>>> >>>>>> On 09/10/12 02:30, Anil Saldhana wrote: >>>>>>> I want to offer continued discussion on the JPA implementation in the >>>>>>> IDM project. >>>>>>> >>>>>>> The work that Pedro did is restored here in the following workspace: >>>>>>> https://github.com/picketlink/picketlink-idm-restored >>>>>>> >>>>>>> A testcase that is useful for JPA implementation in IDM is: >>>>>>> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >>>>>>> >>>>>>> It is the exact mirror of the LDAP implementation: >>>>>>> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >>>>>>> >>>>>>> These two implementations have very minimal user configuration. >>>>>>> >>>>>>> The challenge is when users bring in complex database schemas and LDAP >>>>>>> DITs into operation. But the goal of balancing complexity with >>>>>>> usability is a tough one. >>>>>>> >>>>>>> On 09/06/2012 10:13 AM, Anil Saldhana wrote: >>>>>>>> Similar challenges exist for LDAP bindings also, since user LDAP DITs >>>>>>>> may be different. But we have to balance complexity with usability. :) >>>>>>>> >>>>>>>> On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: >>>>>>>>> Ok. I'll take a look how he took care of that. >>>>>>>>> >>>>>>>>> Regards. >>>>>>>>> Pedro Igor >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >>>>>>>>> To: security-dev(a)lists.jboss.org >>>>>>>>> Sent: Wednesday, September 5, 2012 6:52:35 PM >>>>>>>>> Subject: [security-dev] PicketLink IDM JPA Identity Store >>>>>>>>> >>>>>>>>> Pedro, >>>>>>>>> Shane just referred me to the following: >>>>>>>>> >>>>>>>>> https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... >>>>>>>>> >>>>>>>>> Can you adapt your work to incorporate all facets of this Seam work? >>>>>>>>> Shane says users have varying db schema structures and the JPA >>>>>>>>> implementation in seam3 took care of the nuances. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Anil >>>>>>>>> >>>>>>>>> _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

On Oct 9, 2012, at 4:49 PM, Shane Bryzak wrote: > If the goal is to make available a simple schema for just some > developers that wanted it, the best way to do this is to provide an > additional, optional jar file containing just the simple schema entity > beans (call it picketlink-idm-defaultschema or something like this) > rather than provide an entirely new implementation. This way we avoid > the burden of having to maintain two implementations, and also avoid the > aforementioned problem of having unwanted entity beans in the > distribution for developers that don't want to use the simple schema. So we go from complex to simple? Did you mean the opposite?

> On 09/10/12 23:25, Anil Saldhana wrote: >> I think we really need 2 implementations based on JPA and ldap each. >> One implementation supports the simple/fixed schema approach and the >> other implementation should be fully configurable/customizable schema >> driven implementation. The configuration builders define the >> implementation that is returned to the user. >> >> I am not game for one size fits all implementation that will send brains >> in a roller coaster for simple usecases. >> >> On 10/08/2012 07:06 PM, Shane Bryzak wrote: >>> On 09/10/12 09:54, Douglas Campos wrote: >>>> On Oct 8, 2012, at 8:24 PM, Shane Bryzak wrote: >>>> >>>>> The reason I advised that we base the JPA implementation on Seam's >>>>> JpaIdentityStore was not one to do with pride, but because its design >>>>> has been shaped by many years of developer feedback. I've got no >>>>> problem with Pedro's code (I think it's quite good actually) however the >>>>> design fails to address a number of requirements. Let's go through a >>>>> few of them in more detail: >>>>> >>>>> 1. Hard coded entities >>>>> >>>>> This is a problem for a number of reasons. First and foremost, it >>>>> doesn't allow a developer to BYO schema. Many projects share user >>>>> databases, or are based on legacy systems that cannot be modified. >>>>> There may be strict naming conventions in place for table and column >>>>> names. It might be simply the case that the developer needs to model >>>>> their schema in a particular way to meet certain business requirements. >>>>> Whatever the reason, it is very clear that we cannot dictate the >>>>> database schema to the developer. We can certainly make >>>>> recommendations, however this should be done via documentation, and >>>>> possibly in an example. >>>> I'd like to see actual numbers on greenfield vs BYO - because if flexibility means complexity, we need to assure that we're not hurting 95% because of the 5% >>>> >>>> from my **anedoctal experience**, when adopting a framework, ppl allow for some small changes to accomodate, granted they are small. >>> This flexibility actually allows us to *simplify* the schema, believe it >>> or not. A developer who wants the absolute most basic features is able >>> to create a single database table to store just user, credential and >>> attribute information, something they cannot do if we dictate the schema >>> to them. >>> >>>>> 2. Partitioning >>>>> >>>>> This also stems from having a hard coded schema. Many projects may >>>>> require users to authenticate against an LDAP directory, but authorize >>>>> against a database. One of the great ideas from Bolek's original PLIDM >>>>> implementation was that of FeatureSets, basically metadata which >>>>> reflects which identity management capabilities a particular >>>>> IdentityStore implementation supports. It allows us to store users in >>>>> one identity store, and group and role memberships in another. Also, >>>>> what happens when an application wants to be purely LDAP based, does >>>>> Hibernate still try to create (or expect the existence of) the >>>>> corresponding tables for the hard coded entity beans? What if there is >>>>> no database? >>>>> >>>>> 3. Caching >>>>> >>>>> This particular feature isn't present in Seam, however the intent is to >>>>> support it in PicketLink. To summarise, rather than creating a new >>>>> User, Group or Role instance (or their various memberships) every single >>>>> time the IdentityStore would normally need to do this, we use a single >>>>> cache (distributed in the case of clustered applications) to store these >>>>> identity objects and perform the lookup from the cache instead. This >>>>> isn't possible to achieve when we have hard coded entities that >>>>> implement the identity model interfaces. This feature requires an >>>>> intricate coupling between IdentityManager, IdentityStore and the cache >>>>> implementation. >>>>> >>>>> 4. CDI awareness >>>>> >>>>> We need to develop this module so that it will run in an SE environment >>>>> so that the AS team (and others) can use it, however we need to also >>>>> keep in mind that we need to integrate it with CDI, and the design >>>>> should reflect that. JPACallback and JPATemplate seem to add >>>>> unnecessary complexity which in the end still boils down to one >>>>> EntityManager instance per JPAIdentityStore. I honestly think the >>>>> JPAIdentityStore implementation should be stateless, in that one >>>>> instance can service multiple (concurrent) requests (not to mention that >>>>> configuration is an expensive operation). We also need to also keep in >>>>> mind that the EntityManager could have any type of scope, with the most >>>>> obvious ones being request or conversation scoped. >>>>> >>>>> I'm happy to discuss these further, however I hope that it's convinced >>>>> everyone that we need to reconsider the current design. >>>>> >>>>> Shane >>>>> >>>>> >>>>> On 09/10/12 02:30, Anil Saldhana wrote: >>>>>> I want to offer continued discussion on the JPA implementation in the >>>>>> IDM project. >>>>>> >>>>>> The work that Pedro did is restored here in the following workspace: >>>>>> https://github.com/picketlink/picketlink-idm-restored >>>>>> >>>>>> A testcase that is useful for JPA implementation in IDM is: >>>>>> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >>>>>> >>>>>> It is the exact mirror of the LDAP implementation: >>>>>> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >>>>>> >>>>>> These two implementations have very minimal user configuration. >>>>>> >>>>>> The challenge is when users bring in complex database schemas and LDAP >>>>>> DITs into operation. But the goal of balancing complexity with >>>>>> usability is a tough one. >>>>>> >>>>>> On 09/06/2012 10:13 AM, Anil Saldhana wrote: >>>>>>> Similar challenges exist for LDAP bindings also, since user LDAP DITs >>>>>>> may be different. But we have to balance complexity with usability. :) >>>>>>> >>>>>>> On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: >>>>>>>> Ok. I'll take a look how he took care of that. >>>>>>>> >>>>>>>> Regards. >>>>>>>> Pedro Igor >>>>>>>> >>>>>>>> ----- Original Message ----- >>>>>>>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >>>>>>>> To: security-dev(a)lists.jboss.org >>>>>>>> Sent: Wednesday, September 5, 2012 6:52:35 PM >>>>>>>> Subject: [security-dev] PicketLink IDM JPA Identity Store >>>>>>>> >>>>>>>> Pedro, >>>>>>>> Shane just referred me to the following: >>>>>>>> >>>>>>>> https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... >>>>>>>> >>>>>>>> Can you adapt your work to incorporate all facets of this Seam work? >>>>>>>> Shane says users have varying db schema structures and the JPA >>>>>>>> implementation in seam3 took care of the nuances. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Anil >>>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> -- qmx >>>> >>> _______________________________________________ >>> 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 -- qmx

On 10/10/12 08:05, Douglas Campos wrote: > On Oct 9, 2012, at 4:49 PM, Shane Bryzak wrote: > >> If the goal is to make available a simple schema for just some >> developers that wanted it, the best way to do this is to provide an >> additional, optional jar file containing just the simple schema entity >> beans (call it picketlink-idm-defaultschema or something like this) >> rather than provide an entirely new implementation. This way we avoid >> the burden of having to maintain two implementations, and also avoid the >> aforementioned problem of having unwanted entity beans in the >> distribution for developers that don't want to use the simple schema. > So we go from complex to simple? Did you mean the opposite? I don't understand the question, sorry?

On 11/10/12 00:22, Douglas Campos wrote: > On Oct 9, 2012, at 7:52 PM, Shane Bryzak wrote: > >> On 10/10/12 08:05, Douglas Campos wrote: >>> On Oct 9, 2012, at 4:49 PM, Shane Bryzak wrote: >>> >>>> If the goal is to make available a simple schema for just some >>>> developers that wanted it, the best way to do this is to provide an >>>> additional, optional jar file containing just the simple schema entity >>>> beans (call it picketlink-idm-defaultschema or something like this) >>>> rather than provide an entirely new implementation. This way we avoid >>>> the burden of having to maintain two implementations, and also avoid the >>>> aforementioned problem of having unwanted entity beans in the >>>> distribution for developers that don't want to use the simple schema. >>> So we go from complex to simple? Did you mean the opposite? >> I don't understand the question, sorry? > Optional jar file for the simple schema? shouldn't it be the opposite? > > No no - the point I've been (seemingly unsuccessfully) trying to make is that we *must not* include any entity beans by default. If we did it would cause a multitude of problems for our users. If we do want to provide a default schema that some of our users *may* elect to use instead of providing their own, it must be in a separate jar file. _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

In AS7/EAP6 I'd be less concerned about the entities and more concerned about the datasource definition. Would we ship a jar with the referenced datasource to satisfy the app boot or make the users configure it via the annotations when you get the persistence context, or worse make them unpack the jar, modify the persistence.xml then repack? The easiest thing IMO is to have the entities in the jar w/o any persistence.xml and make the users add the classes to their own persistence.xml. If that's what everyone was thinking before, sorry for the spam.

Sent from my iPhone On Oct 11, 2012, at 8:54, Pete Muir <pmuir(a)redhat.com&gt; wrote: > Shane, can you elaborate on why we can't package the entity beans in the main jar, but make them only enabled optionally (e.g. via the applications persistence.xml)? > > On 10 Oct 2012, at 21:07, Shane Bryzak wrote: > >> On 11/10/12 00:22, Douglas Campos wrote: >>> On Oct 9, 2012, at 7:52 PM, Shane Bryzak wrote: >>> >>>> On 10/10/12 08:05, Douglas Campos wrote: >>>>> On Oct 9, 2012, at 4:49 PM, Shane Bryzak wrote: >>>>> >>>>>> If the goal is to make available a simple schema for just some >>>>>> developers that wanted it, the best way to do this is to provide an >>>>>> additional, optional jar file containing just the simple schema entity >>>>>> beans (call it picketlink-idm-defaultschema or something like this) >>>>>> rather than provide an entirely new implementation. This way we avoid >>>>>> the burden of having to maintain two implementations, and also avoid the >>>>>> aforementioned problem of having unwanted entity beans in the >>>>>> distribution for developers that don't want to use the simple schema. >>>>> So we go from complex to simple? Did you mean the opposite? >>>> I don't understand the question, sorry? >>> Optional jar file for the simple schema? shouldn't it be the opposite? >>> >>> >> >> No no - the point I've been (seemingly unsuccessfully) trying to make is >> that we *must not* include any entity beans by default. If we did it >> would cause a multitude of problems for our users. If we do want to >> provide a default schema that some of our users *may* elect to use >> instead of providing their own, it must be in a separate jar file. >> _______________________________________________ >> 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

Sure - the biggest problem with this relates to configuration. We use processAnnotatedType() to pick up the entity beans and perform automatic configuration during the startup process. To do this, obviously the entity beans must be in a bean archive with a beans.xml - but we can't put a beans.xml in the main jar file as it may not have any dependency on CDI. Since we have producer methods (and other configuration related code) for the main IDM module beans in the core module, we cannot just place a beans.xml in the IDM module, (which by itself wouldn't require a hard dependency on the CDI jar library) because we would then get deployment errors for ambiguous injection points. The easiest solution for this is to simply place the entity beans for the default schema in their own separate jar file, which contains a beans.xml. This way, it can be used both in an SE environment and a JEE environment without any problems. On 12/10/12 00:54, Pete Muir wrote: > Shane, can you elaborate on why we can't package the entity beans in the main jar, but make them only enabled optionally (e.g. via the applications persistence.xml)? > > On 10 Oct 2012, at 21:07, Shane Bryzak wrote: > >> On 11/10/12 00:22, Douglas Campos wrote: >>> On Oct 9, 2012, at 7:52 PM, Shane Bryzak wrote: >>> >>>> On 10/10/12 08:05, Douglas Campos wrote: >>>>> On Oct 9, 2012, at 4:49 PM, Shane Bryzak wrote: >>>>> >>>>>> If the goal is to make available a simple schema for just some >>>>>> developers that wanted it, the best way to do this is to provide an >>>>>> additional, optional jar file containing just the simple schema entity >>>>>> beans (call it picketlink-idm-defaultschema or something like this) >>>>>> rather than provide an entirely new implementation. This way we avoid >>>>>> the burden of having to maintain two implementations, and also avoid the >>>>>> aforementioned problem of having unwanted entity beans in the >>>>>> distribution for developers that don't want to use the simple schema. >>>>> So we go from complex to simple? Did you mean the opposite? >>>> I don't understand the question, sorry? >>> Optional jar file for the simple schema? shouldn't it be the opposite? >>> >>> >> No no - the point I've been (seemingly unsuccessfully) trying to make is >> that we *must not* include any entity beans by default. If we did it >> would cause a multitude of problems for our users. If we do want to >> provide a default schema that some of our users *may* elect to use >> instead of providing their own, it must be in a separate jar file. >> _______________________________________________ >> 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 Oct 8, 2012, at 8:24 PM, Shane Bryzak wrote: > The reason I advised that we base the JPA implementation on Seam's > JpaIdentityStore was not one to do with pride, but because its design > has been shaped by many years of developer feedback. I've got no > problem with Pedro's code (I think it's quite good actually) however the > design fails to address a number of requirements. Let's go through a > few of them in more detail: > > 1. Hard coded entities > > This is a problem for a number of reasons. First and foremost, it > doesn't allow a developer to BYO schema. Many projects share user > databases, or are based on legacy systems that cannot be modified. > There may be strict naming conventions in place for table and column > names. It might be simply the case that the developer needs to model > their schema in a particular way to meet certain business requirements. > Whatever the reason, it is very clear that we cannot dictate the > database schema to the developer. We can certainly make > recommendations, however this should be done via documentation, and > possibly in an example. I'd like to see actual numbers on greenfield vs BYO - because if flexibility means complexity, we need to assure that we're not hurting 95% because of the 5% from my **anedoctal experience**, when adopting a framework, ppl allow for some small changes to accomodate, granted they are small. > > 2. Partitioning > > This also stems from having a hard coded schema. Many projects may > require users to authenticate against an LDAP directory, but authorize > against a database. One of the great ideas from Bolek's original PLIDM > implementation was that of FeatureSets, basically metadata which > reflects which identity management capabilities a particular > IdentityStore implementation supports. It allows us to store users in > one identity store, and group and role memberships in another. Also, > what happens when an application wants to be purely LDAP based, does > Hibernate still try to create (or expect the existence of) the > corresponding tables for the hard coded entity beans? What if there is > no database? > > 3. Caching > > This particular feature isn't present in Seam, however the intent is to > support it in PicketLink. To summarise, rather than creating a new > User, Group or Role instance (or their various memberships) every single > time the IdentityStore would normally need to do this, we use a single > cache (distributed in the case of clustered applications) to store these > identity objects and perform the lookup from the cache instead. This > isn't possible to achieve when we have hard coded entities that > implement the identity model interfaces. This feature requires an > intricate coupling between IdentityManager, IdentityStore and the cache > implementation. > > 4. CDI awareness > > We need to develop this module so that it will run in an SE environment > so that the AS team (and others) can use it, however we need to also > keep in mind that we need to integrate it with CDI, and the design > should reflect that. JPACallback and JPATemplate seem to add > unnecessary complexity which in the end still boils down to one > EntityManager instance per JPAIdentityStore. I honestly think the > JPAIdentityStore implementation should be stateless, in that one > instance can service multiple (concurrent) requests (not to mention that > configuration is an expensive operation). We also need to also keep in > mind that the EntityManager could have any type of scope, with the most > obvious ones being request or conversation scoped. > > I'm happy to discuss these further, however I hope that it's convinced > everyone that we need to reconsider the current design. > > Shane > > > On 09/10/12 02:30, Anil Saldhana wrote: >> I want to offer continued discussion on the JPA implementation in the >> IDM project. >> >> The work that Pedro did is restored here in the following workspace: >> https://github.com/picketlink/picketlink-idm-restored >> >> A testcase that is useful for JPA implementation in IDM is: >> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >> >> It is the exact mirror of the LDAP implementation: >> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/sr... >> >> These two implementations have very minimal user configuration. >> >> The challenge is when users bring in complex database schemas and LDAP >> DITs into operation. But the goal of balancing complexity with >> usability is a tough one. >> >> On 09/06/2012 10:13 AM, Anil Saldhana wrote: >>> Similar challenges exist for LDAP bindings also, since user LDAP DITs >>> may be different. But we have to balance complexity with usability. :) >>> >>> On 09/06/2012 07:37 AM, Pedro Igor Silva wrote: >>>> Ok. I'll take a look how he took care of that. >>>> >>>> Regards. >>>> Pedro Igor >>>> >>>> ----- Original Message ----- >>>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >>>> To: security-dev(a)lists.jboss.org >>>> Sent: Wednesday, September 5, 2012 6:52:35 PM >>>> Subject: [security-dev] PicketLink IDM JPA Identity Store >>>> >>>> Pedro, >>>> Shane just referred me to the following: >>>> >>>> https://github.com/seam/security/blob/develop/impl/src/main/java/org/jbos... >>>> >>>> Can you adapt your work to incorporate all facets of this Seam work? >>>> Shane says users have varying db schema structures and the JPA >>>> implementation in seam3 took care of the nuances. >>>> >>>> Regards, >>>> Anil >>>> >> _______________________________________________ >> 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 -- qmx _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev