[keycloak-dev] implement JPA model

[Bill Burke]

On 11/5/2013 11:30 AM, Anil Saldhana wrote:
> On 11/05/2013 07:06 AM, Bill Burke wrote:
>> Pedro, with all due respect, we already use Picketlink.  What we're
>> doing is swapping it out until there is an advantage to use it again.
>> Right now there are only disadvantages and the fact it can't run in
>> Wildfly is a blocker.  I'll be committing the JPA model later today.
> We are updating WildFly with the PicketLink subsystem that contains IDM
> configuration, this week. Can you please provide a list of disadvantages
> of using PicketLink? A lot of people/teams collaborated on the subsystem
> design. It will be beneficial if KeyCloak can wait a bit on the PL. Give
> us a chance. :)

Disadvantages:
* Performance.  can tweak more performance with a back-end that is 
specific to our metamodel.
* Bolek seems to think importing and syncing with LDAP/AD is a better 
approach than federating LDAP/AD directly.  An approach you just don't 
support and probably won't support for a long time.
* PL IDM API requires upfront declaration of federation model.

But its more of lack of advantages:
* With PL-JPA, I have to define JPA entities *ANYWAYS*.  So, instead, 
avoid the complexity (and bugs) of PL and just implement our own 
datamodel in JPA.  Simpler, easier to maintain.  Something that is more 
proven and reliable.
* PL-File plugin isn't very useful (or usable considering it doesn't 
suport transactions).  Only reason we'd want a file-based storage would 
be to have a human-readable readonly-file specific to our data model so 
admins could edit it directly.

Honestly, the PL_IDM_API vision and architecture scares me a bit.  its 
not a security solution, its a persistence mapping solution.  An 
immature persistence mapping solution.  If I wanted a federated 
persistence solution, why wouldn't I just use Teiid?  And work with 
Teiid to make it more consumable?  Combine this doubt with random 
blocker bugs that pop up makes me want to retire our PL backend until it 
makes sense to bring in back in.
-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com