[keycloak-dev] federation commited need feedback

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 24 July, 2014 2:47:57 PM
> Subject: Re: [keycloak-dev] federation commited need feedback
> 
> 
> 
> On 7/24/2014 9:25 AM, Stian Thorgersen wrote:
> > Looks good. Only two comments from me:
> >
> > 1. FederationManager.getFederationProvider uses factories directly
> >
> > Why is this? This will cause the provider instance not to be registered
> > with the session, so won't be closed automatically when the session is
> > closed, nor will it be able to attach to the transaction.
> >
> 
> FederationProviders are not singletons within KeycloakSession like
> RealmProvider, UserProvider, and UserSessionProvider are.  You can have
> multiple FederationProvider instances per realm.
> 
> 
> public interface FederationProviderFactory extends
> ProviderFactory<FederationProvider> {
>      FederationProvider getInstance(KeycloakSession session,
> FederationProviderModel model);
> }
> 
> 
> FederationProviders implementations have the option to enlist themselves
> with the KeycloakSession transaction manager.  LDAP (really Picketlink)
> doesn't have the concept of a session or transaction, so it doesn't
> enlist itself.
> 
> I guess we do need a enlistForClose() method on KeycloakSession though.

As long as the lifespan of a FederationProvider is the same as the KeycloakSession they should be created through the KeycloakSession IMO. We just need to add an additional createProvider that can create a instance tied to a specific realm.

> 
> 
> > 2. TOTP SPI (just related)
> >
> > Once I've finished access code work I was going to start on TOTP SPI. I
> > think a UserProvider should only be able to verify password credentials,
> > and TOTP providers should be used to verify TOTP. I'll send a separate
> > email about this tomorrow so we can discuss it in more detail, just a
> > heads up.
> >
> 
> UserProvider.validCredentials() should still continue to exist as the
> primary high-level call.  With federation, credential validation may be
> executed in different places (and even within non-Keycloak code)
> depending on the capabilities of the FederationProvider.
> 
> In fact, IMO, there should be no changes needed to any of our APIs/SPIs.
>   The CredentialValidation class is used by all UserProviders now and
> you can plug in any credential validation SPI you want there along with
> adding additional credential types to UserCredentialModel i.e.
> TOTP_GOOGLE, TOTP_FREEOTP
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>