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

[Bill Burke]

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.


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