5:25 p.m.
Bill,
Shane and Pedro have aimed to support your requirements because it
introduces multitenancy
aspects into the IDM. From that angle, your model is not a simple model
as you claim. :) The PicketLink
team has listened patiently few months ago to your requirements and is
willing to patiently make your use cases work.
Also below:
On 11/05/2013 11:06 AM, Bill Burke wrote:
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.
What happens when a particular deployment does not have a DB
supporting
JPA?
Users want ldap or file or HDFS or mongo backed storage.
* 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.
Maybe you need something like GlusterFS. :) Our
File system store
implementation is Read Write.
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.
IDM = Identity Management. Managing CRUD of
identities backed by different
stores (DB, LDAP, File etc). So IDM API = API for CRUD of identities.
Typically
applications require to model Users/Roles/Groups. We provide that.
Applications
want an API to CRUD U/R/G. This is what IDM API aims to do. We did
introduce the
concept of Partition/Tiers etc after listening to your requirements.
I just feel that rather than looking at the model holistically, you are
getting sucked into
the storage aspects. As Pedro said, we should be able to take your JPA
model and plug
into the PL IDM model. What is stopping is your reluctance to give us
the opportunity to
explore that. :)
The PicketLink team supports KeyCloak and wants to see it successful. We
do not want to
hinder your release cycles. But give us an opportunity to take your
model and plug into IDM.