[wildfly-dev] Enhancing the HTTP Management Interface Configuration - WFLY-2635

[Jason Greene]

We also should look at automating SSL setup, although maybe thats a different topic.

On May 1, 2014, at 1:05 PM, Darran Lofthouse <darran.lofthouse at jboss.com> 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
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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