Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC 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: Tuesday, 4 November, 2014 11:54:09 AM Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem On 11/4/2014 2:51 AM, Stian Thorgersen wrote: > Ok, we'll not include this in Beta1. > > I'd like to see a solution to deploying providers that: > > * Can be scripted > * Makes life easy for developers I assume you mean provider developers? We haven't taken anything away from them, so it's at least no harder. They will be able to either use exploded mode or run a script.

> * Can also be done while server is not running (I'm confused to why the > overlays has to be uploaded through a CLI, and can't just be copied to a > directory and manually added to standalone.xml) That's a long, long story. Originally, I wanted to have a directory for overlays and make it work sort of like a deployment scanner. Unfortunately, I found that is impossible for overlays without some substantial changes to WildFly. Overlays can't use a deployment scanner of any kind.

Deployments and overlays are never manually added to standalone.xml. That's just the way WildFly works. You either upload with a tool like CLI or web console, or (if standalone) you let a deployment scanner find it. For domain mode, only uploading is allowed.

> > ----- 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: Monday, 3 November, 2014 7:42:13 PM >> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into >> KC subsystem >> >> On 11/3/2014 1:13 PM, Stian Thorgersen wrote: >>> I thought you could point to a file on the file-system for the overlay. >>> >>> In that case if the only options are CLI GUI or adding to the WAR, we >>> should have the WAR exploded for now. >> I disagree. Using the CLI GUI command is simpler and less error-prone >> than manual copying. >> >> Manual copying in domain mode means copying the provider jar to every >> instance where it will be deployed. And in the case where you want >> multiple Keycloak instances, every instance will get the same providers >> and the same keycloak-server.json. >> >> Is it really such a problem that we will go one release without CLI >> scripting support? If it is then I'd rather delay the whole merge >> until the next release. That's not something I would oppose in any >> case. I want everyone to be comfortable with this because it is a >> fairly big change. >>> ----- 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: Monday, 3 November, 2014 6:52:26 PM >>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into >>>> KC subsystem >>>> >>>> On 11/3/2014 11:21 AM, Stian Thorgersen wrote: >>>>> What about we just add an example snippet of the XML required to add a >>>>> provider manually (no cli) to standalone.xml? IMO that'd be good enough >>>>> for Beta1. >>>> It isn't done using XML. You have to somehow upload the bits to the >>>> server's content repository. That can be done via CLI GUI or by >>>> manually adding the bits to the WAR before it is deployed. >>>> >>>> The point here is that even if you can't yet do this in a CLI script, >>>> you aren't losing anything over the way it is done today. It is still >>>> possible to manually copy the jar into the WAR. >>>>> ----- Original Message ----- >>>>>> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>>>>> To: keycloak-dev(a)lists.jboss.org >>>>>> Sent: Monday, 3 November, 2014 4:10:39 PM >>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server >>>>>> into >>>>>> KC subsystem >>>>>> >>>>>> On 11/3/2014 8:22 AM, Stan Silvert wrote: >>>>>>> On 11/3/2014 8:08 AM, Stian Thorgersen wrote: >>>>>>>> With deployment overlays >>>>>>>> (https://docs.jboss.org/author/display/WFLY8/Deployment+Overlays) is >>>>>>>> it >>>>>>>> possible to refer to files in the file-system? Can we use that to >>>>>>>> add >>>>>>>> a >>>>>>>> provider? >>>>>>> Yes. The only difference is that the "deployment-overlay" command is >>>>>>> a >>>>>>> lot more complicated and error prone. The result is the same though >>>>>>> if >>>>>>> you use it correctly. So we could just document that. >>>>>>> >>>>>>> I guess that's a good solution for now. For "add-provider" and >>>>>>> "update-server-config", I'll document the equivalent >>>>>>> "deployment-overlay" command that can be used in a script. >>>>>> I just heard back from Alex and he wants to add the functionality to >>>>>> CLI >>>>>> that I added to CLI GUI. So at the end of the day, the commands will >>>>>> be >>>>>> the same in CLI and CLI GUI. >>>>>> >>>>>> Instead of documenting equivalent "deployment-overlay" commands, I'll >>>>>> work on that instead. >>>>>> >>>>>> I don't think that lack of scripting support should delay the release. >>>>>> IMO, if everyone is comfortable with the overall change, we can go >>>>>> ahead >>>>>> and merge. But waiting until next release is OK as well. >>>>>>>> ----- 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: Monday, 3 November, 2014 1:54:31 PM >>>>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server >>>>>>>>> into >>>>>>>>> KC subsystem >>>>>>>>> >>>>>>>>> Just a documentation task then. >>>>>>>>> >>>>>>>>> You can still deploy the auth-server.war in exploded format just >>>>>>>>> like >>>>>>>>> we >>>>>>>>> do today. I'll add a section in the doc for that. >>>>>>>>> >>>>>>>>> Or, you can use other means to put files into the unexploded war. >>>>>>>>> (Do >>>>>>>>> it >>>>>>>>> by hand or use Maven war overlay). >>>>>>>>> >>>>>>>>> I welcome other suggestions on updating the docs. We still need to >>>>>>>>> document how to do this the old way because these subsystem >>>>>>>>> enhancements >>>>>>>>> only apply to WildFly. >>>>>>>>> >>>>>>>>> I'll ping Alex about getting this into regular CLI so it is >>>>>>>>> scriptable. >>>>>>>>> Otherwise, I could write a CLI add-on that allows you to do this in >>>>>>>>> a >>>>>>>>> CLI script. >>>>>>>>> >>>>>>>>> On 11/3/2014 6:02 AM, Stian Thorgersen wrote: >>>>>>>>>> Before we can add this PR we need to make it possible to add >>>>>>>>>> providers >>>>>>>>>> and >>>>>>>>>> update server config without using the CLI GUI. This may just be a >>>>>>>>>> documentation task, but it has to be possible to script these >>>>>>>>>> tasks >>>>>>>>>> as >>>>>>>>>> well as perform them without using a GUI. >>>>>>>>>> >>>>>>>>>> We also need to update the provider examples as they currently >>>>>>>>>> asks >>>>>>>>>> the >>>>>>>>>> user to copy to WEB-INF/lib. >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>>>>>>>>> To: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>>>>>>>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>>>>>>>> Sent: Monday, 3 November, 2014 11:28:33 AM >>>>>>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth >>>>>>>>>>> Server >>>>>>>>>>> into >>>>>>>>>>> KC subsystem >>>>>>>>>>> >>>>>>>>>>> Actually, thinking about it we should just drop the confidential >>>>>>>>>>> setting >>>>>>>>>>> in >>>>>>>>>>> web.xml. >>>>>>>>>>> >>>>>>>>>>> #1 We have ssl-required on realm - there may be traffic where we >>>>>>>>>>> don't >>>>>>>>>>> check, >>>>>>>>>>> but we should improve instead of relying on setting in web.xml >>>>>>>>>>> #2 Users shouldn't access Keycloak directly - users click on >>>>>>>>>>> links >>>>>>>>>>> in >>>>>>>>>>> applications they don't navigate to a page on KC itself, so >>>>>>>>>>> there's >>>>>>>>>>> not >>>>>>>>>>> really a need to do the redirect from http >>>>>>>>>>> #3 Could be risky - if an application uses a custom adapter/lib >>>>>>>>>>> (or >>>>>>>>>>> have >>>>>>>>>>> the >>>>>>>>>>> wrong ssl-required in keycloak.json) and a http library that >>>>>>>>>>> automatically >>>>>>>>>>> follows the redirect. This would mean that an application posts >>>>>>>>>>> code >>>>>>>>>>> and >>>>>>>>>>> client secret to http://.., which returns a 302, the http library >>>>>>>>>>> then >>>>>>>>>>> re-posts to https://... Keycloak would think all requests are >>>>>>>>>>> done >>>>>>>>>>> using >>>>>>>>>>> ssl >>>>>>>>>>> (as it doesn't see the initial http request, only the app server >>>>>>>>>>> does) >>>>>>>>>>> and >>>>>>>>>>> the developer could also be unaware of this, the end result being >>>>>>>>>>> that >>>>>>>>>>> an >>>>>>>>>>> application would post codes and secrets in clear-text as well as >>>>>>>>>>> post >>>>>>>>>>> every >>>>>>>>>>> request twice. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>>>>>>>>>> To: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>>>>>>>>>>> Cc: keycloak-dev(a)lists.jboss.org >>>>>>>>>>>> Sent: Monday, 3 November, 2014 9:19:15 AM >>>>>>>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth >>>>>>>>>>>> Server >>>>>>>>>>>> into >>>>>>>>>>>> KC >>>>>>>>>>>> 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: Friday, 31 October, 2014 7:42:34 PM >>>>>>>>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth >>>>>>>>>>>>> Server >>>>>>>>>>>>> into >>>>>>>>>>>>> KC >>>>>>>>>>>>> subsystem >>>>>>>>>>>>> >>>>>>>>>>>>> On 10/31/2014 4:15 AM, Stian Thorgersen wrote: >>>>>>>>>>>>>> Looks good to me. We should include this in Beta1. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A few comments/questions: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Can we support enabling confidential transport-guarantee >>>>>>>>>>>>>> (auth-server/WEB-INF/web.xml) without cracking open the WAR? >>>>>>>>>>>>>> This >>>>>>>>>>>>>> seems >>>>>>>>>>>>>> to >>>>>>>>>>>>>> be the last requirement for an exploded WAR >>>>>>>>>>>>> Looking this over, it seems pretty important! I think I'd like >>>>>>>>>>>>> to >>>>>>>>>>>>> go >>>>>>>>>>>>> ahead and implement this option before we merge. I should be >>>>>>>>>>>>> able >>>>>>>>>>>>> to >>>>>>>>>>>>> do >>>>>>>>>>>>> that and also finish the doc updates by the middle of next >>>>>>>>>>>>> week. >>>>>>>>>>>>> Just >>>>>>>>>>>>> go ahead and release the Beta if you want. I can catch the >>>>>>>>>>>>> next >>>>>>>>>>>>> release >>>>>>>>>>>>> train. >>>>>>>>>>>>> >>>>>>>>>>>>> I plan to implement this as a boolean value on on the server >>>>>>>>>>>>> called >>>>>>>>>>>>> "https-required". Is there a better name for it? >>>>>>>>>>>>> <subsystem xmlns="urn:jboss:domain:keycloak:1.0"> >>>>>>>>>>>>> <auth-server name="foo"> >>>>>>>>>>>>> <enabled>true</enabled> >>>>>>>>>>>>> <web-context>auth</web-context> >>>>>>>>>>>>> <https-required>true</https-required> >>>>>>>>>>>>> </auth-server> >>>>>>>>>>>>> </subsystem> >>>>>>>>>>>>> >>>>>>>>>>>>> Should the default be false? I realize that the default in the >>>>>>>>>>>>> appliance dist is false, but should the default always be >>>>>>>>>>>>> false? >>>>>>>>>>>> We already have the option 'ssl-required' on a realm, so that >>>>>>>>>>>> may >>>>>>>>>>>> be >>>>>>>>>>>> confusing. What about 'redirect-non-ssl'? >>>>>>>>>>>> >>>>>>>>>>>> It shouldn't be on by default, as that would require setting up >>>>>>>>>>>> ssl >>>>>>>>>>>> for >>>>>>>>>>>> development as well. We have the 'ssl-required' set to >>>>>>>>>>>> 'external' >>>>>>>>>>>> to >>>>>>>>>>>> give >>>>>>>>>>>> us >>>>>>>>>>>> a compromise between usability and security. >>>>>>>>>>>> >>>>>>>>>>>>> If true, this will be automatically added to auth-server.war at >>>>>>>>>>>>> deploy >>>>>>>>>>>>> time: >>>>>>>>>>>>> >>>>>>>>>>>>> <security-constraint> >>>>>>>>>>>>> <web-resource-collection> >>>>>>>>>>>>> <url-pattern>/*</url-pattern> >>>>>>>>>>>>> </web-resource-collection> >>>>>>>>>>>>> <user-data-constraint> >>>>>>>>>>>>> <transport-guarantee>CONFIDENTIAL</transport-guarantee> >>>>>>>>>>>>> </user-data-constraint> >>>>>>>>>>>>> </security-constraint> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>