[keycloak-dev] AuthProvider refactor details

[Bill Burke]

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 at redhat.com>
>> To: keycloak-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com