From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 15 July, 2014 8:59:24 PM Subject: [keycloak-dev] UserProvider merged * ModelProvider renamed to RealmProvider * All user related methods except for credential validation removed from RealmModel * KeycloakSession.users() gets you a UserProvider * All classes now use UserProvider to work with users. * KeycloakSession.model() renamed to realms() * There are two cache providers now. One for realms, other for users. TODO: * JPA UserRoleMappingEntity and UserEntity still have @ManyToOne to RoleEntity and RealmEntity respectively. Do we want to keep these constraints?

* JPA and Mongo RealmEntity and UserEntity should be refactored to be attribute based as in the Hybrid model. As Stian suggested, this will allow us flexibility in the future.

* Credential validation, update needs to move from RealmModel to UserProvider. I'll do this tomorrow. -- 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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 16 July, 2014 1:27:21 PM Subject: Re: [keycloak-dev] UserProvider merged On 7/16/2014 4:23 AM, Stian Thorgersen wrote: >> * JPA and Mongo RealmEntity and UserEntity should be refactored to be >> attribute based as in the Hybrid model. As Stian suggested, this will >> allow us flexibility in the future. > > I'd also like to have a generic configuration mechanism for providers. This > would include being able to store configuration as well as change it > through the admin console. > > Potentially something I could work on while you guys do sync? > This would overlap with sync refactor. Just a thought, except for our base LDAP support, would we want generic config mechanism in admin console? What if user needs something more than name/value pairs for config?

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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 16 July, 2014 1:59:51 PM Subject: Re: [keycloak-dev] UserProvider merged On 7/16/2014 8:47 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)lists.jboss.org >> Sent: Wednesday, 16 July, 2014 1:27:21 PM >> Subject: Re: [keycloak-dev] UserProvider merged >> >> >> >> On 7/16/2014 4:23 AM, Stian Thorgersen wrote: >>>> * JPA and Mongo RealmEntity and UserEntity should be refactored to be >>>> attribute based as in the Hybrid model. As Stian suggested, this will >>>> allow us flexibility in the future. >>> >>> I'd also like to have a generic configuration mechanism for providers. >>> This >>> would include being able to store configuration as well as change it >>> through the admin console. >>> >>> Potentially something I could work on while you guys do sync? >>> >> >> This would overlap with sync refactor. Just a thought, except for our >> base LDAP support, would we want generic config mechanism in admin >> console? What if user needs something more than name/value pairs for >> config? > Re-reading what you wrote, maybe I misunderstood? You want a generic way to store and manage keycloak-server.json through admin console? > Generic config mechanism for sync you mean? > Yes. I think sync is in two parts: * A UserProvider. For on-demand sync. * A "chron job" for periodic bulk sync. Both would want generic config mechanism and realm-specific storage for this config. > I was thinking it would be nice to have something available to all SPIs and > providers. Name/value pairs would be simplest with regards to storing and > also editing through the admin console. > What are the security implications of this in a multi-tenant environment? Might not want a specific realm admin to be able to modify keycloak-server.json What about just allowing user to enter in Json? -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 16 July, 2014 2:25:36 PM Subject: Re: [keycloak-dev] UserProvider merged On 7/16/2014 9:08 AM, Stian Thorgersen wrote: > The idea for provider config was: > > A provider can have a server-wide config (keycloak-server.json) as well as > realm-specific configs. > > Server-wide config would at least initially be configured only through > keycloak-server.json and would also require a server restart. We could > look at making this configurable through admin console as well. > > Realm specific config would be configurable through the admin console. You > would go to a "Providers" tab in the admin console, then you'd have a menu > that lists out all SPIs. So you would for example click on Sync. You could > then configure which Sync providers are enabled for the Realm, as well as > set configuration for them. With regards to config I thought key/value > would be sufficient, and much simpler to deal with. > > With that regards it would probably make sense that KeycloakSession would > be bound to a specific realm so we could create Provider instances with > the correct config. > Don't you have a Catch 22 with KeycloakSession and RealmProvider?

For sync/federation I was thinking that KeycloakSession.users() would take a RealmModel parameter though. Maybe something like this for an SPI? interface RealmLoadedProviderFactory<T extends Provider> { T createProvider(KeycloakSession session, RealmModel realm); } -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com