Re: [keycloak-dev] Remaining work and who does what for beta-4

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 5:24:58 PM Subject: Re: [keycloak-dev] Remaining work and who does what for beta-4 On 7/16/2014 12:04 PM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Wednesday, 16 July, 2014 4:12:51 PM >> Subject: Re: [keycloak-dev] Remaining work and who does what for beta-4 >> >> >> >> On 7/16/2014 10:12 AM, Stian Thorgersen wrote: >>> Now that the craziness of splitting the model is behind us I think we >>> should figure out exactly what's left to do for beta-4, who's doing what >>> and an estimated release date. >>> >>> Here's the list of things I can come up with: >>> >>> 1. JPA UserRoleMappingEntity and UserEntity still have @ManyToOne to >>> RoleEntity and RealmEntity respectively. >>> 2. JPA and Mongo RealmEntity and UserEntity should be refactored to be >>> attribute based as in the Hybrid model. >>> 3. Credential validation, update needs to move from RealmModel to >>> UserProvider. >>> 4. Sync support in UserProvider >>> 5. LDAP implementation for 4 >>> 6. Access code work (reducing code size, email link size, single-use >>> code, >>> etc.) >>> 7. Pagination support for users >>> 8. Improve delete of users >>> >>> My vote is yes to all above! >>> >>> Also, a couple of things we should consider: >>> >>> 9. Add generic configuration for providers, including the ability to >>> configure any providers through the admin console >>> 10. Have KeycloakSession bound to a specific realm >>> >> >> I'm working on 1-5 and 8. I think I can be done in 5-7 business days. >> 1-3, 8 are really easy, at least for JPA. Was going to copy what stian >> did for Hybrid for attribute queries. >> >> -1 for #10. We need per-realm providers probably for everything, but >> RealmProvider. 4 and 5 will be impacted by per-realm UserProvider. #5 >> will be a refactoring of Marek's current code to fit model we've been >> discussing for #4. > > I probably agree with regards to #10. Maybe instead providers can either be > global or per-realm? > I think it ties into #9. See below: >> >> IMO, #9 comes in 2 parts. 1st part is a generic Config per-realm >> storage. 2nd is Provider config through admin console. > > Can you elaborate on what you mean about config per-realm storage? > interface RealmModel { org.keycloak.Config getProviderConfig(); } I thought that was what you were proposing. There would need to be a non-static and write interface for Config though. Then KeycloakSession changes: Provider getProvider(Realm realm, Class providerClass); getProvider() grabs Config.Scope from the RealmModel for the provider and creates a ProviderFactory per realm. Just a thought. Maybe it can't work in practice.

>> >> I vote Stian does #6 and #9. Marek finishes 7 and looks into LDAP >> changelogs. There's also a few bugs/enhancements here and there still >> in JIRA. > > Sounds good. > > I've already started 7 and I'm almost done. Basically just copying what I > did for pagination of sessions. > Yeah, I hope to have 1-3, and 8 done by the time you wake up tomorrow.

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