Uploaded image for project: 'WildFly Core'
  1. WildFly Core
  2. WFCORE-5081

Misleading warnings when management interfaces not secured.

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • Major
    • None
    • None
    • Management, Remoting
    • None

    Description

      Where the following configuration exists in a standlone.xml:

              <management-interfaces>
                  <http-interface>
                      <http-upgrade enabled="true"/>
                      <socket-binding http="management-http"/>
                  </http-interface>
              </management-interfaces>
      
              <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>
      

      We can see the following two warnings logged:

      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.
      
      10:31:47,852 WARN  [org.jboss.as.remoting] (MSC service thread 1-7) ****** All authentication is ANONYMOUS for org.jboss.as.remoting.RemotingHttpUpgradeService
      

      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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            darran.lofthouse@redhat.com Darran Lofthouse
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: