Re: [security-dev] PicketLink IDM JPA Identity Store

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