[security-dev] PicketLink IDM JPA Identity Store

Wed Oct 10 16:09:06 EDT 2012

That's easy, we just package Pedro's entity beans in their own submodule 
alongside the PLIDM api and impl modules.

On 11/10/12 00:49, Anil Saldhana wrote:
> Since we have Pedro's simple implementation someplace, lets work out how
> his work (as a separate jar) can get integrated. It is probably via an
> auxiliary maven release.
>
> On 10/09/2012 03:16 PM, Shane Bryzak wrote:
>> That's exactly right.  If the developer wants to use the default, simple
>> schema they just include the extra jar in their project, no additional
>> configuration necessary.
>>
>> On 10/10/12 06:09, Pedro Igor Silva wrote:
>>> Hi Shane,
>>>
>>>        I think I understood what you have in mind. We can have some entities mapped/configured using seam2/3 approach to provide a ready-to-use schema. Am I right ?
>>>
>>>        If so, let's start something around that. And use just one jpa store instead. I agree that will be much more easier to maintain.
>>>
>>> Regards.
>>> Pedro Igor
>>>
>>> ----- Original Message -----
>>> From: "Shane Bryzak" <sbryzak at redhat.com>
>>> To: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>>> Cc: security-dev at lists.jboss.org
>>> Sent: Tuesday, October 9, 2012 4:49:19 PM
>>> Subject: Re: [security-dev] PicketLink IDM JPA Identity Store
>>>
>>> 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.
>>>
>>> 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