Re: [keycloak-dev] implement JPA model
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