I'll give a big +1 to Shane's arguments here. <div><br></div><div>Making the JPA IdentityStore as flexible wrt entities is absolutely key for adoption. The partitioning aspect is probably very common in larger organizations, I simply haven't come across it.<br>
<br><div class="gmail_quote">On Mon, Oct 8, 2012 at 5:24 PM, Shane Bryzak <span dir="ltr"><<a href="mailto:sbryzak@redhat.com" target="_blank">sbryzak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The reason I advised that we base the JPA implementation on Seam's<br>
JpaIdentityStore was not one to do with pride, but because its design<br>
has been shaped by many years of developer feedback. I've got no<br>
problem with Pedro's code (I think it's quite good actually) however the<br>
design fails to address a number of requirements. Let's go through a<br>
few of them in more detail:<br>
<br>
1. Hard coded entities<br>
<br>
This is a problem for a number of reasons. First and foremost, it<br>
doesn't allow a developer to BYO schema. Many projects share user<br>
databases, or are based on legacy systems that cannot be modified.<br>
There may be strict naming conventions in place for table and column<br>
names. It might be simply the case that the developer needs to model<br>
their schema in a particular way to meet certain business requirements.<br>
Whatever the reason, it is very clear that we cannot dictate the<br>
database schema to the developer. We can certainly make<br>
recommendations, however this should be done via documentation, and<br>
possibly in an example.<br>
<br>
2. Partitioning<br>
<br>
This also stems from having a hard coded schema. Many projects may<br>
require users to authenticate against an LDAP directory, but authorize<br>
against a database. One of the great ideas from Bolek's original PLIDM<br>
implementation was that of FeatureSets, basically metadata which<br>
reflects which identity management capabilities a particular<br>
IdentityStore implementation supports. It allows us to store users in<br>
one identity store, and group and role memberships in another. Also,<br>
what happens when an application wants to be purely LDAP based, does<br>
Hibernate still try to create (or expect the existence of) the<br>
corresponding tables for the hard coded entity beans? What if there is<br>
no database?<br>
<br>
3. Caching<br>
<br>
This particular feature isn't present in Seam, however the intent is to<br>
support it in PicketLink. To summarise, rather than creating a new<br>
User, Group or Role instance (or their various memberships) every single<br>
time the IdentityStore would normally need to do this, we use a single<br>
cache (distributed in the case of clustered applications) to store these<br>
identity objects and perform the lookup from the cache instead. This<br>
isn't possible to achieve when we have hard coded entities that<br>
implement the identity model interfaces. This feature requires an<br>
intricate coupling between IdentityManager, IdentityStore and the cache<br>
implementation.<br>
<br>
4. CDI awareness<br>
<br>
We need to develop this module so that it will run in an SE environment<br>
so that the AS team (and others) can use it, however we need to also<br>
keep in mind that we need to integrate it with CDI, and the design<br>
should reflect that. JPACallback and JPATemplate seem to add<br>
unnecessary complexity which in the end still boils down to one<br>
EntityManager instance per JPAIdentityStore. I honestly think the<br>
JPAIdentityStore implementation should be stateless, in that one<br>
instance can service multiple (concurrent) requests (not to mention that<br>
configuration is an expensive operation). We also need to also keep in<br>
mind that the EntityManager could have any type of scope, with the most<br>
obvious ones being request or conversation scoped.<br>
<br>
I'm happy to discuss these further, however I hope that it's convinced<br>
everyone that we need to reconsider the current design.<br>
<span class="HOEnZb"><font color="#888888"><br>
Shane<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On 09/10/12 02:30, Anil Saldhana wrote:<br>
> I want to offer continued discussion on the JPA implementation in the<br>
> IDM project.<br>
><br>
> The work that Pedro did is restored here in the following workspace:<br>
> <a href="https://github.com/picketlink/picketlink-idm-restored" target="_blank">https://github.com/picketlink/picketlink-idm-restored</a><br>
><br>
> A testcase that is useful for JPA implementation in IDM is:<br>
> <a href="https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/src/test/java/org/picketlink/test/idm/internal/mgr/DefaultJPAIdentityManagerTestCase.java" target="_blank">https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/src/test/java/org/picketlink/test/idm/internal/mgr/DefaultJPAIdentityManagerTestCase.java</a><br>
><br>
> It is the exact mirror of the LDAP implementation:<br>
> <a href="https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/src/test/java/org/picketlink/test/idm/internal/mgr/DefaultLDAPIdentityManagerTestCase.java" target="_blank">https://github.com/picketlink/picketlink-idm-restored/blob/master/impl/src/test/java/org/picketlink/test/idm/internal/mgr/DefaultLDAPIdentityManagerTestCase.java</a><br>
><br>
> These two implementations have very minimal user configuration.<br>
><br>
> The challenge is when users bring in complex database schemas and LDAP<br>
> DITs into operation. But the goal of balancing complexity with<br>
> usability is a tough one.<br>
><br>
> On 09/06/2012 10:13 AM, Anil Saldhana wrote:<br>
>> Similar challenges exist for LDAP bindings also, since user LDAP DITs<br>
>> may be different. But we have to balance complexity with usability. :)<br>
>><br>
>> On 09/06/2012 07:37 AM, Pedro Igor Silva wrote:<br>
>>> Ok. I'll take a look how he took care of that.<br>
>>><br>
>>> Regards.<br>
>>> Pedro Igor<br>
>>><br>
>>> ----- Original Message -----<br>
>>> From: "Anil Saldhana" <<a href="mailto:Anil.Saldhana@redhat.com">Anil.Saldhana@redhat.com</a>><br>
>>> To: <a href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a><br>
>>> Sent: Wednesday, September 5, 2012 6:52:35 PM<br>
>>> Subject: [security-dev] PicketLink IDM JPA Identity Store<br>
>>><br>
>>> Pedro,<br>
>>> Shane just referred me to the following:<br>
>>><br>
>>> <a href="https://github.com/seam/security/blob/develop/impl/src/main/java/org/jboss/seam/security/management/picketlink/JpaIdentityStore.java" target="_blank">https://github.com/seam/security/blob/develop/impl/src/main/java/org/jboss/seam/security/management/picketlink/JpaIdentityStore.java</a><br>
>>><br>
>>> Can you adapt your work to incorporate all facets of this Seam work?<br>
>>> Shane says users have varying db schema structures and the JPA<br>
>>> implementation in seam3 took care of the nuances.<br>
>>><br>
>>> Regards,<br>
>>> Anil<br>
>>><br>
> _______________________________________________<br>
> security-dev mailing list<br>
> <a href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/security-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/security-dev</a><br>
<br>
<br>
_______________________________________________<br>
security-dev mailing list<br>
<a href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/security-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/security-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Jason Porter<br><a href="http://lightguard-jp.blogspot.com" target="_blank">http://lightguard-jp.blogspot.com</a><br><a href="http://twitter.com/lightguardjp" target="_blank">http://twitter.com/lightguardjp</a><br>
<br>Software Engineer<br>Open Source Advocate<br>Author of Seam Catch - Next Generation Java Exception Handling<br><br>PGP key id: 926CCFF5<br>PGP key available at: <a href="http://keyserver.net" target="_blank">keyserver.net</a>, <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a><br>
</div>