[keycloak-dev] Design of Auth Server startup from subsystem

[Stian Thorgersen]

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Thursday, 2 October, 2014 2:46:01 PM
> Subject: Re: [keycloak-dev] Design of Auth Server startup from subsystem
> 
> On 10/2/2014 8:18 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: "Stian Thorgersen" <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Thursday, 2 October, 2014 2:08:31 PM
> >> Subject: Re: [keycloak-dev] Design of Auth Server startup from subsystem
> >>
> >>
> >>>> /account-spi optionally contains a single jar file that replaces
> >>>> keycloak-account-freemarker.jar.
> >>>> /login-spi optionally contains a single jar file that replaces
> >>>> keycloak-login-freemarker.jar
> >>> Why replace keycloak-*-freemarker.jar?
> >> http://docs.jboss.org/keycloak/docs/1.0.1.Final/userguide/html/themes.html#d4e1060
> >>
> >> For account or login SPI, it says to delete these jars or disable with a
> >> System property if you want to use your own provider.  I chose replace.
> >> It doesn't actually change the original auth-server.war on disk.  It's a
> >> virtual replace.
> > Ah, forgot that was how it used to work - that doc is out of date, sorry!
> > You don't need to replace or use system properties any more, instead you
> > configure the provider to use in keycloak-server.json:
> >
> >    {
> >      "account" : {
> >        "provider": "my-account-provider"
> >      }
> >    }
> >
> > Basically Keycloak either retrieves a named provider for an SPI (for
> > example to get the ldap federation) or just picks the default provider
> > configured for the server (for example account provider). The default
> > provider is either specified as above, or if there's only one available
> > it'll pick that one.
> That's much better.  So I just need one directory where you drop all the
> SPI jars.  Maybe I'll call it /plugins.  That name covers both SPI jars
> and theme jars.
> >
> > Made me think about another thing. How should we deal with what providers
> > are included by default, and what users can add later? For instance we
> > could just put everything in the auth-server.war as we do now, or we could
> > have a simple mechanism to add those needed (stuff like ldap, google
> > login, etc, etc..).
> >
> Is there a reason to leave them out?
> 

Size and to disable/remove certain features. Could be useful for other projects if they want to include a slim auth-server for OOTB experience. For example AeroGear currently excludes most providers (ldap, social, etc.).