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

This conversation has become hard to follow. Can you guys summarize what you've agreed to?

On 9/17/2014 9:19 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 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 >