On Mon, Oct 8, 2012 at 5:54 PM, Douglas Campos <span dir="ltr"><<a href="mailto:qmx@redhat.com" target="_blank">qmx@redhat.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Oct 8, 2012, at 8:24 PM, Shane Bryzak wrote:<br>
<br>
> 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>
</div>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%<br>
<br>
from my **anedoctal experience**, when adopting a framework, ppl allow for some small changes to accomodate, granted they are small.<br></blockquote><div><br></div><div>From those looking to migrate from Seam 2 to Seam 3 when we first rolled out Seam 3 the fact that the entities had to be coded and in a specific schema was one of the largest issues with Persistence. I agree it adds complexity, but I think it's one of those things that we simply need to do.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">><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>
><br>
> Shane<br>
><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>
<br>
</div></div>-- qmx<br>
<div class="HOEnZb"><div class="h5"><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>