[security-dev] PicketLink IDM JPA Identity Store

[Douglas Campos]

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