[security-dev] PicketLink IDM JPA Identity Store

Tue Oct 9 09:32:32 EDT 2012

----- Original Message -----
> From: "Shane Bryzak" <sbryzak at redhat.com>
> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
> Cc: security-dev at lists.jboss.org
> Sent: Monday, October 8, 2012 8:24:12 PM
> Subject: Re: [security-dev] PicketLink IDM JPA Identity Store
> 
> 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 agree with you regarding the BYO schema. As listed on the side notes, that is a item that need to be considered.

The actual impl is very useful for users that do not have a defined schema and do not want to worry about defining one. There are people that simply wants a ready to use model and worry only about their business.

> 
> 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.

Actually, the JPAIdentityStore can be stateful and stateless. I agree with you that stateless is always the best option here.

Just to give you an example, we are using the the actual JPAIdentityStore using a custom JPATemplate that uses CDI to get the current EntityManager instance to be used. Making the JPAIdentityStore stateless.

    https://github.com/pedroigor/picketbox-cdi/blob/master/src/main/java/org/picketbox/cdi/idm/DefaultJPATemplate.java

Another motivation behind the JPATemplate stuff is make the code more cleaner and flexible. It simplifies the use of JPA, helps to avoid common errors and let custom implementations dictate how the EntityManager is used/retrieved by the JPAIdentityStore.

> 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
> 