On 10/29/2014 9:28 AM, Stan Silvert wrote: > * EAP6 does not yet support all this. We should discuss whether or > not this functionality should be backported. > +1 for this, but maybe some focus should be on getting a more seamless "hello world" like we discussed in a previous thread?

From: "Stian Thorgersen" <stian(a)redhat.com&gt; To: "Stan Silvert" <ssilvert(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 29 October, 2014 3:56:18 PM Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem I'd like to have a look at this before we merge it, but won't have time until tomorrow (maybe Friday). ----- Original Message ----- > From: "Stan Silvert" <ssilvert(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Wednesday, 29 October, 2014 3:25:55 PM > Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC > subsystem > > On 10/29/2014 10:07 AM, Bill Burke wrote: > > > > On 10/29/2014 9:28 AM, Stan Silvert wrote: > >> * EAP6 does not yet support all this. We should discuss whether or > >> not this functionality should be backported. > >> > > +1 for this, but maybe some focus should be on getting a more seamless > > "hello world" like we discussed in a previous thread? > > > I agree. IMO, the next step should be Feature Pack installation and the > seamless "hello world". Then we look at EAP6. > _______________________________________________ > 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

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 12:43:16 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 I didn't know about that. I can add it. > * How to manually add a provider? > * How to use add-provider and update-server-config? I'm still a bit unclear > on how the 'update-server-config' works, can you elaborate a bit on this? I should be done with updating the doc today. These questions will be answered there. > * What's the "new CLI GUI"? Why doesn't it work with the old CLI? This is CLI GUI: https://developer.jboss.org/wiki/AGUIForTheCommandLineInterface It's been around almost three years and I'm quite proud of it, but a lot of people don't know it exists. I just added a new feature to CLI GUI that automatically uploads bytes for operations that require uploads. To do this in regular CLI, you would need to write code for a meta-command like "deploy". Soon I'll talk to Alexey about adding this feature to regular CLI as well. The new feature will be available with WildFly Core 1.0.0.Alpha11. Should be out soon. For now you have to build from master to get it. You just need a single jar and it works with older WildFly/EAP versions. https://developer.jboss.org/wiki/UsingTheCLIRemoteClientJar > * How to add themes in domain mode? Is that with provider jar? Yes. > Documentation obviously needs updating before Beta1 is released. We also > need to test that it works with the OpenShift Cartridge. I can't think of a reason why it wouldn't work. I know CLI GUI works with OpenShift. But yea, we need to test it.

BTW, using CLI GUI is just temporary. I think it won't be long before we can front-end the Keycloak subsystem in Keycloak admin. > > Stan, can we get rid of these: > 08:30:02,004 WARN [org.jboss.as.dependency.private] (MSC service thread > 1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is using > a private module ... I don't think that's related to my PR. I think you'll see those when you deploy from the /deployments directory as well. The messages are for the jackson and httpcomponents modules. I think I can get rid of the messages if we remove the <dependencies> section from jboss-deployment-structure.xml. Those dependencies should be added using KeycloakDependencyProcessor instead.

> > ----- 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: Wednesday, 29 October, 2014 3:56:18 PM >> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into >> KC subsystem >> >> I'd like to have a look at this before we merge it, but won't have time >> until >> tomorrow (maybe Friday). >> >> ----- Original Message ----- >>> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>> To: keycloak-dev(a)lists.jboss.org >>> Sent: Wednesday, 29 October, 2014 3:25:55 PM >>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into >>> KC >>> subsystem >>> >>> On 10/29/2014 10:07 AM, Bill Burke wrote: >>>> On 10/29/2014 9:28 AM, Stan Silvert wrote: >>>>> * EAP6 does not yet support all this. We should discuss whether or >>>>> not this functionality should be backported. >>>>> >>>> +1 for this, but maybe some focus should be on getting a more seamless >>>> "hello world" like we discussed in a previous thread? >>>> >>> I agree. IMO, the next step should be Feature Pack installation and the >>> seamless "hello world". Then we look at EAP6. >>> _______________________________________________ >>> 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 >>

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 1:41:59 PM Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem On 10/31/2014 7:55 AM, Stian Thorgersen wrote: > >>> Stan, can we get rid of these: >>> 08:30:02,004 WARN [org.jboss.as.dependency.private] (MSC service >>> thread >>> 1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is >>> using >>> a private module ... >> I don't think that's related to my PR. I think you'll see those when >> you deploy from the /deployments directory as well. >> >> The messages are for the jackson and httpcomponents modules. I think I >> can get rid of the messages if we remove the <dependencies> section from >> jboss-deployment-structure.xml. Those dependencies should be added using >> KeycloakDependencyProcessor instead. > Yes, it's not caused by your PR (I should have clarified that), was just > hoping there was some magic we could do in the subsystem to get rid of > those. > > Removing dependencies section would brake it when deployed as WAR though. > Can you modify the dependencies in the deployment-process instead? It would only brake when the Keycloak subsystem is not installed. You can still deploy as a WAR. Don't we require that anyway on WildFly/EAP deployments?

The other thing we could do is to install our own versions of httpcomponents and jackson.

> >>> ----- 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: Wednesday, 29 October, 2014 3:56:18 PM >>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into >>>> KC subsystem >>>> >>>> I'd like to have a look at this before we merge it, but won't have time >>>> until >>>> tomorrow (maybe Friday). >>>> >>>> ----- Original Message ----- >>>>> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>>>> To: keycloak-dev(a)lists.jboss.org >>>>> Sent: Wednesday, 29 October, 2014 3:25:55 PM >>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server >>>>> into >>>>> KC >>>>> subsystem >>>>> >>>>> On 10/29/2014 10:07 AM, Bill Burke wrote: >>>>>> On 10/29/2014 9:28 AM, Stan Silvert wrote: >>>>>>> * EAP6 does not yet support all this. We should discuss whether >>>>>>> or >>>>>>> not this functionality should be backported. >>>>>>> >>>>>> +1 for this, but maybe some focus should be on getting a more seamless >>>>>> "hello world" like we discussed in a previous thread? >>>>>> >>>>> I agree. IMO, the next step should be Feature Pack installation and >>>>> the >>>>> seamless "hello world". Then we look at EAP6. >>>>> _______________________________________________ >>>>> 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 >>>> >>

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 2:10:06 PM Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem On 10/31/2014 8:47 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: Friday, 31 October, 2014 1:41:59 PM >> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into >> KC subsystem >> >> On 10/31/2014 7:55 AM, Stian Thorgersen wrote: >>>>> Stan, can we get rid of these: >>>>> 08:30:02,004 WARN [org.jboss.as.dependency.private] (MSC service >>>>> thread >>>>> 1-8) JBAS018567: Deployment "deployment.main-auth-server.war" is >>>>> using >>>>> a private module ... >>>> I don't think that's related to my PR. I think you'll see those when >>>> you deploy from the /deployments directory as well. >>>> >>>> The messages are for the jackson and httpcomponents modules. I think I >>>> can get rid of the messages if we remove the <dependencies> section from >>>> jboss-deployment-structure.xml. Those dependencies should be added using >>>> KeycloakDependencyProcessor instead. >>> Yes, it's not caused by your PR (I should have clarified that), was just >>> hoping there was some magic we could do in the subsystem to get rid of >>> those. >>> >>> Removing dependencies section would brake it when deployed as WAR though. >>> Can you modify the dependencies in the deployment-process instead? >> It would only brake when the Keycloak subsystem is not installed. You >> can still deploy as a WAR. Don't we require that anyway on WildFly/EAP >> deployments? > How about when we deploy to AS7 and EAP6? We have a subsystem for that. So we would just have to require that it's installed. > >> The other thing we could do is to install our own versions of >> httpcomponents and jackson. > Or just put them in WEB-INF/lib? We already have a few deps in there That would work too. Do we use the same WAR for WildFly and Tomcat? If so, then that's probably how we should handle it.

> >>>>> ----- 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: Wednesday, 29 October, 2014 3:56:18 PM >>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server >>>>>> into >>>>>> KC subsystem >>>>>> >>>>>> I'd like to have a look at this before we merge it, but won't have >>>>>> time >>>>>> until >>>>>> tomorrow (maybe Friday). >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>>>>>> To: keycloak-dev(a)lists.jboss.org >>>>>>> Sent: Wednesday, 29 October, 2014 3:25:55 PM >>>>>>> Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server >>>>>>> into >>>>>>> KC >>>>>>> subsystem >>>>>>> >>>>>>> On 10/29/2014 10:07 AM, Bill Burke wrote: >>>>>>>> On 10/29/2014 9:28 AM, Stan Silvert wrote: >>>>>>>>> * EAP6 does not yet support all this. We should discuss >>>>>>>>> whether >>>>>>>>> or >>>>>>>>> not this functionality should be backported. >>>>>>>>> >>>>>>>> +1 for this, but maybe some focus should be on getting a more >>>>>>>> seamless >>>>>>>> "hello world" like we discussed in a previous thread? >>>>>>>> >>>>>>> I agree. IMO, the next step should be Feature Pack installation and >>>>>>> the >>>>>>> seamless "hello world". Then we look at EAP6. >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>

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

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?

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>

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

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

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.

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

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.

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

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.

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

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

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

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

----- 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: 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. Yes, provider developers. We have made it harder. They have to explode the war and change the setting in standalone.xml. We've also moved the auth-server.war to a harder to find location.

>> * 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. That's a real shame, it would have been so much nicer if users could just drop a jar into a directory.

> 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. I thought you just said you can't use a deployment scanner?

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

On 11/4/2014 5:54 AM, Stan Silvert wrote: > 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. > Why do we need overlays again?

> 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. Requiring a CLI is so Webspherish...Surprised Jason et. al. thought that was a good idea.

#3 is a great point. On 11/3/2014 5:28 AM, Stian Thorgersen wrote: > 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 >

Yep ----- Original Message ----- > From: "Stan Silvert" <ssilvert(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Monday, 3 November, 2014 2:29:41 PM > Subject: Re: [keycloak-dev] Notes on KEYCLOAK-795: Move Auth Server into KC subsystem > > So it is decided then? We are dropping the confidential setting in web.xml? > > On 11/3/2014 8:20 AM, Bill Burke wrote: >> #3 is a great point. >> >> On 11/3/2014 5:28 AM, Stian Thorgersen wrote: >>> 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 >

I've sent a PR for this: https://github.com/keycloak/keycloak/pull/811 It's a pretty big change in the way the Auth Server is started when the KeyCloak subsystem is used. The WAR is no longer dropped into the standalone/deployments directory. This is especially helpful for domain deployments, but it makes standalone cleaner as well. It will also be important for Feature Pack installation. The main difference you will see right away with this PR is that the appliance dist now uses the subsystem to launch the Auth Server. Here are some notes about how everything turned out. Next, I'll update the documentation if there is no major rework that needs to be done after the PR is reviewed. * The WAR for the auth server now lives in modules/.../keycloak-wildfly-subsystem/main/auth-server. By default, it is unexploded. If you want it to be exploded you can unzip it into that same directory and set the "auth-server-exploded" property in module.xml. * A new Auth Server is declared in standalone.xml/domain.xml. You can have more than one Auth Server in the same WildFly instance. * <subsystem xmlns="urn:jboss:domain:keycloak:1.0"> <auth-server name="main-auth-server"> <enabled>true</enabled> <web-context>auth</web-context> </auth-server> * The "enabled" attribute can be toggled at runtime to make the auth server undeploy/redeploy. * If you have more than one auth-server, the web-context must be unique. * In a domain environment, all specified Auth Server deployments are propagated to all servers using that profile. The same is true for overlays uploaded through the new CLI operations. * There are two new CLI operations that act on an auth-server. They are "add-provider" and "update-server-config". Currently, you can only execute these operations in the latest version of CLI GUI. We should discuss if we need to add support in plain CLI. The long term goal would be to add this functionality to the Keycloak Admin Console. * "add-provider" adds a provider jar to an auth-server * "update-server-config" overlays the keycloak-server.json for an auth-server. * If a keycloak-server.json file is found in standalone/configuration directory, all auth-server instances will still use it regardless of any update-server-config operations. * EAP6 does not yet support all this. We should discuss whether or not this functionality should be backported. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev