[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:
-----------------------------------
Description:
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.
was:
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.
> 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] (WFCORE-2797) http-remoting-connector attributes wrongly declared as "restart-required" => "no-services"
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2797?page=com.atlassian.jira.plugi... ]
Chao Wang reassigned WFCORE-2797:
---------------------------------
Assignee: Chao Wang (was: David Lloyd)
> http-remoting-connector attributes wrongly declared as "restart-required" => "no-services"
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-2797
> URL: https://issues.jboss.org/browse/WFCORE-2797
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Martin Choma
> Assignee: Chao Wang
>
> Changing http-remoting-connector leads to reload required state. But all attributes are marked as {{"restart-required" => "no-services"}} in model. Based on documentation [1] I think they should be rather {{"restart-required" => "resource-services"}}
> {code}
> [standalone@localhost:9990 /] /subsystem=remoting/http-connector=http-remoting-connector:read-resource-description
> {
> "outcome" => "success",
> "result" => {
> "description" => "The configuration of a HTTP Upgrade based Remoting connector.",
> "capabilities" => [{
> "name" => "org.wildfly.remoting.http-connector",
> "dynamic" => true
> }],
> "attributes" => {
> "authentication-provider" => {
> "type" => STRING,
> "description" => "The \"authentication-provider\" element contains the name of the authentication provider to use for incoming connections.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"remoting-security" => {"type" => "remoting"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "connector-ref" => {
> "type" => STRING,
> "description" => "The name (or names) of a connector in the Undertow subsystem to connect to.",
> "expressions-allowed" => false,
> "required" => true,
> "nillable" => false,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "sasl-authentication-factory" => {
> "type" => STRING,
> "description" => "Reference to the SASL authentication factory to use for this connector.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "nil-significant" => true,
> "capability-reference" => "org.wildfly.security.sasl-authentication-factory",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"authentication-factory-ref" => {"type" => "core"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "sasl-protocol" => {
> "type" => STRING,
> "description" => "The protocol to pass into the SASL mechanisms used for authentication.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "default" => "remote",
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"remoting-security" => {"type" => "remoting"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "security-realm" => {
> "type" => STRING,
> "description" => "The associated security realm to use for authentication for this connector.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {
> "security-realm-ref" => {"type" => "core"},
> "remoting-security" => {"type" => "remoting"}
> }},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> },
> "server-name" => {
> "type" => STRING,
> "description" => "The server name to send in the initial message exchange and for SASL based authentication.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "access-constraints" => {"sensitive" => {"remoting-security" => {"type" => "remoting"}}},
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> }
> },
> "operations" => undefined,
> "notifications" => undefined,
> "children" => {
> "security" => {
> "description" => "Configuration of security for this connector.",
> "model-description" => undefined
> },
> "property" => {
> "description" => "Properties to further configure the connector.",
> "model-description" => undefined
> }
> }
> },
> "response-headers" => {"process-state" => "reload-required"}
> }
> {code}
> [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1712) Disable Examples in KIE Workbench does not work
by Alberto Flores (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1712?page=com.atlassian.jira.plugi... ]
Alberto Flores updated DROOLS-1712:
-----------------------------------
Summary: Disable Examples in KIE Workbench does not work (was: Disable Examples in KIE Workbench)
> Disable Examples in KIE Workbench does not work
> -----------------------------------------------
>
> Key: DROOLS-1712
> URL: https://issues.jboss.org/browse/DROOLS-1712
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.2.0.Final
> Environment: Tomcat 8.5.20 - jdk 8
> Reporter: Alberto Flores
> Assignee: Edson Tirelli
> Priority: Minor
>
> Per the documentation, to disable the examples that come with the KIE workbench installation can be disabled using the flags {{-Dorg.kie.example=false}} and {{-Dorg.kie.demo=false}}. I tried this in my local Tomcat installation and I still had the examples in the deployed war.
> The following is a sample of my setenv.sh in tomcat:
> {noformat}
> CATALINA_OPTS="-Xmx512M \
> -Djava.security.auth.login.config=$CATALINA_HOME/webapps/kie-drools-wb/WEB-INF/classes/login.config \
> -Dorg.jboss.logging.provider=jdk \
> -Dorg.uberfire.metadata.index.dir=$CATALINA_HOME/conf/workbench \
> -Dorg.uberfire.nio.git.dir=$CATALINA_HOME/conf/workbench \
> -Dorg.kie.example=false \
> -Dorg.kie.demo=false"
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (DROOLS-1712) Disable Examples in KIE Workbench
by Alberto Flores (JIRA)
Alberto Flores created DROOLS-1712:
--------------------------------------
Summary: Disable Examples in KIE Workbench
Key: DROOLS-1712
URL: https://issues.jboss.org/browse/DROOLS-1712
Project: Drools
Issue Type: Bug
Affects Versions: 7.2.0.Final
Environment: Tomcat 8.5.20 - jdk 8
Reporter: Alberto Flores
Assignee: Edson Tirelli
Priority: Minor
Per the documentation, to disable the examples that come with the KIE workbench installation can be disabled using the flags {{-Dorg.kie.example=false}} and {{-Dorg.kie.demo=false}}. I tried this in my local Tomcat installation and I still had the examples in the deployed war.
The following is a sample of my setenv.sh in tomcat:
{noformat}
CATALINA_OPTS="-Xmx512M \
-Djava.security.auth.login.config=$CATALINA_HOME/webapps/kie-drools-wb/WEB-INF/classes/login.config \
-Dorg.jboss.logging.provider=jdk \
-Dorg.uberfire.metadata.index.dir=$CATALINA_HOME/conf/workbench \
-Dorg.uberfire.nio.git.dir=$CATALINA_HOME/conf/workbench \
-Dorg.kie.example=false \
-Dorg.kie.demo=false"
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9256) Add ironjacamar.xsd
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-9256:
------------------------------------
Summary: Add ironjacamar.xsd
Key: WFLY-9256
URL: https://issues.jboss.org/browse/WFLY-9256
Project: WildFly
Issue Type: Bug
Components: JCA
Reporter: Flavia Rainone
Assignee: Flavia Rainone
Priority: Critical
Fix For: 11.0.0.CR1
The parsing of ironjacamar.xml is extended inside wildfly, but the xsd file is missing.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFCORE-3205) Logging does not work in the embedded server
by James Perkins (JIRA)
James Perkins created WFCORE-3205:
-------------------------------------
Summary: Logging does not work in the embedded server
Key: WFCORE-3205
URL: https://issues.jboss.org/browse/WFCORE-3205
Project: WildFly Core
Issue Type: Bug
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
When using the {{EmbeddedProcessFactory}} logging does not appear to work. Debugging shows a different {{LogContext}} associated with the loggers than the one associated with the logging subsystem.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (WFLY-9252) Redundant config restore before quorum configuration
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9252?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9252:
--------------------------------------
[~sgilda] I think that's good you added it - users will start from the exact same place so it will be less confusing - so the change here is mostly cosmetic. Maybe you were hitting the issue where toggling the policy was problematic (JBEAP-12252). Should you be trying these out again and hit the issue again, please let me know what the issue is.
> Redundant config restore before quorum configuration
> ----------------------------------------------------
>
> Key: WFLY-9252
> URL: https://issues.jboss.org/browse/WFLY-9252
> Project: WildFly
> Issue Type: Bug
> Components: Quickstarts
> Affects Versions: 11.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Minor
> Labels: eap7.1-ok-for-CR1
> Fix For: 11.0.0.CR1
>
>
> In ER3 there is a new instruction in {{Configure a Quorum for the Singleton Policy}} to restore the singleton election policy to default configuration:
> {{If you have tested other election policies that configured the singleton subsystem, see Restoring the Default Singleton Subsystem Configuration for instructions to restore the singleton election policy to the default configuration.}}
> I think this step should be either removed or reworded to avoid confusion. The reasons are:
> * Quorum can be specified for any election policy, not only for the default one.
> * Wording {{If you have tested other election policies}} suggests that this section configures another election policy, which is not true - it only adds quorum to existing election policy.
> [~rhusar], what do you think?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months