[security-dev] PicketLink IDM JPA Identity Store

Mon Oct 8 20:05:29 EDT 2012

On Mon, Oct 8, 2012 at 5:54 PM, Douglas Campos <qmx at redhat.com> 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.
>

>From those looking to migrate from Seam 2 to Seam 3 when we first rolled
out Seam 3 the fact that the entities had to be coded and in a specific
schema was one of the largest issues with Persistence. I agree it adds
complexity, but I think it's one of those things that we simply need to do.

> >
> > 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/src/test/java/org/picketlink/test/idm/internal/mgr/DefaultJPAIdentityManagerTestCase.java
> >>
> >> It is the exact mirror of the LDAP implementation:
> >>
> https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/src/test/java/org/picketlink/test/idm/internal/mgr/DefaultLDAPIdentityManagerTestCase.java
> >>
> >> 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 at redhat.com>
> >>>> To: security-dev at 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/jboss/seam/security/management/picketlink/JpaIdentityStore.java
> >>>>
> >>>> 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/security-dev
> >
> >
> > _______________________________________________
> > security-dev mailing list
> > security-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/security-dev
>
> -- qmx
>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20121008/36deafd9/attachment.html 