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

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at 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 at redhat.com>
> >> To: keycloak-dev at 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.

Something like that could work. I'll think about it some more tomorrow ;) 

> 
> 
> >>
> >> 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.

I get up at 6am! Not by personal choice :(

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