Re: [keycloak-dev] Designing Auth Server startup from subsystem

From: "Stan Silvert" <ssilvert(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)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(a)redhat.com&gt; >> To: keycloak-dev(a)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.

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.

> >>>> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>