Enhancing the HTTP Management Interface Configuration - WFLY-2635

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

Enhancing the HTTP Management Interface Configuration - WFLY-2635

Darran Lofthouse
I am just about to work on the outstanding task to enhance the
configuration to the HTTP management interface and add some additional
capabilities to it so this mail is really a FYI for those interested as
numerous teams have interest in this area.

The parent Jira issue is here: -
   https://issues.jboss.org/browse/WFLY-2635

At the moment there are not many configuration options for the HTTP
interface and we make a lot of decisions ourselves as to how it is
assembled, we now need some additional flexibility.

For the admin console there is a desire to enable alternative
distribution mechanisms so that the console can be served up from
elsewhere.  There are no plans to remove the admin console from the
WildFly distribution but users may want to switch to a different
version.  For this reason I plan to add configuration for the /console
context to make it possible to either disable the bundles console or to
respond to requests for the console with a redirect.

When we first authentication approaches for the HTTP management
operations we decided to use standard HTTP authentication mechanisms so
that clients could be written in many languages without imposing a
requirement other than the support of standard mechanisms.  This in turn
has some problems with web browsers calling the management interface so
cross origin resource sharing has been completely disabled to protect
against malicious cross site scripting attacks.  My intention is that
this /management context will remain as a legacy context (not
deprecated) so that clients written to use it can still do so - we may
choose to have it switched off by default but enabling this context will
be a config item.

The next step will be the introduction of a new management context with
a new name, at this stage I am only looking at configuration but this
new context will be updated to support new authentication mechanisms
which will be used directly by the console instead of by the web
browser.  By moving credential handling from the web browser to the
console itself we will be able to relax our cross resource sharing
restrictions for this context maybe with configuration of allowed
origins.  This will also allow us to remove the current 'Logout' hack
that we have in the console and HTTP interface as the console will be
able to control exactly how long credentials are cached for.  This will
also have a useful side effect of allowing a user to open the admin
console multiple times with each instance authenticated as a different user.

At that point it will be possible for the console to be used with
alternative distribution approaches and also will provide a path where
additional SSO mechanisms can be used as these also have a requirement
on CORS.

I will send round some design ideas / config examples next week but if
there are any additional demands on the HTTP management interface in
addition to a path to enabling alternative distribution approaches and
the enablement of SSO not is the time to speak up ;-)

Regards,
Darran Lofthouse.

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

Re: Enhancing the HTTP Management Interface Configuration - WFLY-2635

Stan Silvert
On 5/1/2014 2:05 PM, Darran Lofthouse wrote:

> I am just about to work on the outstanding task to enhance the
> configuration to the HTTP management interface and add some additional
> capabilities to it so this mail is really a FYI for those interested as
> numerous teams have interest in this area.
>
> The parent Jira issue is here: -
>     https://issues.jboss.org/browse/WFLY-2635
>
> At the moment there are not many configuration options for the HTTP
> interface and we make a lot of decisions ourselves as to how it is
> assembled, we now need some additional flexibility.
>
> For the admin console there is a desire to enable alternative
> distribution mechanisms so that the console can be served up from
> elsewhere.  There are no plans to remove the admin console from the
> WildFly distribution but users may want to switch to a different
> version.  For this reason I plan to add configuration for the /console
> context to make it possible to either disable the bundles console or to
> respond to requests for the console with a redirect.
We might also need another static-content context in addition to
/console.  I'm thinking that the Keycloak console will probably need to
be accessed from the domain controller in the same manner as the web
console.

>
> When we first authentication approaches for the HTTP management
> operations we decided to use standard HTTP authentication mechanisms so
> that clients could be written in many languages without imposing a
> requirement other than the support of standard mechanisms.  This in turn
> has some problems with web browsers calling the management interface so
> cross origin resource sharing has been completely disabled to protect
> against malicious cross site scripting attacks.  My intention is that
> this /management context will remain as a legacy context (not
> deprecated) so that clients written to use it can still do so - we may
> choose to have it switched off by default but enabling this context will
> be a config item.
>
> The next step will be the introduction of a new management context with
> a new name, at this stage I am only looking at configuration but this
> new context will be updated to support new authentication mechanisms
> which will be used directly by the console instead of by the web
> browser.  By moving credential handling from the web browser to the
> console itself we will be able to relax our cross resource sharing
> restrictions for this context maybe with configuration of allowed
> origins.  This will also allow us to remove the current 'Logout' hack
> that we have in the console and HTTP interface as the console will be
> able to control exactly how long credentials are cached for.  This will
> also have a useful side effect of allowing a user to open the admin
> console multiple times with each instance authenticated as a different user.
>
> At that point it will be possible for the console to be used with
> alternative distribution approaches and also will provide a path where
> additional SSO mechanisms can be used as these also have a requirement
> on CORS.
>
> I will send round some design ideas / config examples next week but if
> there are any additional demands on the HTTP management interface in
> addition to a path to enabling alternative distribution approaches and
> the enablement of SSO not is the time to speak up ;-)
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> 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: Enhancing the HTTP Management Interface Configuration - WFLY-2635

Stan Silvert
In reply to this post by Darran Lofthouse
On 5/1/2014 2:05 PM, Darran Lofthouse wrote:

> I am just about to work on the outstanding task to enhance the
> configuration to the HTTP management interface and add some additional
> capabilities to it so this mail is really a FYI for those interested as
> numerous teams have interest in this area.
>
> The parent Jira issue is here: -
>     https://issues.jboss.org/browse/WFLY-2635
>
> At the moment there are not many configuration options for the HTTP
> interface and we make a lot of decisions ourselves as to how it is
> assembled, we now need some additional flexibility.
>
> For the admin console there is a desire to enable alternative
> distribution mechanisms so that the console can be served up from
> elsewhere.  There are no plans to remove the admin console from the
> WildFly distribution but users may want to switch to a different
> version.  For this reason I plan to add configuration for the /console
> context to make it possible to either disable the bundles console or to
> respond to requests for the console with a redirect.
>
> When we first authentication approaches for the HTTP management
> operations we decided to use standard HTTP authentication mechanisms so
> that clients could be written in many languages without imposing a
> requirement other than the support of standard mechanisms.  This in turn
> has some problems with web browsers calling the management interface so
> cross origin resource sharing has been completely disabled to protect
> against malicious cross site scripting attacks.  My intention is that
> this /management context will remain as a legacy context (not
> deprecated) so that clients written to use it can still do so - we may
> choose to have it switched off by default but enabling this context will
> be a config item.
>
> The next step will be the introduction of a new management context with
> a new name, at this stage I am only looking at configuration but this
> new context will be updated to support new authentication mechanisms
> which will be used directly by the console instead of by the web
> browser.  By moving credential handling from the web browser to the
> console itself we will be able to relax our cross resource sharing
> restrictions for this context maybe with configuration of allowed
> origins.  This will also allow us to remove the current 'Logout' hack
> that we have in the console and HTTP interface as the console will be
> able to control exactly how long credentials are cached for.  This will
> also have a useful side effect of allowing a user to open the admin
> console multiple times with each instance authenticated as a different user.
What is meant by "moving credential handling from the web browser to the
console itself"?

>
> At that point it will be possible for the console to be used with
> alternative distribution approaches and also will provide a path where
> additional SSO mechanisms can be used as these also have a requirement
> on CORS.
>
> I will send round some design ideas / config examples next week but if
> there are any additional demands on the HTTP management interface in
> addition to a path to enabling alternative distribution approaches and
> the enablement of SSO not is the time to speak up ;-)
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> 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: Enhancing the HTTP Management Interface Configuration - WFLY-2635

jtgreene
Administrator

On May 1, 2014, at 3:08 PM, Stan Silvert <[hidden email]> wrote:

> What is meant by "moving credential handling from the web browser to the
> console itself”?

He means doing auth in the JS code itself.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


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

Re: Enhancing the HTTP Management Interface Configuration - WFLY-2635

jtgreene
Administrator
In reply to this post by Darran Lofthouse
We also should look at automating SSL setup, although maybe thats a different topic.

On May 1, 2014, at 1:05 PM, Darran Lofthouse <[hidden email]> wrote:

> I am just about to work on the outstanding task to enhance the
> configuration to the HTTP management interface and add some additional
> capabilities to it so this mail is really a FYI for those interested as
> numerous teams have interest in this area.
>
> The parent Jira issue is here: -
>   https://issues.jboss.org/browse/WFLY-2635
>
> At the moment there are not many configuration options for the HTTP
> interface and we make a lot of decisions ourselves as to how it is
> assembled, we now need some additional flexibility.
>
> For the admin console there is a desire to enable alternative
> distribution mechanisms so that the console can be served up from
> elsewhere.  There are no plans to remove the admin console from the
> WildFly distribution but users may want to switch to a different
> version.  For this reason I plan to add configuration for the /console
> context to make it possible to either disable the bundles console or to
> respond to requests for the console with a redirect.
>
> When we first authentication approaches for the HTTP management
> operations we decided to use standard HTTP authentication mechanisms so
> that clients could be written in many languages without imposing a
> requirement other than the support of standard mechanisms.  This in turn
> has some problems with web browsers calling the management interface so
> cross origin resource sharing has been completely disabled to protect
> against malicious cross site scripting attacks.  My intention is that
> this /management context will remain as a legacy context (not
> deprecated) so that clients written to use it can still do so - we may
> choose to have it switched off by default but enabling this context will
> be a config item.
>
> The next step will be the introduction of a new management context with
> a new name, at this stage I am only looking at configuration but this
> new context will be updated to support new authentication mechanisms
> which will be used directly by the console instead of by the web
> browser.  By moving credential handling from the web browser to the
> console itself we will be able to relax our cross resource sharing
> restrictions for this context maybe with configuration of allowed
> origins.  This will also allow us to remove the current 'Logout' hack
> that we have in the console and HTTP interface as the console will be
> able to control exactly how long credentials are cached for.  This will
> also have a useful side effect of allowing a user to open the admin
> console multiple times with each instance authenticated as a different user.
>
> At that point it will be possible for the console to be used with
> alternative distribution approaches and also will provide a path where
> additional SSO mechanisms can be used as these also have a requirement
> on CORS.
>
> I will send round some design ideas / config examples next week but if
> there are any additional demands on the HTTP management interface in
> addition to a path to enabling alternative distribution approaches and
> the enablement of SSO not is the time to speak up ;-)
>
> Regards,
> Darran Lofthouse.
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


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

Re: Enhancing the HTTP Management Interface Configuration - WFLY-2635

Heiko Braun
In reply to this post by Darran Lofthouse
If i understand it correctly, the new auth method you mention has no relation to sso (the brno design decisions, right?). Maybe its worth exploring the commonalities and differences to see if we can move to keycloak right away? Assuming that we dont wont two pssible authentication options. The way i see it keycloak sso would be a replacement for the new auth method you desribe, right?

Heiko



> Am 01.05.2014 um 20:05 schrieb Darran Lofthouse <[hidden email]>:
>
> I will send round some design ideas / config examples next week but if
> there are any additional demands on the HTTP management interface in
> addition to a path to enabling alternative distribution approaches and
> the enablement of SSO not is the time to speak up ;-)

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

Re: Enhancing the HTTP Management Interface Configuration - WFLY-2635

Jason T. Greene
I don't believe we want to require SSO out of the box. That would be too much infrastructure for a simple setup.

> On May 2, 2014, at 2:27 AM, Heiko Braun <[hidden email]> wrote:
>
> If i understand it correctly, the new auth method you mention has no relation to sso (the brno design decisions, right?). Maybe its worth exploring the commonalities and differences to see if we can move to keycloak right away? Assuming that we dont wont two pssible authentication options. The way i see it keycloak sso would be a replacement for the new auth method you desribe, right?
>
> Heiko
>
>
>
>> Am 01.05.2014 um 20:05 schrieb Darran Lofthouse <[hidden email]>:
>>
>> I will send round some design ideas / config examples next week but if
>> there are any additional demands on the HTTP management interface in
>> addition to a path to enabling alternative distribution approaches and
>> the enablement of SSO not is the time to speak up ;-)
>
> _______________________________________________
> 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: Enhancing the HTTP Management Interface Configuration - WFLY-2635

Brian Stansberry
I agree.

Sent from my iPhone

> On May 2, 2014, at 9:51 PM, "Jason T. Greene" <[hidden email]> wrote:
>
> I don't believe we want to require SSO out of the box. That would be too much infrastructure for a simple setup.
>
>> On May 2, 2014, at 2:27 AM, Heiko Braun <[hidden email]> wrote:
>>
>> If i understand it correctly, the new auth method you mention has no relation to sso (the brno design decisions, right?). Maybe its worth exploring the commonalities and differences to see if we can move to keycloak right away? Assuming that we dont wont two pssible authentication options. The way i see it keycloak sso would be a replacement for the new auth method you desribe, right?
>>
>> Heiko
>>
>>
>>
>>> Am 01.05.2014 um 20:05 schrieb Darran Lofthouse <[hidden email]>:
>>>
>>> I will send round some design ideas / config examples next week but if
>>> there are any additional demands on the HTTP management interface in
>>> addition to a path to enabling alternative distribution approaches and
>>> the enablement of SSO not is the time to speak up ;-)
>>
>> _______________________________________________
>> 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

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

Re: Enhancing the HTTP Management Interface Configuration - WFLY-2635

Darran Lofthouse
In reply to this post by jtgreene
On 01/05/14 22:45, Jason Greene wrote:
> We also should look at automating SSL setup, although maybe thats a different topic.

+1 That is a separate topic I will start on shortly where I am going to
pull together the 'backlog' of SSL related enhancements including the
unification of SSL configuration across WildFly.

That will in turn lead to the point where we can simplify the enablement
and also other items that we have discussed such as strongly encouraging
it is enabled.

> On May 1, 2014, at 1:05 PM, Darran Lofthouse <[hidden email]> wrote:
>
>> I am just about to work on the outstanding task to enhance the
>> configuration to the HTTP management interface and add some additional
>> capabilities to it so this mail is really a FYI for those interested as
>> numerous teams have interest in this area.
>>
>> The parent Jira issue is here: -
>>    https://issues.jboss.org/browse/WFLY-2635
>>
>> At the moment there are not many configuration options for the HTTP
>> interface and we make a lot of decisions ourselves as to how it is
>> assembled, we now need some additional flexibility.
>>
>> For the admin console there is a desire to enable alternative
>> distribution mechanisms so that the console can be served up from
>> elsewhere.  There are no plans to remove the admin console from the
>> WildFly distribution but users may want to switch to a different
>> version.  For this reason I plan to add configuration for the /console
>> context to make it possible to either disable the bundles console or to
>> respond to requests for the console with a redirect.
>>
>> When we first authentication approaches for the HTTP management
>> operations we decided to use standard HTTP authentication mechanisms so
>> that clients could be written in many languages without imposing a
>> requirement other than the support of standard mechanisms.  This in turn
>> has some problems with web browsers calling the management interface so
>> cross origin resource sharing has been completely disabled to protect
>> against malicious cross site scripting attacks.  My intention is that
>> this /management context will remain as a legacy context (not
>> deprecated) so that clients written to use it can still do so - we may
>> choose to have it switched off by default but enabling this context will
>> be a config item.
>>
>> The next step will be the introduction of a new management context with
>> a new name, at this stage I am only looking at configuration but this
>> new context will be updated to support new authentication mechanisms
>> which will be used directly by the console instead of by the web
>> browser.  By moving credential handling from the web browser to the
>> console itself we will be able to relax our cross resource sharing
>> restrictions for this context maybe with configuration of allowed
>> origins.  This will also allow us to remove the current 'Logout' hack
>> that we have in the console and HTTP interface as the console will be
>> able to control exactly how long credentials are cached for.  This will
>> also have a useful side effect of allowing a user to open the admin
>> console multiple times with each instance authenticated as a different user.
>>
>> At that point it will be possible for the console to be used with
>> alternative distribution approaches and also will provide a path where
>> additional SSO mechanisms can be used as these also have a requirement
>> on CORS.
>>
>> I will send round some design ideas / config examples next week but if
>> there are any additional demands on the HTTP management interface in
>> addition to a path to enabling alternative distribution approaches and
>> the enablement of SSO not is the time to speak up ;-)
>>
>> Regards,
>> Darran Lofthouse.
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Enhancing the HTTP Management Interface Configuration - WFLY-2635

Darran Lofthouse
In reply to this post by Stan Silvert
In general however this configuration is structured I think it does make
sense to structure it in a way that would allow additional contexts to
be added, that way whether it is used as an EE server or as the cut down
core with something else added on top alternatives could be added.

One point to keep in mind however is at the moment we are talking about
something running in a host controller so we have no access to a servlet
container.

On 01/05/14 21:03, Stan Silvert wrote:
> We might also need another static-content context in addition to
> /console.  I'm thinking that the Keycloak console will probably need to
> be accessed from the domain controller in the same manner as the web
> console.
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev