[keycloak-dev] implement JPA model

[Bill Burke]

On 11/5/2013 6:25 PM, Anil Saldhana wrote:
> 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. :)

multitenancy does not make the data model complex.  Keycloak security 
model is very small compared to the average persistence requirements of 
persistence applications.

> 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?

Ridiculous point.  Hibernate supports all popular RDBMS.  BTW, what 
happens when PL ends up re-creating Hibernate to implement your JDBC 
backend?  Because you have no concrete security data model that's 
exactly what you'll end up doing...

> Users want ldap or file or HDFS or mongo backed storage.

Considering PL doesn't have a HDFS or Mongo backend and your file-based 
one is kinda fucked up, I fail to see your point...FYI, we already have 
our own custom mongo backend.

>> * 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.

Please re-read what I wrote about file backed storage.  Your statement 
makes zero sense.

>>
>> 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.
>

Again, you've developed a persistence mapping solution, not a security 
solution.  I know exactly what PL does, because, well, I was knee deep 
in the code for weeks.

> 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. :)
>

Anil.  For the hundredth time...We *ALREADY* have a Picketlink backend, 
that works, for our model.  We're replacing it as the default backend 
because we do not want to be dependent on PL release cycles or blocker 
bugs and because we feel that we can scale it better if we're not tied 
to a completely generic programming model.  We will bring back 
Picketlink as the default back-end if it makes sense and brings value.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com