Push for CORS in WildFly 8

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Push for CORS in WildFly 8

Stan Silvert
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Harald Pehl
+1 for getting this done.

.: Harald


Am 10.12.2013 um 14:17 schrieb [hidden email]:

> 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
---
Harald Pehl
JBoss by Red Hat
http://hpehl.info


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

signature.asc (506 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Darran Lofthouse
In reply to this post by Stan Silvert
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, [hidden email] 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Stan Silvert
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/89af5ba711502005275411820b8198f69e36269b

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, [hidden email] 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Darran Lofthouse
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, [hidden email] 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/89af5ba711502005275411820b8198f69e36269b
>
> 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, [hidden email] 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Stan Silvert
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, [hidden email] 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/89af5ba711502005275411820b8198f69e36269b
>>
>>
>> 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, [hidden email] 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Heiko Braun
In reply to this post by Stan Silvert
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 [hidden email]:
>
> No other console is allowed to use the HTTP management endpoint.  So,
> a layered product's console can not control its own subsystem.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Darran Lofthouse
In reply to this post by Stan Silvert
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, [hidden email] 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, [hidden email] 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/89af5ba711502005275411820b8198f69e36269b
>>>
>>>
>>> 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, [hidden email] 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Stan Silvert
On 12/10/2013 12:33 PM, Darran Lofthouse wrote:

> 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.
+1 Static config would be great for now.

>
> Regards,
> Darran Lofthouse.
>
> On 10/12/13 16:53, [hidden email] 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, [hidden email] 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/89af5ba711502005275411820b8198f69e36269b
>>>>
>>>>
>>>>
>>>> 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, [hidden email] 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
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>
>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Stan Silvert
In reply to this post by Heiko Braun
On 12/10/2013 12:35 PM, Heiko Braun wrote:
> 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?
That's where I think we're headed and I intend to get there
eventually.   It's key to doing SSO between the web console and all our
other consoles.

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

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Darran Lofthouse
In reply to this post by Heiko Braun
The main problem we have with these solutions is they quickly introduce
the requirement for the transport to be confidential to prevent
interception of packets for replays.

Being confidential out of the box is never really an option, any
solution there is flawed - the best I can think of at the moment is
adding a set of management ops for key / certificate management and
updating the console to strongly push the administrator towards enabling
SSL.

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.  But having said that supporting it in addition
to the current mechanisms should not be a problem - best case the
authentication mechanisms co-exist - worst case we have a second context
exposed that the console communicates with leaving the existing
management context as-is.

Regards,
Darran Lofthouse.



On 10/12/13 17:35, Heiko Braun wrote:

> 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 [hidden email]:
>>
>> No other console is allowed to use the HTTP management endpoint.  So,
>> a layered product's console can not control its own subsystem.
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Heiko Braun



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) that need to be replaced in production environments?

this would give us TLS and push the need to custom certificate creation beyond the out-of-the-box scenario.




On 10 Dec 2013, at 19:00, Darran Lofthouse <[hidden email]> wrote:

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.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Heiko Braun
In reply to this post by Darran Lofthouse



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) that need to be replaced in production environments?

this would give us TLS and push the need to custom certificate creation beyond the out-of-the-box scenario.




On 10 Dec 2013, at 19:00, Darran Lofthouse <[hidden email]> wrote:

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.


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Darran Lofthouse
In reply to this post by Heiko Braun
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!

> this would give us TLS and push the need to custom certificate creation
> beyond the out-of-the-box scenario.
>
>
>
>
> On 10 Dec 2013, at 19:00, Darran Lofthouse <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>> 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.
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Bill Burke


On 12/11/2013 7:26 AM, Darran Lofthouse wrote:

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

This is why I've argued before on the TAG that wildfly should generate
SSL keys/certs on initial boot by default.  Just generate a key
pair/cert that will only work for "localhost".

For development, the user has something that works out of the box that
they can test HTTPS/SSL with, instead of figuring out the lengthy and
often confusing SSL setup steps.  (Our own docs have been really really
crappy in this area, btw).

For production, since the generated cert would only work for
"localhost", the admin would be pretty much forced to install SSL
correctly (or figure out how to turn it off) if they want to run
anywhere outside of development.

Bill

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Jason T. Greene
In reply to this post by Heiko Braun


Sent from my iPhone

> On Dec 11, 2013, at 5:00 AM, Heiko Braun <[hidden email]> 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.





_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Push for CORS in WildFly 8

Darran Lofthouse


On 11/12/13 14:52, Jason Greene wrote:

>
>
> Sent from my iPhone
>
>> On Dec 11, 2013, at 5:00 AM, Heiko Braun <[hidden email]> 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.

And if we can provide the operations and appropriate guidance through
the admin console enabling TLS should not be too complicated.

>
>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev