[security-dev] PicketLink IDM JPA Identity Store

Tue Oct 9 16:01:16 EDT 2012

I think Pedro should talk about the JPA side of the house since he 
understands
it better than me. :)  Atleast on the LDAP side, we need a simple 
implementation
and an extensible one.

On 10/09/2012 02:55 PM, Anil Saldhana wrote:
> Shane,
>     we do not have to look at outside users.  PicketBox Core has a hard
> dependency on PL IDM now. And we need the simple schema implementation
> for authentication purposes and minimal configuration. :)
>
> I support the extensibility/configurability demands from developers who
> consume the IDM API. I am just saying that we need to additionally ship
> the simple implementations (JPA and LDAP) to get at least our internal
> JBoss projects going, since they have lower demands for
> extensibility(byo schemas).
>
> Regards,
> Anil
>
> On 10/09/2012 02: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.
>>
>> 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