[security-dev] PicketLink IDM JPA Identity Store

[Shane Bryzak]

On 09/10/12 09:54, Douglas Campos 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.

This flexibility actually allows us to *simplify* the schema, believe it 
or not.  A developer who wants the absolute most basic features is able 
to create a single database table to store just user, credential and 
attribute information, something they cannot do if we dictate the schema 
to them.

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