[keycloak-dev] Designing 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: Wednesday, 17 September, 2014 2:23:12 PM
> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
> 
> On 9/17/2014 4:03 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 17 September, 2014 2:13:07 AM
> >> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
> >>
> >> On 9/16/2014 4:13 PM, Bill Burke wrote:
> >>> On 9/16/2014 4:03 PM, Stan Silvert wrote:
> >>>> *Questions and Design Decisions*
> >>>> The Auth Server WAR will live in its own module.  Is there any reason
> >>>> for it to be in exploded form?
> >>>>
> >>> We have exploded form so that user can plug in their own custom user
> >>> federation providers and other plugin SPIs.  These providers are scanned
> >>> for in the classpath using the META-INF/services pattern.
> >> They could (should?) install the plugin as a module and expose the
> >> services from there.  But for now I'll use exploded form.
> > I don't personally like the current way we add plugins to the
> > auth-server.war. Would it be possible to "deploy" plugins in
> > "deployments"? Alternatively have plugins added as modules, then either
> > have the Keycloak subsystem automatically detect them on startup or
> > require users to register them with Keycloak somehow.
> Anything is possible, but adding as a deployment is definitely not the
> way to go.  Deployments are for end-user applications.

Plugins are end-user things though, and it certainly would make it easier to develop plugins if you could do "mvn wildfly:deploy" ;)

> 
> Adding as a module is the cleanest way to do this but it requires a
> little more than just copying the jar to the file system.  So we're
> talking about either creating a module.xml by hand or using a tool.
> 
> Since there will soon be a keycloak-auth-server module, you could put
> the jar in that module and add an entry in that module.xml. That's
> probably a good compromise.

Whatever we do we should make it simple - we've already had complaints about having to copy a jar into standalone/deployments/auth-server.war/WEB-INF/lib. Creating a module and updating keycloak-auth-server module.xml is even more work. Also what happens when you upgrade the keycloak-auth-server module, wouldn't it loose the dependencies added by users?

> >
> >>>> The Keycloak Subsystem will get a new resource called "auth-server".
> >>>> Right now I only plan to have one attribute called "enabled".  By
> >>>> default, this will be false in a domain environment. You don't want an
> >>>> auth server to boot everywhere you install the keycloak subsystem.  Do
> >>>> we want this to be true for standalone?  In other words, should the auth
> >>>> server automatically boot if the keycloak subsystem is installed on
> >>>> standalone?
> >>>>
> >>> Why wouldn't it boot?  What is the plan for distributing Keycloak?
> >> You don't want the auth server to boot if you are just using the
> >> subsystem for clients.  But now that I think about it, I've answered my
> >> own question.  Whether or not the auth server is enabled is something
> >> that can be defined when you add the Keycloak feature pack.  So you
> >> could set the default to whatever you want depending on the situation.
> >>
> >> I'm not sure I understand your question about distribution.  With the
> >> feature pack, Keycloak can be added when a server is first assembled or
> >> Keycloak can be added on later.  The feature pack lives in the Maven
> >> repo.  For example, the WildFly full build will use the Keycloak FP to
> >> add Keycloak and make it part of its download.  The WildFly web build
> >> probably won't include Keycloak, but you can use the feature pack to add
> >> it later.
> >>
> >> Feature Pack = module references + configuration XML + extra content
> >>>
> >>>> Are there any other attributes to add?  The Keycloak subsystem can do
> >>>> anything it wants to the auth server at deployment time.  It can change
> >>>> context params, add modules, boot in some kind of admin-only mode, or
> >>>> anything else.  Configuration settings on the WAR could be made from
> >>>> standalone.xml, domain.xml, CLI, etc.  Anything you would like the
> >>>> subsystem to do?
> >>>>
> >>> there is a keycloak-server.json file.  Maybe that should be configurable
> >>> in the subsystem too.
> >> OK.  I'll take a look at that.  Should be very similar to what we do for
> >> clients configured by the subsystem.
> > Would it not be best to drop 'keycloak-server.json' and configure it all
> > from standalone/domain.xml?
> For WildFly/EAP deployments, I think this will become the preferred way
> of doing it.   We'll still need keycloak-server.json for other containers.
> >
> >>>
> >>>> Do I need to allow for multiple auth server deployments in the same
> >>>> WildFly instance?  This is quite easy to do.  For the second instance,
> >>>> it would override the module name of the auth server WAR.
> >>>>
> >>> I'm sure there is some weird user that will want to do this.  But I
> >>> don't think this will be the norm, do you?
> >> No, not the norm.  Would there be a scenario where someone wanted to
> >> have prod and test instances of the auth server inside the same WildFly
> >> instance?  Or maybe someone wants a single WildFly instance to host two
> >> auth servers from unrelated entities?
> >>>> What are the plans and considerations for clustered auth server?
> >>>> Anything I should be aware of at this point?
> >>>>
> >>> Might need infinispan configured for clustering going forward.
> >>>
> >>>
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
>