Unable to add attribute 'http-authentication-factory' to 'application-security-domain' in WildFly 34-37

45 views
Skip to first unread message

Arthur Messerschmitt

unread,
Jul 31, 2025, 11:17:42 AMJul 31
to WildFly
Good day,

I have an issue I can't work around.
In my standalone-full.xml config, I am trying to add the attribute 'http-authentication-factory' to my 'application-security-domain' in both the Undertow and EJB subsystems.
But no matter what I input, I receive the following error:

OPVDX001: Validation error in standalone-full.xml ------------------------------
|
|  608:     </handlers>
|  609:     <application-security-domains>
|  610:         <application-security-domain name="other" http-authentication-factory="my-http-authentication"/>
|                                                         ^^^^ 'http-authentication-factory' isn't an allowed attribute for the
|                                                                'application-security-domain' element
|
|                                                              Attributes allowed here are: enable-jacc,
|                                                                legacy-compliant-principal-propagation, name, security-domain
|
|  611:     </application-security-domains>
|  612: </subsystem>
|  613: <subsystem xmlns="urn:jboss:domain:webservices:2.0" statistics-enabled="${wildfly.webservices.statistics-enabled:${wildfly.statistics-enabled:false}}">
|
| 'http-authentication-factory' is allowed on elements:
| - server > management > management-interfaces > http-interface
| - server > profile > {urn:jboss:domain:undertow:community:14.0}subsystem > server > host > http-invoker
| - server > profile > {urn:jboss:domain:undertow:community:14.0}subsystem > application-security-domains > application-security-domain
|
|
| The primary underlying error message was:
| > ParseError at [row,col]:[288,114]
| > Message: WFLYCTL0197: Unexpected attribute
| >   'http-authentication-factory' encountered
|
|-------------------------------------------------------------------------------

16:44:46,747 ERROR [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0055: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0085: Failed to parse configuration
        at org.jboss.a...@29.0.0.Beta6//org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:123)
        at org.jboss...@29.0.0.Beta6//org.jboss.as.server.ServerService.boot(ServerService.java:386)
        at org.jboss.a...@29.0.0.Beta6//org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:360)
        at java.base/java.lang.Thread.run(Thread.java:842)

The highlighted lines contradict each other in the same error message. I can confirm that my line 610 is indeed specified in server > profile >
subsystem xmlns="urn:jboss:domain:undertow:community:14.0" > application-security-domains > application-security-domain

The official xsd for undertow supports that this should be possible:
Line 1016 there shows that http-authentication-factory is a String attribute of applicationSecurityDomainType (= application-security-domain).

I have tried this with WildFly 34.0.1.Final, 35.0.1.Final, 36.0.1.Final and 37.0.0.Beta1 (all the latests), with the same result.
I am using JDK 21 for this (and have tested on WF 37 with JDK 17 as well).

This used to work in WildFly 14. Is this a bug? Or did I write something wrong? I have tried to work around, to no avail.

Thank you for your time

Regards,
Arthur

Darran Lofthouse

unread,
Jul 31, 2025, 11:47:39 AMJul 31
to WildFly
This sounds bizarre.

FYI this should not be possible on the EJB3 subsystem, the EJB3 subsystem does not handle it's own transport so does not have it's own authentication instead it just uses the SecurityDomain for authorization decisions using the previously authenticated identity.

I have just tried this in the Undertow subsystem on the latest WildFly build and this works fine:

            <application-security-domains>
                <application-security-domain name="other" http-authentication-factory="application-http-authentication"/>
            </application-security-domains>


What is the XML namespace at the top of your Undertow subsystem configuration?

Arthur Messerschmitt

unread,
Jul 31, 2025, 12:05:53 PMJul 31
to Darran Lofthouse, WildFly
My namespace is xmlns="urn:jboss:domain:undertow:community:14.0", this seems to be the latest version, used by all WildFly versions I have tested.

You are right, EJB3 does not accept http-authentication-factory (you can see this on the xsd here : https://github.com/wildfly/wildfly/blob/main/ejb3/src/main/resources/schema/wildfly-ejb3_10_0.xsd (line 481, no mention of http-authentication-factory, only security-domain).

I was confused by the error does talking about Undertow. Does the validator mix up the two config both using 'application-security-domains'? (I was surprised that it caught the undertow error before EJB, as EJB is higher in the file)

I will try tomorrow to replace 'http-authentication-factory' in EJB3's config with the security domain used in the factory, and see if I see something different.

Thank you for your answer.

From: 'Darran Lofthouse' via WildFly <wil...@googlegroups.com>
Sent: Thursday, July 31, 2025 5:47:38 PM
To: WildFly <wil...@googlegroups.com>
Subject: Re: Unable to add attribute 'http-authentication-factory' to 'application-security-domain' in WildFly 34-37
 
--
You received this message because you are subscribed to a topic in the Google Groups "WildFly" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wildfly/qCcXVd8NlIA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/0be0aad2-78c8-46b9-85a7-a0133fcf3800n%40googlegroups.com.

Darran Lofthouse

unread,
Jul 31, 2025, 12:27:31 PMJul 31
to Arthur Messerschmitt, WildFly
I am not sure how it generates that error message, it may just be searching all schemas for places that attribute is allowed.

You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/VE1P192MB078139BF03C9C9E7939A05EBA927A%40VE1P192MB0781.EURP192.PROD.OUTLOOK.COM.

Arthur Messerschmitt

unread,
Aug 1, 2025, 4:49:23 AMAug 1
to WildFly
It works!
Replacing 'application-security-domain' with 'security-domain' in the EJB subsystem fixes the validator's error, and WildFly accepts it in Undertow.
This could probably be a bug report for the validator, but I don't know where to report it. Hoping this conversation will help others running into this issue.
Thank you for your help!

Bartosz Baranowski

unread,
Aug 1, 2025, 5:10:34 AMAug 1
to WildFly

Brian Stansberry

unread,
Aug 1, 2025, 11:11:11 AMAug 1
to WildFly
Thanks, Arthur, for filing https://issues.redhat.com/browse/WFLY-20820.

Going forward I'll comment on the JIRA, but since others are following this thread I'll post an initial thought here.

I haven't tried to reproduce this myself yet, but looking at the original post that shows the OPVDX001 message, the fundamental problem is the lines of XML it writes -- the ones starting  with line numbers like '608:' etc. Note that those don't match to the 'The primary underlying error message was:| > ParseError at [row,col]:[288,114]' content.

That's the bug. The other stuff it writes is all valid, but, because it writes incorrect surrounding xml, the "'http-authentication-factory' is allowed on elements:" stuff becomes a source of confusion instead of being possibly useful information.

Beyond fixing the bug, a possible enhancement would be to change the "'http-authentication-factory' isn't an allowed attribute for the 'application-security-domain' element" to append "in <the_namespace>". Besides acting as further info about context beyond the surrounding xml, it can help emphasize the relevant namespace; e.g. for situations where people are using things valid in one version of the schema but not others.
Reply all
Reply to author
Forward
0 new messages