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