[security-dev] PicketLink IDM JPA Identity Store

Mon Oct 8 19:34:23 EDT 2012

I'll give a big +1 to Shane's arguments here.

Making the JPA IdentityStore as flexible wrt entities is absolutely key for
adoption. The partitioning aspect is probably very common in larger
organizations, I simply haven't come across it.

On Mon, Oct 8, 2012 at 5:24 PM, Shane Bryzak <sbryzak at redhat.com> 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.
>
> 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
>

-- 
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/52b0e1ec/attachment-0001.html 