[security-dev] PicketLink IDM JPA Identity Store

Tue Oct 9 09:25:02 EDT 2012

I think we really need 2 implementations based on JPA and ldap each.  
One implementation supports the simple/fixed schema approach and the 
other implementation should be fully configurable/customizable schema 
driven implementation.  The configuration builders define the 
implementation that is returned to the user.

I am not game for one size fits all implementation that will send brains 
in a roller coaster for simple usecases.

On 10/08/2012 07:06 PM, Shane Bryzak wrote:
> 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
>>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev