[keycloak-dev] Designing Auth Server startup from subsystem

Stian Thorgersen stian at redhat.com
Wed Sep 17 04:03:44 EDT 2014



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

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

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


More information about the keycloak-dev mailing list