[security-dev] PicketLink IDM JPA Identity Store

Tue Oct 9 18:05:51 EDT 2012

On Oct 9, 2012, at 4:49 PM, Shane Bryzak wrote:

> If the goal is to make available a simple schema for just some 
> developers that wanted it, the best way to do this is to provide an 
> additional, optional jar file containing just the simple schema entity 
> beans (call it picketlink-idm-defaultschema or something like this) 
> rather than provide an entirely new implementation.  This way we avoid 
> the burden of having to maintain two implementations, and also avoid the 
> aforementioned problem of having unwanted entity beans in the 
> distribution for developers that don't want to use the simple schema.
So we go from complex to simple? Did you mean the opposite?

> 
> On 09/10/12 23:25, Anil Saldhana wrote:
>> 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
>> _______________________________________________
>> 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