[security-dev] PicketLink IDM JPA Identity Store

Tue Oct 9 18:52:41 EDT 2012

On 10/10/12 08:05, Douglas Campos wrote:
> 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?

I don't understand the question, sorry?

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