[keycloak-dev] implement JPA model

[Anil Saldhana]

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.