EE Security - Disable HttpAuthenticationMechanism for static files

283 views
Skip to first unread message

David Baddeley

unread,
Oct 26, 2022, 8:49:14 AM10/26/22
to WildFly
Is it possible to disable authentication calls (using custom HttpAuthenticationMechanism implementation) for specific file types?

We would like to disable Weld context creation for all static file requests but cannot currently as our HttpAuthenticationMechanism implementation requires CDI

Paul Ferraro

unread,
Oct 26, 2022, 11:09:07 AM10/26/22
to WildFly
In your web.xml, create a <security-constraint/> without an <auth-constraint/>, and specify the static url-patterns that should be exempt from authentication/authorization.
e.g.
<security-constraint>
    <web-resource-collection>
        <web-resource-name>public</web-resource-name>
        <url-pattern>*.pdf</url-pattern>
        <http-method>GET</http-method>
    </web-resource-collection>
</security-constraint>

David Baddeley

unread,
Oct 26, 2022, 3:01:24 PM10/26/22
to WildFly
Thx Paul, I tried this but the HttpAuthenticationMechanism bean still seems to being invoked, see stack below

<security-constraint>
        <web-resource-collection>
            <web-resource-name>Static Content</web-resource-name>
            <url-pattern>*.css</url-pattern>
            <url-pattern>*.js</url-pattern>
            <url-pattern>*.png</url-pattern>
            <url-pattern>*.jpeg</url-pattern>
            <url-pattern>*.jpg</url-pattern>
            <url-pattern>*.gif</url-pattern>

            <http-method>GET</http-method>
        </web-resource-collection>
    </security-constraint>

19:55:51,163 ERROR [io.undertow.request] UT005023: Exception handling request to /apple-touch-icon.png: org.jboss.weld.contexts.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped
    at org.jboss...@3.1.9.Final//org.jboss.weld.manager.BeanManagerImpl.getContext(BeanManagerImpl.java:647)
    at org.jboss...@3.1.9.Final//org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:89)
    at org.jboss...@3.1.9.Final//org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.getIfExists(ContextualInstanceStrategy.java:164)
    at org.jboss...@3.1.9.Final//org.jboss.weld.bean.ContextualInstance.getIfExists(ContextualInstance.java:63)
    at org.jboss...@3.1.9.Final//org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:87)
    at org.jboss...@3.1.9.Final//org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
    at deployment.MyAppWeb-web.war//com.myapp.security.MyAppAuthentication$Proxy$_$$_WeldClientProxy.validateRequest(Unknown Source)
    at org.glassfish.soteria@1.1//org.glassfish.soteria.mechanisms.jaspic.HttpBridgeServerAuthModule.validateRequest(HttpBridgeServerAuthModule.java:89)
    at org.glassfish.soteria@1.1//org.glassfish.soteria.mechanisms.jaspic.DefaultServerAuthContext.validateRequest(DefaultServerAuthContext.java:52)
    at org.wildfly.security.elytron...@1.10.1.Final//org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl.authenticate(ServletSecurityContextImpl.java:182)
    at org.wildfly.security.elytron...@1.10.1.Final//org.wildfly.elytron.web.undertow.server.servlet.ServletSecurityContextImpl.authenticate(ServletSecurityContextImpl.java:99)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
    at io.under...@2.2.17.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at io.under...@2.2.17.Final//io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
    at io.under...@2.2.17.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
    at io.under...@2.2.17.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
    at org.wildfly.security.elytron...@1.10.1.Final//org.wildfly.elytron.web.undertow.server.servlet.CleanUpHandler.handleRequest(CleanUpHandler.java:38)
    at io.under...@2.2.17.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at org.wildfly.ext...@26.1.1.Final//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
    at io.under...@2.2.17.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at org.wildfly.ext...@26.1.1.Final//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
    at io.under...@2.2.17.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
    at io.under...@2.2.17.Final//io.undertow.server.handlers.MetricsHandler.handleRequest(MetricsHandler.java:64)
    at io.undert...@2.2.17.Final//io.undertow.servlet.core.MetricsChainHandler.handleRequest(MetricsChainHandler.java:59)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:275)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:79)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:134)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:131)
    at io.undert...@2.2.17.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
    at io.undert...@2.2.17.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
    at org.wildfly.ext...@26.1.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
    at org.wildfly.ext...@26.1.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
    at org.wildfly.ext...@26.1.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
    at org.wildfly.ext...@26.1.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
    at org.wildfly.ext...@26.1.1.Final//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1544)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:255)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:79)
    at io.undert...@2.2.17.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:100)
    at io.under...@2.2.17.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
    at io.under...@2.2.17.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:852)
    at org.jbos...@2.4.0.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
    at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
    at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
    at org.jbos...@2.4.0.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
    at org.jbo...@3.8.7.Final//org.xnio.XnioWorker$WorkerThreadFactory$1$1.run(XnioWorker.java:1282)
    at java.base/java.lang.Thread.run(Thread.java:833)

Paul Ferraro

unread,
Oct 27, 2022, 11:21:00 AM10/27/22
to WildFly
This suggests that your application defines another security constraint with a specific auth-constraint (probably one with a wildcard path, e.g. of the form /* or similar) that is taking precedence.
What other security-constraints does your application define, either in its web.xml, a web.xml fragment, or annotations?

David Baddeley

unread,
Oct 27, 2022, 11:30:51 AM10/27/22
to WildFly
We have some other constraints that match subfolder wildcards

But, for example, the static file referenced in the stack trace above was located in the root folder "/apple-touch-icon.png" that shouldn't match any of the constraints?

<security-constraint>
        <web-resource-collection>
            <web-resource-name>User Login Area</web-resource-name>
            <url-pattern>/user/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>user</role-name>
        </auth-constraint>
        <user-data-constraint>
           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
       </user-data-constraint>
    </security-constraint>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Client User Login Area</web-resource-name>
            <url-pattern>/client/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>clientUser</role-name>
        </auth-constraint>
        <user-data-constraint>
           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
       </user-data-constraint>
    </security-constraint>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Admin User Login Area</web-resource-name>
            <url-pattern>/admin/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>admin</role-name>
        </auth-constraint>
        <user-data-constraint>
           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
       </user-data-constraint>
    </security-constraint>

Paul Ferraro

unread,
Oct 27, 2022, 11:53:10 AM10/27/22
to WildFly
Yeah - none of those security constraints should match a static file in the root of your context path.
Can you think of any other constraints that might be defined in a web xml fragment, or maybe a jboss-web.xml?

It is certainly possible that there could be a bug in the security path matching algorithm, or perhaps the non-existent auth-constraint is getting the wrong EmptyRoleSemantic applied, but I just went over that code and did not find anything that looked suspicious.
Not that this is, by any means, a permanent solution, but can you verify that specifying an exact path in your "Static Content" web-resource-collection is getting handled correctly?
e.g. <url-pattern>apple-touch-icon.png</url-pattern>

That will at least give us a starting point for diagnosis.

David Baddeley

unread,
Oct 30, 2022, 6:33:44 AM10/30/22
to WildFly
Here is the contents of my jboss-web.xml, I did have our own Security Domain defined but I have since switched it to the default 'other' and still get the same behaviour

<?xml version="1.0" encoding="UTF-8"?>
<jboss-web>
    <virtual-host>myapp-webapp</virtual-host>
    <context-root>/</context-root>
    <max-active-sessions>2000</max-active-sessions>
    <security-domain>other</security-domain>
</jboss-web>

I tried what you suggested and specified an exact file in the web.xml <security-constraint> url-pattern but I am still getting the validateRequest() method being invoked

I have also tried specifying the subfolders where the static files are contained eg.

<security-constraint>
        <web-resource-collection>
            <web-resource-name>Static Content</web-resource-name>

            <url-pattern>/images/*</url-pattern>
            <url-pattern>/resources/*</url-pattern>
            <url-pattern>/jsJawrPath/*</url-pattern>
            <url-pattern>/javax.faces.resource/*</url-pattern>
        </web-resource-collection>
    </security-constraint>

But this doesn't seem to work either

Could it be some Elytron configuration that is overriding the EE Security spec?


Reply all
Reply to author
Forward
0 new messages