9:12 a.m.
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
My suggestion is:
* Bill - works on sync support in UserSession
* Marek - works on LDAP implementation for sync
* Stian - I can either get started on 9 and 10, or scrape of the rest. Depends on whether
or not we decide to do them or not.
If we're going to have a chance of releasing 1.0.final in August, I think we should
aim at having beta-4 (with an actual code freeze!) towards the end of July. We'll need
at least 1 month to do tests, security audit, update docs, etc.
Also, I'm away 13 days and Marek is away 8 days in August!
10:12 a.m.
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.
IMO, #9 comes in 2 parts. 1st part is a generic Config per-realm
storage. 2nd is Provider config through admin console.
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.
Also, I'm away 13 days and Marek is away 8 days in August!
I'm away last week of August.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
11:04 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
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?
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?
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.
> Also, I'm away 13 days and Marek is away 8 days in August!
I'm away last week of August.
--
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
11:24 a.m.
On 7/16/2014 12:04 PM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> 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
12:04 p.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
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>
>> 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.
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
3816
days inactive
3816
days old
4 comments
2 participants
participants (2)
-
Bill Burke -
Stian Thorgersen