Re: https://issues.jboss.org/browse/WFLY-1014 I'd like to request that we take a harder look at getting WFLY-1014 done. This feature allows CORS requests into the HTTP management endpoint. This would solve two problems: 1) The web console must ship with WildFly and must be downloaded from the WildFly instance it is talking to. 2) No other console is allowed to use the HTTP management endpoint. So, a layered product's console can not control its own subsystem. Herald gives a nice overview of what this would mean for the Web Console: http://hpehl.info/independent-jboss-admin-console.html It would be very beneficial for other products as well. Can we get this done? Stan

To get this implemented the first thing we need is some detailed analysis of how the Host and Origin headers will be used by different browsers for the different distribution approaches we will take for the different consoles. We will need to take into account how this could be affected by proxies / firewalls etc... Considering the different distribution approaches we will need to consider implications for malicious consoles / web pages etc possibly from the same source and any options to mitigate this. But then overall it should be a case of configuration to allow a relaxation of the Host / Origin match with acceptable values.

Regards, Darran Lofthouse. On 10/12/13 13:17, ssilvert(a)redhat.com wrote: > Re: https://issues.jboss.org/browse/WFLY-1014 > > I'd like to request that we take a harder look at getting WFLY-1014 > done. This feature allows CORS requests into the HTTP management > endpoint. > > This would solve two problems: > 1) The web console must ship with WildFly and must be downloaded from > the WildFly instance it is talking to. > 2) No other console is allowed to use the HTTP management endpoint. So, > a layered product's console can not control its own subsystem. > > Herald gives a nice overview of what this would mean for the Web > Console: > http://hpehl.info/independent-jboss-admin-console.html > > It would be very beneficial for other products as well. Can we get this > done? > > Stan > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev >

I am not sure if I am missing something, are you proposing that we stop the rejection of requests that have a different origin?

On 10/12/13 15:58, ssilvert(a)redhat.com wrote: > On 12/10/2013 9:35 AM, Darran Lofthouse wrote: >> To get this implemented the first thing we need is some detailed >> analysis of how the Host and Origin headers will be used by different >> browsers for the different distribution approaches we will take for >> the different consoles. >> >> We will need to take into account how this could be affected by >> proxies / firewalls etc... >> >> Considering the different distribution approaches we will need to >> consider implications for malicious consoles / web pages etc possibly >> from the same source and any options to mitigate this. >> >> But then overall it should be a case of configuration to allow a >> relaxation of the Host / Origin match with acceptable values. > Let's do this last part first. It's not much effort to enable CORS. > Here is Herald's commit: > https://github.com/hpehl/wildfly/commit/89af5ba711502005275411820b8198f69... > > > If we put this into WildFly 8 (disabled by default), it would allow us > to start working with it and better perform the analysis suggested by > Darran. > > I propose that Herald update his commit to work with the latest code and > we go ahead and get that in. Any objections? > >> >> Regards, >> Darran Lofthouse. >> >> >> On 10/12/13 13:17, ssilvert(a)redhat.com wrote: >>> Re: https://issues.jboss.org/browse/WFLY-1014 >>> >>> I'd like to request that we take a harder look at getting WFLY-1014 >>> done. This feature allows CORS requests into the HTTP management >>> endpoint. >>> >>> This would solve two problems: >>> 1) The web console must ship with WildFly and must be downloaded from >>> the WildFly instance it is talking to. >>> 2) No other console is allowed to use the HTTP management >>> endpoint. So, >>> a layered product's console can not control its own subsystem. >>> >>> Herald gives a nice overview of what this would mean for the Web >>> Console: >>> http://hpehl.info/independent-jboss-admin-console.html >>> >>> It would be very beneficial for other products as well. Can we get >>> this >>> done? >>> >>> Stan >>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >

If we are going to support cross origin requests we need to do it properly, the current behaviour is there to solve a specific problem of the server being vulnerable to cross site scripting attacks - relaxing it without a complete solution is just going to re-introduce that vulnerability. Based on the current commit there are two things we would really need to do: - 1 - Instead of faking authentication move Options handling to it's own handler before authentication. 2 - Proper support for configured alternative origins. Maybe we can just get away with a configured list of alternative origins to allow through but without exploring the origins for the alternative distribution approaches we can not be sure that would not leave an alternative option for malicious calls. At the moment I have not seen anything to suggest we need anything more dynamic but at this point I don't know if we have all the distribution approaches defined. I will have a look at what we can do for the static config approach.

Regards, Darran Lofthouse. On 10/12/13 16:53, ssilvert(a)redhat.com wrote: > On 12/10/2013 11:26 AM, Darran Lofthouse wrote: >> I am not sure if I am missing something, are you proposing that we >> stop the rejection of requests that have a different origin? > Not by default. Just as an option so that we can start working with > CORS on the front end. >> >> On 10/12/13 15:58, ssilvert(a)redhat.com wrote: >>> On 12/10/2013 9:35 AM, Darran Lofthouse wrote: >>>> To get this implemented the first thing we need is some detailed >>>> analysis of how the Host and Origin headers will be used by different >>>> browsers for the different distribution approaches we will take for >>>> the different consoles. >>>> >>>> We will need to take into account how this could be affected by >>>> proxies / firewalls etc... >>>> >>>> Considering the different distribution approaches we will need to >>>> consider implications for malicious consoles / web pages etc possibly >>>> from the same source and any options to mitigate this. >>>> >>>> But then overall it should be a case of configuration to allow a >>>> relaxation of the Host / Origin match with acceptable values. >>> Let's do this last part first. It's not much effort to enable CORS. >>> Here is Herald's commit: >>> https://github.com/hpehl/wildfly/commit/89af5ba711502005275411820b8198f69... >>> >>> >>> >>> If we put this into WildFly 8 (disabled by default), it would allow us >>> to start working with it and better perform the analysis suggested by >>> Darran. >>> >>> I propose that Herald update his commit to work with the latest >>> code and >>> we go ahead and get that in. Any objections? >>> >>>> >>>> Regards, >>>> Darran Lofthouse. >>>> >>>> >>>> On 10/12/13 13:17, ssilvert(a)redhat.com wrote: >>>>> Re: https://issues.jboss.org/browse/WFLY-1014 >>>>> >>>>> I'd like to request that we take a harder look at getting WFLY-1014 >>>>> done. This feature allows CORS requests into the HTTP management >>>>> endpoint. >>>>> >>>>> This would solve two problems: >>>>> 1) The web console must ship with WildFly and must be downloaded >>>>> from >>>>> the WildFly instance it is talking to. >>>>> 2) No other console is allowed to use the HTTP management >>>>> endpoint. So, >>>>> a layered product's console can not control its own subsystem. >>>>> >>>>> Herald gives a nice overview of what this would mean for the Web >>>>> Console: >>>>> http://hpehl.info/independent-jboss-admin-console.html >>>>> >>>>> It would be very beneficial for other products as well. Can we get >>>>> this >>>>> done? >>>>> >>>>> Stan >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>> >

I dont understand your second point, but +1 for enabling cors. It would enable arbitrary use cases that rely on the http endpoint. But cors is onky one part if the story. The authentication mechanism would need to change as well, to allow for better integration. Has anyone evaluated keycloak as an alternative for securing the http management endpoint?

At a first glance it seems to solve many of the problems we've outlined before. > Am 10.12.2013 um 14:17 schrieb ssilvert(a)redhat.com: > > No other console is allowed to use the HTTP management endpoint. So, > a layered product's console can not control its own subsystem.

The next issue is that by using standard HTTP authentication mechanisms standard APIs can be used in many programming languages to actually call the management interface without needing to know about alternative authentication schemes.

On 11/12/13 10:53, Heiko Braun wrote: > yes, but this is not true for digest auth. there are actually very few > client environments that fully support digest out of the box. > > so i would say, this argument doesn't count as digest is not any less > complicated to use then any other more sophisticated auth mechanism. > > I agree to the TLS argument: for most other auth mechanisms i looked at > it seems to be requirement indeed. > But can you elaborate why we cannot ship certificates (out of the box) What you are talking about here is encrypting traffic with a key which is public knowledge. > that need to be replaced in production environments? We know that will not happen in many installations - guaranteed!

Sent from my iPhone > On Dec 11, 2013, at 5:00 AM, Heiko Braun <hbraun(a)redhat.com&gt; wrote: > > yes, but this is not true for digest auth. there are actually very few client environments that fully support digest out of the box. Everything I know of supports Digest, all mainstream scripting languages. We don't need to mix use cases though. We can start with digest and have a config process for SSO that requires switching to TLS.