[keycloak-dev] AuthProvider refactor details

[Bill Burke]

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