[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 3:15:18 PM
> Subject: Re: [keycloak-dev] Designing Auth Server startup from subsystem
> 
> On 9/17/2014 8:35 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: 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" ;)
> I agree.  That's why the EAP team is working on tooling for that sort of
> thing.  Before WildFly/AS7, everything was a deployment. But we've
> changed that now to divide the world into applications and services.
> >
> >> 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?
> If you upgrade by hand, it definitely won't lose anything.  How well it
> all works in the end will depend on how good the new provisioning tools
> are.  We can fill in the gaps with our own tools though.
> 
> If the requirement is to be able to upload the jar, we can accomplish
> that one way or the other.

Ignoring the underlying details, it would be cool if we had a Maven plugin that could "deploy" the plugin, maybe even restart Keycloak when a new plugin is deployed to make sure it's available.

> >
> >>>>>> 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
> >>>>
> >>
> 
>