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

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