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