[wildfly-dev] 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.