[keycloak-dev] AuthProvider refactor details

[Bill Burke]

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