[
https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin....
]
charles ghislain updated WFLY-9251:
-----------------------------------
Steps to Reproduce:
Please see the attached POC for reproduction:
- Build the maven project
- Place the authmodule jar in a wildfly module, along with a module descriptor:
{noformat}
<module xmlns="urn:jboss:module:1.3"
name="be.test.testauthmodule">
<dependencies>
<!-- Needed for javax.security.auth -->
<module name="javax.api" export="false"/>
<module name="org.apache.logging.log4j"/>
</dependencies>
<resources>
<resource-root path="authmodule-1.0-SNAPSHOT.jar"/>
</resources>
</module>
{noformat}
- Make sure it is loaded eagerly:
{noformat}
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<global-modules>
<module name="be.test.testauthmodule"/>
{noformat}
- Specify the realm and login module in the standalone config:
{noformat}
<security-domain name="TestSecurityDomain"
cache-type="default">
<authentication>
<login-module code="be.test.TestLoginModule"
flag="required"/>
<login-module
code="org.jboss.security.ClientLoginModule" flag="optional"/>
</authentication>
</security-domain>
{noformat}
{noformat}
<security-realm name="TestRealm">
<authentication>
<jaas name="TestSecurityDomain"/>
</authentication>
</security-realm>
{noformat}
- Deploy the war to your wildfly instance
- Make sure you have several worker threads. In the IO subsystem, I use 8 IO threads and
64 task threads.
- Launch a bunch of requests simultaneously. Requests must authenticate themeselves using
a Basic Authorization header with a login starting by 'test-' to pass
authorization. You could paste the following snippet in the browser js console opened from
a page serving your wildfly content (to avoid cors):
{noformat}
var count = 500;
let url = 'http://localhost:8080/ws-1.0-SNAPSHOT/test';
function onReqLoad(index, event, xhr) {
if (xhr.readyState === 4) {
console.log(index + ' ' + xhr.status);
}
}
function doit() {
var i = 0;
while (i < count) {
let xhr = new XMLHttpRequest();
xhr.addEventListener('load', function (event) {
onReqLoad(i, event, xhr)
});
xhr.open('GET', url);
xhr.setRequestHeader('Authorization', 'Basic
dGVzdC1hZXJhOnRlc3Rlc3Rlc3Q=');
xhr.withCredentials = true;
xhr.send();
i++
}
}
doit();
{noformat}
You should notice some requests getting a 401 response, while most of them get the
expected 200.
I you modify your wildfly config to use only a single worker thread and a single task
thread, then you should notice that all requests pass, although it takes much longer for
the server to process them.
was:
Please see the attached POC for reproduction:
- Build the maven project
- Place the authmodule jar in a wildfly module, along with a module descriptor:
{{<module xmlns="urn:jboss:module:1.3"
name="be.test.testauthmodule">
<dependencies>
<!-- Needed for javax.security.auth -->
<module name="javax.api" export="false"/>
<module name="org.apache.logging.log4j"/>
</dependencies>
<resources>
<resource-root path="authmodule-1.0-SNAPSHOT.jar"/>
</resources>
</module>}}
Make sure it is loaded eagerly:
{{
<subsystem xmlns="urn:jboss:domain:ee:4.0">
<global-modules>
<module name="be.test.testauthmodule"/>
}}
- Specify the realm and login module in the standalone config:
{{ <security-domain name="TestSecurityDomain"
cache-type="default">
<authentication>
<login-module code="be.test.TestLoginModule"
flag="required"/>
<login-module
code="org.jboss.security.ClientLoginModule" flag="optional"/>
</authentication>
</security-domain>
}}
{{
<security-realm name="TestRealm">
<authentication>
<jaas name="TestSecurityDomain"/>
</authentication>
</security-realm>
}}
- Deploy the war to your wildfly instance
- Make sure you have several worker threads. In the IO subsystem, I use 8 IO threads and
64 task threads.
- Launch a bunch of requests simultaneously. Requests must authenticate themeselves using
a Basic Authorization header with a login starting by 'test-' to pass
authorization. You could paste the following snippet in the browser js console opened from
a page serving your wildfly content (to avoid cors):
{{
var count = 500;
let url = 'http://localhost:8080/ws-1.0-SNAPSHOT/test';
function onReqLoad(index, event, xhr) {
if (xhr.readyState === 4) {
console.log(index + ' ' + xhr.status);
}
}
function doit() {
var i = 0;
while (i < count) {
let xhr = new XMLHttpRequest();
xhr.addEventListener('load', function (event) {
onReqLoad(i, event, xhr)
});
xhr.open('GET', url);
xhr.setRequestHeader('Authorization', 'Basic
dGVzdC1hZXJhOnRlc3Rlc3Rlc3Q=');
xhr.withCredentials = true;
xhr.send();
i++
}
}
doit();
}}
You should notice some requests getting a 401 response, while most of them get the
expected 200.
I you modify your wildfly config to use only a single worker thread and a single task
thread, then you should notice that all requests pass, although it takes much longer for
the server to process them.
Security context is not thread safe
-----------------------------------
Key: WFLY-9251
URL:
https://issues.jboss.org/browse/WFLY-9251
Project: WildFly
Issue Type: Bug
Components: Security
Affects Versions: 10.1.0.Final
Environment: Windows, LInux
Reporter: charles ghislain
Assignee: Darran Lofthouse
Labels: jaas, security, security-context, thread-safety, threads
Attachments: wildflytestauthcontext-2.zip, wildflytestauthcontext.zip
Using a custom JAAS login module, we sometimes fail to obtain the authenticated subject
from the 'javax.security.auth.Subject.container' policy context. This appear to be
related to the worker threads.
See the reproduction steps below. When a wildfly instance attempts to authenticate 500
requests coming simultaneously, a bunch of them fail. If you configure wildfly to only use
a single worker thread and a single task thread, this issue disappears.
The issue is as follow:
I login using HttpServletRequest#login.
Right after that, login.getUserPrincipal return the correct principal.
However, sometimes,
PolicyContext.getContext("javax.security.auth.Subject.container") returns null.
Right after the login.
In our production app,
PolicyContext.getContext("javax.security.auth.Subject.container") returns null
during some EJB call, throwing random exceptions from various parts of the application.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)