[keycloak-dev] triple abstraction?

[Stian Thorgersen]

I thought we where at an agreement with splitting the model. If that's not the case, and to be able to actually do a release sometime soon, I propose we just revert back to how it was before.

For argument sake the benefits for this split include:

* Users are what we need to federate, this split makes that a lot simpler IMO
* Users are what people may want to store in their own schema, again this makes it a lot simpler IMO
* Can store different things in different store types. For example realms in a json file, users in a relational database and sessions in a in-mem data-grid
* Realms store can be changed if we need to. Relative quick and easy to export/import to update.
* Users store shouldn't be changed frequently. Updating a database with 20 million entries is non-trivial
* Model was getting pretty big and complex, with loads of tables. Splitting makes it simpler IMO

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 8 July, 2014 4:39:02 PM
> Subject: Re: [keycloak-dev] triple abstraction?
> 
> 
> 
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Tuesday, 8 July, 2014 4:29:03 PM
> > Subject: Re: [keycloak-dev] triple abstraction?
> > 
> > 
> > 
> > On 7/8/2014 11:16 AM, Stian Thorgersen wrote:
> > > Dropping Hybrid API sounds like pretty much undoing all the work I've
> > > done
> > > the last couple weeks :(
> > >
> > 
> > I honestly have some serious concerns that this split will solve much.
> > See my previous email.
> 
> Which email?
> 
> > 
> > > IMO what we should do is to drop the Model API/SPI. Instead make it into
> > > a
> > > single implementation that delegates to the various providers
> > > (RealmProvider, UserProvider, SessionProvider and probably also
> > > CacheProvider). We can then merge this with RealmManager,
> > > ApplicationManager, etc. and instead have a single ModelManager.
> > >
> > > I don't think it's a good idea to make the UserProvider create
> > > RoleModels.
> > > The UserProvider should be as simple as possible IMO, and shouldn't deal
> > > with Realms, Apps, Roles, etc, other than through simple id's.
> > >
> > 
> > That's not what I said.  UserProvider may have to map between an
> > existing static user role mapping in some existing LDAP store to a role
> > defined in Keycloak.  It may be impossible to map one to one a Keycloak
> > role id and the role mapping stored in the customer's user database.
> 
> Sure, I assumed the UserProvider would do that by returning the id of the
> Keycloak role it maps to.
> 
> > 
> > Federating an existing user store is pretty hard to do even with the
> > current split.  Not only does the UserProvider make some pretty steep
> > assumptions, tts pretty hard, IMO, to understand exactly where
> > AuthenticationProvider begins and the UserProvider takes over, or the
> > relationship between the two.
> 
> See my previous email where I proposed that AuthenticationProvider could be
> dropped and replaced by a delegating UserProvider with the same
> functionality.
> 
> > 
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>