9:05 p.m.
I reviewed Marek's code. The refactor is going to be pretty much
Marek's code except reorganized a little bit. Hopefully you can follow
what I'm saying. I'll try and follow up with code in a few days.
* AuthProvider is going to turn into FederationProvider which is an
extension of UserProvider
public interface FederationProvider extends UserProvider {
String getAdminPage();
Class<? extends FederatonAdmin> getAdminClass();
UserModel proxy(UserModel localUser);
}
* AuthenticationProviderManager is going to turn into a concrete class
which implements UserProvider, FederationManager. It will basically do
the same algorithm as AuthProviderManager for finding users (looping
through the realm's configured FederationProviders), except it will be
using the UserProvider interface and returning UserModels.
- UserModel getXXX() methods will search within "local" storage first
for a user.
- If exists, it will look at the UserModel.getProvider() attribute to
learn which provider to use. Then call FederationProvider.proxy()
method. This will allow the FederationProvider to proxy the UserModel
so it can perform on demand sync.
* KeycloakSession will allocate a FederationManager and wrap it with a
CacheUserProvider instead of getting the "local" user storage provider.
* LDAP/Picketlink code will turn into a set of abstract classes used to
build the LDAPFederationProvider.
- getXXX will try to locate in LDAP store. If exists, it will import
the user into the "local" storage UserModel. It will create a proxy to
this local storage. This proxy will allow on-demand sync.
Configuration:
* AuthentiationProviderModel will be renamed to FederationProviderModel.
RealmModel will also return a list of these
* LDAP code will not use Realm.getLdapConfig(). It will instead use
FederationProviderModel config.
Management:
* Federation configuration will move from the Realm Settings page, to
the Users page.
* getAdminPage and getAdminClass exist so that FederationProvider
plugins can plug-in their own admin console UI and REST API.
* FederationProvider.getAdminPage() will point to a admin console path.
When adding a FederationProvider, the admin console will load this
page for setup/config.
* The FederationProvider.getAdminClass() method will return a JAX-RS
resource locator class that implements
interface FederationAdmin {
void setAdmin(UserModel admin);
void setSession(Keycloak session);
void setRealm(RealmModel realm);
}
* The admin class will be instantiated when invoking REST calls to
.../realms/{realm}/users/providers/{provider-name}/...
That's it in a nutshell. I haven't implemented any of this, its just in
my head and there's probably a lot of details I've overlooked that I'll
figure out when I code.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
4:05 p.m.
One thing I'm not sure what do do is getUserCount(). can't really get
an accurate user count in a federated environment. I see this is only
used by export? Probably not an issue as export would only use local
Keycloak storage.
On 7/18/2014 10:05 PM, Bill Burke wrote:
I reviewed Marek's code. The refactor is going to be pretty
much
Marek's code except reorganized a little bit. Hopefully you can follow
what I'm saying. I'll try and follow up with code in a few days.
* AuthProvider is going to turn into FederationProvider which is an
extension of UserProvider
public interface FederationProvider extends UserProvider {
String getAdminPage();
Class<? extends FederatonAdmin> getAdminClass();
UserModel proxy(UserModel localUser);
}
* AuthenticationProviderManager is going to turn into a concrete class
which implements UserProvider, FederationManager. It will basically do
the same algorithm as AuthProviderManager for finding users (looping
through the realm's configured FederationProviders), except it will be
using the UserProvider interface and returning UserModels.
- UserModel getXXX() methods will search within "local" storage first
for a user.
- If exists, it will look at the UserModel.getProvider() attribute to
learn which provider to use. Then call FederationProvider.proxy()
method. This will allow the FederationProvider to proxy the UserModel
so it can perform on demand sync.
* KeycloakSession will allocate a FederationManager and wrap it with a
CacheUserProvider instead of getting the "local" user storage provider.
* LDAP/Picketlink code will turn into a set of abstract classes used to
build the LDAPFederationProvider.
- getXXX will try to locate in LDAP store. If exists, it will import
the user into the "local" storage UserModel. It will create a proxy to
this local storage. This proxy will allow on-demand sync.
Configuration:
* AuthentiationProviderModel will be renamed to FederationProviderModel.
RealmModel will also return a list of these
* LDAP code will not use Realm.getLdapConfig(). It will instead use
FederationProviderModel config.
Management:
* Federation configuration will move from the Realm Settings page, to
the Users page.
* getAdminPage and getAdminClass exist so that FederationProvider
plugins can plug-in their own admin console UI and REST API.
* FederationProvider.getAdminPage() will point to a admin console path.
When adding a FederationProvider, the admin console will load this
page for setup/config.
* The FederationProvider.getAdminClass() method will return a JAX-RS
resource locator class that implements
interface FederationAdmin {
void setAdmin(UserModel admin);
void setSession(Keycloak session);
void setRealm(RealmModel realm);
}
* The admin class will be instantiated when invoking REST calls to
.../realms/{realm}/users/providers/{provider-name}/...
That's it in a nutshell. I haven't implemented any of this, its just in
my head and there's probably a lot of details I've overlooked that I'll
figure out when I code.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3:34 a.m.
I am not sure I understand why "getUserCount" is an issue and for
example "getUsers" or "searchForUser" is not? Am I understand
correctly
that implementor of FederationProvider can choose which method to
override, so for example if he won't override "getUsers" or
"getUserCount" then FederationManager just delegates those to "local"
UserProvider?
If getUserCount() is an issue, I can remove it and refactor export to
not using it and instead use approach like: "checkout users until
current page is not full", which would mean that there are no more users
to export (Like for example if I have 50 users and usersPerPage is 20,
then page1 has 20 users, page2 has 20 users and page3 has just 10 users,
so export process can recognize that it is last page).
But still getUserCount() may be useful if we later want to add
pagination support to admin console (in this case, we may need "count"
methods also for searchFor** -
https://issues.jboss.org/browse/KEYCLOAK-564 )
Marek
On 20.7.2014 23:05, Bill Burke wrote:
One thing I'm not sure what do do is getUserCount(). can't
really get
an accurate user count in a federated environment. I see this is only
used by export? Probably not an issue as export would only use local
Keycloak storage.
On 7/18/2014 10:05 PM, Bill Burke wrote:
> I reviewed Marek's code. The refactor is going to be pretty much
> Marek's code except reorganized a little bit. Hopefully you can follow
> what I'm saying. I'll try and follow up with code in a few days.
>
> * AuthProvider is going to turn into FederationProvider which is an
> extension of UserProvider
>
> public interface FederationProvider extends UserProvider {
> String getAdminPage();
> Class<? extends FederatonAdmin> getAdminClass();
> UserModel proxy(UserModel localUser);
> }
>
> * AuthenticationProviderManager is going to turn into a concrete class
> which implements UserProvider, FederationManager. It will basically do
> the same algorithm as AuthProviderManager for finding users (looping
> through the realm's configured FederationProviders), except it will be
> using the UserProvider interface and returning UserModels.
> - UserModel getXXX() methods will search within "local" storage first
> for a user.
> - If exists, it will look at the UserModel.getProvider() attribute to
> learn which provider to use. Then call FederationProvider.proxy()
> method. This will allow the FederationProvider to proxy the UserModel
> so it can perform on demand sync.
>
> * KeycloakSession will allocate a FederationManager and wrap it with a
> CacheUserProvider instead of getting the "local" user storage provider.
>
> * LDAP/Picketlink code will turn into a set of abstract classes used to
> build the LDAPFederationProvider.
> - getXXX will try to locate in LDAP store. If exists, it will import
> the user into the "local" storage UserModel. It will create a proxy to
> this local storage. This proxy will allow on-demand sync.
>
> Configuration:
>
> * AuthentiationProviderModel will be renamed to FederationProviderModel.
> RealmModel will also return a list of these
> * LDAP code will not use Realm.getLdapConfig(). It will instead use
> FederationProviderModel config.
>
> Management:
>
> * Federation configuration will move from the Realm Settings page, to
> the Users page.
> * getAdminPage and getAdminClass exist so that FederationProvider
> plugins can plug-in their own admin console UI and REST API.
> * FederationProvider.getAdminPage() will point to a admin console path.
> When adding a FederationProvider, the admin console will load this
> page for setup/config.
> * The FederationProvider.getAdminClass() method will return a JAX-RS
> resource locator class that implements
>
> interface FederationAdmin {
> void setAdmin(UserModel admin);
> void setSession(Keycloak session);
> void setRealm(RealmModel realm);
> }
> * The admin class will be instantiated when invoking REST calls to
> .../realms/{realm}/users/providers/{provider-name}/...
>
> That's it in a nutshell. I haven't implemented any of this, its just in
> my head and there's probably a lot of details I've overlooked that I'll
> figure out when I code.
>
>
>
8:46 a.m.
for getUsers/search, I can do a union of local storage and external
storage. For getUserCount I can't do this as I would have to iterate
over every UserModel, which defeats the purpose of optimized, 1-query,
getUserCount.
On 7/21/2014 4:34 AM, Marek Posolda wrote:
I am not sure I understand why "getUserCount" is an issue
and for
example "getUsers" or "searchForUser" is not? Am I understand
correctly
that implementor of FederationProvider can choose which method to
override, so for example if he won't override "getUsers" or
"getUserCount" then FederationManager just delegates those to
"local"
UserProvider?
If getUserCount() is an issue, I can remove it and refactor export to
not using it and instead use approach like
It is not an issue as only export uses it. Export will only be
exporting local storage.
: "checkout users until
current page is not full", which would mean that there are no more users
to export (Like for example if I have 50 users and usersPerPage is 20,
then page1 has 20 users, page2 has 20 users and page3 has just 10 users,
so export process can recognize that it is last page).
But still getUserCount() may be useful if we later want to add
pagination support to admin console (in this case, we may need "count"
methods also for searchFor** -
https://issues.jboss.org/browse/KEYCLOAK-564 )
Don't need a count, just if size() < maxRequested, you know you're at
the end.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
9:49 a.m.
On 21.7.2014 15:46, Bill Burke wrote:
for getUsers/search, I can do a union of local storage and external
storage.
hmm... I wonder about the case when you have data like this:
- User "john", which was synced from LDAP to local UserProvider and
hence now is in both LDAP and local UserProvider
- User "local_foo" which was registered just locally in Keycloak and not
available in LDAP
- User "ldap_foo" which was recently added directly to LDAP and not yet
synced in Keycloak ldap UserProvider
So now when admin invokes UserProvider.getUsers() it should return him 3
users like: "john", "local_foo", "ldap_foo"
But if I understand correctly, with union it returns 4 users like:
"john", "john", "local_foo", "ldap_foo", because
user "john" is in both.
So how to handle this? Merge both "john" users just during this call?
Does it scale when we have 10K users in LDAP and 10K users in local
UserProvider (some shared, some just in either LDAP or local provider)?
Personally I don't believe that federation will scale well here...
For getUserCount I can't do this as I would have to iterate over
every
UserModel, which defeats the purpose of optimized, 1-query, getUserCount.
On 7/21/2014 4:34 AM, Marek Posolda wrote:
> I am not sure I understand why "getUserCount" is an issue and for
> example "getUsers" or "searchForUser" is not? Am I understand
correctly
> that implementor of FederationProvider can choose which method to
> override, so for example if he won't override "getUsers" or
> "getUserCount" then FederationManager just delegates those to
"local"
> UserProvider?
>
> If getUserCount() is an issue, I can remove it and refactor export to
> not using it and instead use approach like
It is not an issue as only export uses it. Export will only be
exporting local storage.
> : "checkout users until
> current page is not full", which would mean that there are no more users
> to export (Like for example if I have 50 users and usersPerPage is 20,
> then page1 has 20 users, page2 has 20 users and page3 has just 10 users,
> so export process can recognize that it is last page).
>
> But still getUserCount() may be useful if we later want to add
> pagination support to admin console (in this case, we may need "count"
> methods also for searchFor** -
> https://issues.jboss.org/browse/KEYCLOAK-564 )
>
Don't need a count, just if size() < maxRequested, you know you're at
the end.
yeah, it's ok if we support just 3 buttons like "<<"
"<" ">" as it's
now. If we want to add also ">>" I think we would need to add support
for counting, so users have possibility to go directly to the last page.
Marek
3:47 a.m.
Sounds good to me with the exception of the admin console stuff. I don't think adding
pages to the admin console this way is very elegant. If we're aiming to make the admin
console extensible we should look at UberFire or Hawt to achieve this. However, I think a
much simpler way to achieve the same goal is to add a generic configuration mechanism for
providers, which would just consist of a key/value map. The provider would also return a
list of what keys should be configured.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Saturday, 19 July, 2014 3:05:27 AM
Subject: [keycloak-dev] AuthProvider refactor details
I reviewed Marek's code. The refactor is going to be pretty much
Marek's code except reorganized a little bit. Hopefully you can follow
what I'm saying. I'll try and follow up with code in a few days.
* AuthProvider is going to turn into FederationProvider which is an
extension of UserProvider
public interface FederationProvider extends UserProvider {
String getAdminPage();
Class<? extends FederatonAdmin> getAdminClass();
UserModel proxy(UserModel localUser);
}
* AuthenticationProviderManager is going to turn into a concrete class
which implements UserProvider, FederationManager. It will basically do
the same algorithm as AuthProviderManager for finding users (looping
through the realm's configured FederationProviders), except it will be
using the UserProvider interface and returning UserModels.
- UserModel getXXX() methods will search within "local" storage first
for a user.
- If exists, it will look at the UserModel.getProvider() attribute to
learn which provider to use. Then call FederationProvider.proxy()
method. This will allow the FederationProvider to proxy the UserModel
so it can perform on demand sync.
* KeycloakSession will allocate a FederationManager and wrap it with a
CacheUserProvider instead of getting the "local" user storage provider.
* LDAP/Picketlink code will turn into a set of abstract classes used to
build the LDAPFederationProvider.
- getXXX will try to locate in LDAP store. If exists, it will import
the user into the "local" storage UserModel. It will create a proxy to
this local storage. This proxy will allow on-demand sync.
Configuration:
* AuthentiationProviderModel will be renamed to FederationProviderModel.
RealmModel will also return a list of these
* LDAP code will not use Realm.getLdapConfig(). It will instead use
FederationProviderModel config.
Management:
* Federation configuration will move from the Realm Settings page, to
the Users page.
* getAdminPage and getAdminClass exist so that FederationProvider
plugins can plug-in their own admin console UI and REST API.
* FederationProvider.getAdminPage() will point to a admin console path.
When adding a FederationProvider, the admin console will load this
page for setup/config.
* The FederationProvider.getAdminClass() method will return a JAX-RS
resource locator class that implements
interface FederationAdmin {
void setAdmin(UserModel admin);
void setSession(Keycloak session);
void setRealm(RealmModel realm);
}
* The admin class will be instantiated when invoking REST calls to
.../realms/{realm}/users/providers/{provider-name}/...
That's it in a nutshell. I haven't implemented any of this, its just in
my head and there's probably a lot of details I've overlooked that I'll
figure out when I code.
--
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
8:38 a.m.
I said this in other email but:
Positive:
1) I don't know if Hawt/Uberfire have mechanism to plug in a backend
REST interface,
2) Don't know yet if Hawt/Uberfire can even plug into our theme
architecture.
3) This way is much easier than bringing in a huge backend framework to
do something that is really really easy with the small SPI I suggested.
4) Developer doesn't have to learn Hawt/Uberfire. (And neither do we for
at least 1.0).
5) we can provide a default JAX-RS class and page to do generic properties
6) I want our LDAP provider to be a plugin, but I also want it to have a
nice config page.
Negative:
1) We're stuck with the API if we move to Hawt/Uberfire.
On 7/21/2014 4:47 AM, Stian Thorgersen wrote:
Sounds good to me with the exception of the admin console stuff. I
don't think adding pages to the admin console this way is very elegant. If we're
aiming to make the admin console extensible we should look at UberFire or Hawt to achieve
this. However, I think a much simpler way to achieve the same goal is to add a generic
configuration mechanism for providers, which would just consist of a key/value map. The
provider would also return a list of what keys should be configured.
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: keycloak-dev(a)lists.jboss.org
> Sent: Saturday, 19 July, 2014 3:05:27 AM
> Subject: [keycloak-dev] AuthProvider refactor details
>
> I reviewed Marek's code. The refactor is going to be pretty much
> Marek's code except reorganized a little bit. Hopefully you can follow
> what I'm saying. I'll try and follow up with code in a few days.
>
> * AuthProvider is going to turn into FederationProvider which is an
> extension of UserProvider
>
> public interface FederationProvider extends UserProvider {
> String getAdminPage();
> Class<? extends FederatonAdmin> getAdminClass();
> UserModel proxy(UserModel localUser);
> }
>
> * AuthenticationProviderManager is going to turn into a concrete class
> which implements UserProvider, FederationManager. It will basically do
> the same algorithm as AuthProviderManager for finding users (looping
> through the realm's configured FederationProviders), except it will be
> using the UserProvider interface and returning UserModels.
> - UserModel getXXX() methods will search within "local" storage first
> for a user.
> - If exists, it will look at the UserModel.getProvider() attribute to
> learn which provider to use. Then call FederationProvider.proxy()
> method. This will allow the FederationProvider to proxy the UserModel
> so it can perform on demand sync.
>
> * KeycloakSession will allocate a FederationManager and wrap it with a
> CacheUserProvider instead of getting the "local" user storage provider.
>
> * LDAP/Picketlink code will turn into a set of abstract classes used to
> build the LDAPFederationProvider.
> - getXXX will try to locate in LDAP store. If exists, it will import
> the user into the "local" storage UserModel. It will create a proxy to
> this local storage. This proxy will allow on-demand sync.
>
> Configuration:
>
> * AuthentiationProviderModel will be renamed to FederationProviderModel.
> RealmModel will also return a list of these
> * LDAP code will not use Realm.getLdapConfig(). It will instead use
> FederationProviderModel config.
>
> Management:
>
> * Federation configuration will move from the Realm Settings page, to
> the Users page.
> * getAdminPage and getAdminClass exist so that FederationProvider
> plugins can plug-in their own admin console UI and REST API.
> * FederationProvider.getAdminPage() will point to a admin console path.
> When adding a FederationProvider, the admin console will load this
> page for setup/config.
> * The FederationProvider.getAdminClass() method will return a JAX-RS
> resource locator class that implements
>
> interface FederationAdmin {
> void setAdmin(UserModel admin);
> void setSession(Keycloak session);
> void setRealm(RealmModel realm);
> }
> * The admin class will be instantiated when invoking REST calls to
> .../realms/{realm}/users/providers/{provider-name}/...
>
> That's it in a nutshell. I haven't implemented any of this, its just in
> my head and there's probably a lot of details I've overlooked that I'll
> figure out when I code.
>
>
>
> --
> 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
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
3811
days inactive
3813
days old
6 comments
3 participants
participants (3)
-
Bill Burke -
Marek Posolda -
Stian Thorgersen