[security-dev] PicketLink IDM JPA Identity Store

[Shane Bryzak]

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