[jboss-jira] [JBoss JIRA] (WFCORE-5081) Misleading warnings when management interfaces not secured.

Darran Lofthouse (Jira) issues at jboss.org
Wed Aug 5 05:41:00 EDT 2020


Darran Lofthouse created WFCORE-5081:
----------------------------------------

             Summary: Misleading warnings when management interfaces not secured.
                 Key: WFCORE-5081
                 URL: https://issues.redhat.com/browse/WFCORE-5081
             Project: WildFly Core
          Issue Type: Bug
          Components: Management, Remoting
            Reporter: Darran Lofthouse


Where the following configuration exists in a standlone.xml:

{code:xml}
        <management-interfaces>
            <http-interface>
                <http-upgrade enabled="true"/>
                <socket-binding http="management-http"/>
            </http-interface>
        </management-interfaces>
{code}

{code:xml}
        <subsystem xmlns="urn:jboss:domain:remoting:4.0">
            <endpoint worker="default"/>
            <http-connector name="http-remoting-connector" connector-ref="default" sasl-authentication-factory="application-sasl-authentication"/>
        </subsystem>
{code}

We can see the following two warnings logged:

{code}
10:31:47,775 WARN  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0035: No security realm or http server authentication defined for http management service; all access will be unrestricted.
{code}

{code}
10:31:47,852 WARN  [org.jboss.as.remoting] (MSC service thread 1-7) ****** All authentication is ANONYMOUS for org.jboss.as.remoting.RemotingHttpUpgradeService
{code}

They appear quite a few messages apart in the console, it gives the impression by the time the second is logged start up has moved on from management and is now deploying the subsystems.

For the first message, when using Elytron security there is a http-authentication-factory and a sasl-authentication-factory, there is no mention of the second - both are important.

The second message is very generic as it reports itself in the context of a class which could be reused in a couple of different situations, it was originally added as a final catch all to be 100% sure we logged something but now this should be cleaned up.

The messages should be in the context of both resources i.e. make it very clear which resource is not secured rather than which class.  They should also be clearer about which attributes are missing and check the permutations.




--
This message was sent by Atlassian Jira
(v7.13.8#713008)


More information about the jboss-jira mailing list