11:01 a.m.
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(a)redhat.com>
To: "Bill Burke" <bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 8 July, 2014 4:39:02 PM
Subject: Re: [keycloak-dev] triple abstraction?
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev