[JBoss JIRA] (ELY-476) Arrays clone() does not work in static method of interface for IBM JDK
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/ELY-476?page=com.atlassian.jira.plugin.sy... ]
Peter Palaga resolved ELY-476.
------------------------------
Resolution: Out of Date
I cannot see any of the named tests failing as of ibm-java-sdk-8.0-4.10-x86_64. Thus closing as out of date.
> Arrays clone() does not work in static method of interface for IBM JDK
> ----------------------------------------------------------------------
>
> Key: ELY-476
> URL: https://issues.jboss.org/browse/ELY-476
> Project: WildFly Elytron
> Issue Type: Bug
> Affects Versions: 1.1.0.Beta4
> Reporter: Ondrej Lukas
> Priority: Critical
>
> It seems IBM JDK has an issue with using clone() method for arrays in static method of interface. Using arrays clone() method causes following exception for IBM JDK:
> {code}
> java.lang.IllegalAccessError: Class org/wildfly/security/password/interfaces/SaltedSimpleDigestPassword illegally accessing "protected" member of class [B
> at org.wildfly.security.password.interfaces.SaltedSimpleDigestPassword.createRaw(SaltedSimpleDigestPassword.java:112)
> ...
> {code}
> Issue affects only direct usage of arrays clone() method from static method of interface.
> Example, calling methodWillFail() will fail with IBM JDK:
> {code}
> public interface SimpleInterface {
> static int[] methodWillFail() {
> int[] array = {1, 2};
> return array.clone();
> }
> }
> {code}
> Workaround is simple. Calling static method of another class using arrays clone() works for IBM JDK 8.
> Example, calling methodWillNotFail() will pass with IBM JDK:
> {code}
> public interface SimpleInterface {
> static int[] methodWillNotFail() {
> return SimpleClass.methodOk();
> }
> }
> public class SimpleClass {
> static int[] methodOk() {
> int[] array = {1, 2};
> return array.clone();
> }
> }
> {code}
> Affected interfaces:
> org.wildfly.security.auth.server.NameRewriter.java
> org.wildfly.security.authz.RoleMapper.java
> org.wildfly.security.password.interfaces.SaltedSimpleDigestPassword.java
> org.wildfly.security.password.interfaces.OneTimePassword.java
> org.wildfly.security.password.interfaces.BSDUnixDESCryptPassword.java
> org.wildfly.security.password.interfaces.BCryptPassword.java
> org.wildfly.security.password.interfaces.SimpleDigestPassword.java
> org.wildfly.security.password.interfaces.DigestPassword.java
> org.wildfly.security.password.interfaces.ScramDigestPassword.java
> org.wildfly.security.ssl.SNIServerSSLContextSelector.java
> This issue causes errors in following test cases running with IBM JDK:
> org.wildfly.security.auth.KeyStoreBackedSecurityRealmTest
> org.wildfly.security.auth.realm.jdbc.PasswordSupportTest
> org.wildfly.security.password.impl.BCryptPasswordTest
> org.wildfly.security.auth.realm.ldap.UserPasswordPasswordUtilTest
> org.wildfly.security.ldap.PasswordSupportSuiteChild
> org.wildfly.security.password.impl.BSDUnixDESCryptTest
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ELY-1345) ExceptionInInitializerError in tests on IBM reintroduced by commit 362aa0e
by Peter Palaga (JIRA)
Peter Palaga created ELY-1345:
---------------------------------
Summary: ExceptionInInitializerError in tests on IBM reintroduced by commit 362aa0e
Key: ELY-1345
URL: https://issues.jboss.org/browse/ELY-1345
Project: WildFly Elytron
Issue Type: Bug
Reporter: Peter Palaga
Assignee: Peter Palaga
[~ctomc] 's commit broke my older fix for ELY-534. Due to that, some tests are erroring again with a {{ExceptionInInitializerError}} -javaagent:${org.jmockit:jmockit:jar} is still required, even with {{ibm-java-sdk-8.0-4.10-x86_64}} and jmockit 1.33
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by charles ghislain (JIRA)
[ 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;
var failures = [];
var responseCount = 0;
let url = 'http://localhost:8080/ws-1.0-SNAPSHOT/test';
function onReqLoad(index, event, xhr) {
if (xhr.readyState === 4) {
responseCount++;
console.log(index + ' ' + xhr.status);
if (xhr.status >= 400) {
failures.push(index);
}
}
}
function doit() {
var i = 0;
while (i < count) {
let xhr = new XMLHttpRequest();
let index = i;
xhr.addEventListener('load', function (event) {
onReqLoad(index, event, xhr)
}
);
xhr.open('GET', url);
xhr.setRequestHeader('Authorization', 'Basic dGVzdC1hZXJhOnRlc3Rlc3Rlc3Q=');
xhr.withCredentials = true;
xhr.send();
i++
}
}
function logStatus() {
console.log('totlal: ' + responseCount + ' ; failures:');
console.log(failures);
}
doit();
window.setTimeout(function(){logStatus();}, 30000);
{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:
{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;
var failures = [];
var responseCount = 0;
let url = 'http://localhost:8080/ws-1.0-SNAPSHOT/test';
function onReqLoad(index, event, xhr) {
if (xhr.readyState === 4) {
responseCount++;
console.log(index + ' ' + xhr.status);
if (xhr.status >= 400) {
failures.push(index);
}
}
}
function doit() {
var i = 0;
while (i < count) {
let xhr = new XMLHttpRequest();
let index = i;
xhr.addEventListener('load', function (event) {
onReqLoad(index, event, xhr)
}
);
xhr.open('GET', url);
xhr.setRequestHeader('Authorization', 'Basic dGVzdC1hZXJhOnRlc3Rlc3Rlc3Q=');
xhr.withCredentials = true;
xhr.send();
i++
}
}
function logStatus() {
console.log('totlal: ' + responseCount + ' ; failures:');
console.log(failures);
}
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.
> 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)
8 years, 8 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by charles ghislain (JIRA)
[ 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;
var failures = [];
var responseCount = 0;
let url = 'http://localhost:8080/ws-1.0-SNAPSHOT/test';
function onReqLoad(index, event, xhr) {
if (xhr.readyState === 4) {
responseCount++;
console.log(index + ' ' + xhr.status);
if (xhr.status >= 400) {
failures.push(index);
}
}
}
function doit() {
var i = 0;
while (i < count) {
let xhr = new XMLHttpRequest();
let index = i;
xhr.addEventListener('load', function (event) {
onReqLoad(index, event, xhr)
}
);
xhr.open('GET', url);
xhr.setRequestHeader('Authorization', 'Basic dGVzdC1hZXJhOnRlc3Rlc3Rlc3Q=');
xhr.withCredentials = true;
xhr.send();
i++
}
}
function logStatus() {
console.log('totlal: ' + responseCount + ' ; failures:');
console.log(failures);
}
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:
{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.
> 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)
8 years, 8 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by charles ghislain (JIRA)
[ 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)
8 years, 8 months
[JBoss JIRA] (WFLY-9251) Security context is not thread safe
by charles ghislain (JIRA)
[ https://issues.jboss.org/browse/WFLY-9251?page=com.atlassian.jira.plugin.... ]
charles ghislain updated WFLY-9251:
-----------------------------------
Attachment: wildflytestauthcontext-2.zip
> 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)
8 years, 8 months