January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2003) Deliver message batches

by Bela Ban (JIRA)

Bela Ban created JGRP-2003: ------------------------------ Summary: Deliver message batches Key: JGRP-2003 URL: https://issues.jboss.org/browse/JGRP-2003 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0 Currently, message batches are sent up tp the channel, which delivers its messages one-by-one, e.g. by calling the {{Receiver.receive(Message msg)}} callback. Another callback {{Receiver.receive(MessageBatch batch)}} should be added (also to RpcDispatcher), to deliver a batch of messages at once. This should result in performance increase, as the application can handle multiple messages at once. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1135) Unable to start Wildfly when FIPS is enabled in Domain Mode

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1135?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-1135: ------------------------------------------ A server which is connecting back to it's HostController can be configured to use it's JVM wide default SSLContext by executing the following command: - {noformat} ./host=master/server-config=server-one/ssl=loopback:add(ssl-protocol=Default) {noformat} Alternatively a custom SSL configuration can be provided: - {noformat} ./host=master/server-config=server-three/ssl=loopback:add(ssl-protocol=TLS, trust-manager-algorithm=SunX509, truststore-type=JKS, truststore-path=/home/darranl/src/wildfly9/cli-scripts/management-ssl/client.keystore, truststore-password=keystore_password) {noformat} Note: With the exception of 'ssl-protocol' defaults are not represented in the management model as the JVM specific default values are used for 'trust-manager-algorithm' and 'truststore-type'. > Unable to start Wildfly when FIPS is enabled in Domain Mode > ----------------------------------------------------------- > > Key: WFCORE-1135 > URL: https://issues.jboss.org/browse/WFCORE-1135 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Affects Versions: 2.0.1.Final > Reporter: Ryan Emerson > Assignee: Darran Lofthouse > Fix For: 2.0.8.Final > > > Allow FIPS use in Domain mode. This requires additional logic to standalone, due to the connections between controllers and servers. > Resulting stacktrace when attempting to run domain mode with FIPS enabled at the JVM: > 15:47:39,410 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.host.controller.client: org.jboss.msc.service.StartException in service jboss.host.controller.client: java.io.IOException: WFLYSRV0117: Unable to initialise a basic SSLContext 'FIPS mode: only SunJSSE TrustManagers may be used' > [Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:133) > [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [Server:server-one] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [Server:server-one] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [Server:server-one] at java.lang.Thread.run(Thread.java:745) > [Server:server-one] Caused by: java.io.IOException: WFLYSRV0117: Unable to initialise a basic SSLContext 'FIPS mode: only SunJSSE TrustManagers may be used' > [Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.getAcceptingSSLContext(HostControllerConnectionService.java:212) > [Server:server-one] at org.jboss.as.server.mgmt.domain.HostControllerConnectionService.start(HostControllerConnectionService.java:108) > [Server:server-one] ... 5 more -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6004) JAASCallbackHandler resets SecurityContext after authentication to it's pre-authentication value

by Ian MacIntyre (JIRA)

[ https://issues.jboss.org/browse/WFLY-6004?page=com.atlassian.jira.plugin.... ] Ian MacIntyre commented on WFLY-6004: ------------------------------------- OK, thanks for that - will need to see what our original code was trying to do and fix it. > JAASCallbackHandler resets SecurityContext after authentication to it's pre-authentication value > ------------------------------------------------------------------------------------------------ > > Key: WFLY-6004 > URL: https://issues.jboss.org/browse/WFLY-6004 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.2.Final, 10.0.0.CR5 > Reporter: Ian MacIntyre > Assignee: Darran Lofthouse > Labels: remote-ejb-connection, roles > > We are using remote EJB calls and are finding role information being lost. > I have traced this to our use of JAAS authentication for the ApplicationRealm security realm > Within the handle() method of JaasCallbackHander it stores the current Security context at that point (via securityManager.push()) > It then calls securityManager.authenticate() which results in login modules being called. We use the ClientLoginModule which stores information on the SecurityContext via SecurityAssociationActions.setPrincipalInfo > After authentication the JaasCallbackHandler calls securityManager.pop() which resets the SecurityContext back its state before authentication - thus losing the context set in the ClientLoginModule. > This only occurs via a remote ejb call, not via a call made from the web tier (as it does not use JaasLoginHandler) > Ideally I'd like some way to stop the JaasCallbackHandler reseting the SecurityContext (even if it was incredibly simple by checking for an attribute on the current security context) > The same operations work in EAP 6.3 / JBoss 7.2 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6004) JAASCallbackHandler resets SecurityContext after authentication to it's pre-authentication value

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6004?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-6004. ------------------------------------ Resolution: Rejected The ClientLoginModule must never ever be used in this way - quite simply if there are ever bean to bean calls involving run as identities this login module risks getting the stack out of sync and effectively leaving requests running with random roles. > JAASCallbackHandler resets SecurityContext after authentication to it's pre-authentication value > ------------------------------------------------------------------------------------------------ > > Key: WFLY-6004 > URL: https://issues.jboss.org/browse/WFLY-6004 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.2.Final, 10.0.0.CR5 > Reporter: Ian MacIntyre > Assignee: Darran Lofthouse > Labels: remote-ejb-connection, roles > > We are using remote EJB calls and are finding role information being lost. > I have traced this to our use of JAAS authentication for the ApplicationRealm security realm > Within the handle() method of JaasCallbackHander it stores the current Security context at that point (via securityManager.push()) > It then calls securityManager.authenticate() which results in login modules being called. We use the ClientLoginModule which stores information on the SecurityContext via SecurityAssociationActions.setPrincipalInfo > After authentication the JaasCallbackHandler calls securityManager.pop() which resets the SecurityContext back its state before authentication - thus losing the context set in the ClientLoginModule. > This only occurs via a remote ejb call, not via a call made from the web tier (as it does not use JaasLoginHandler) > Ideally I'd like some way to stop the JaasCallbackHandler reseting the SecurityContext (even if it was incredibly simple by checking for an attribute on the current security context) > The same operations work in EAP 6.3 / JBoss 7.2 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6004) JAASCallbackHandler resets SecurityContext after authentication to it's pre-authentication value

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6004?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-6004: -------------------------------------- Assignee: Darran Lofthouse (was: Jason Greene) > JAASCallbackHandler resets SecurityContext after authentication to it's pre-authentication value > ------------------------------------------------------------------------------------------------ > > Key: WFLY-6004 > URL: https://issues.jboss.org/browse/WFLY-6004 > Project: WildFly > Issue Type: Bug > Affects Versions: 9.0.2.Final, 10.0.0.CR5 > Reporter: Ian MacIntyre > Assignee: Darran Lofthouse > Labels: remote-ejb-connection, roles > > We are using remote EJB calls and are finding role information being lost. > I have traced this to our use of JAAS authentication for the ApplicationRealm security realm > Within the handle() method of JaasCallbackHander it stores the current Security context at that point (via securityManager.push()) > It then calls securityManager.authenticate() which results in login modules being called. We use the ClientLoginModule which stores information on the SecurityContext via SecurityAssociationActions.setPrincipalInfo > After authentication the JaasCallbackHandler calls securityManager.pop() which resets the SecurityContext back its state before authentication - thus losing the context set in the ClientLoginModule. > This only occurs via a remote ejb call, not via a call made from the web tier (as it does not use JaasLoginHandler) > Ideally I'd like some way to stop the JaasCallbackHandler reseting the SecurityContext (even if it was incredibly simple by checking for an attribute on the current security context) > The same operations work in EAP 6.3 / JBoss 7.2 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6004) JAASCallbackHandler resets SecurityContext after authentication to it's pre-authentication value

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-6004?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated WFLY-6004: ----------------------------------- Component/s: Security > JAASCallbackHandler resets SecurityContext after authentication to it's pre-authentication value > ------------------------------------------------------------------------------------------------ > > Key: WFLY-6004 > URL: https://issues.jboss.org/browse/WFLY-6004 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 9.0.2.Final, 10.0.0.CR5 > Reporter: Ian MacIntyre > Assignee: Darran Lofthouse > Labels: remote-ejb-connection, roles > > We are using remote EJB calls and are finding role information being lost. > I have traced this to our use of JAAS authentication for the ApplicationRealm security realm > Within the handle() method of JaasCallbackHander it stores the current Security context at that point (via securityManager.push()) > It then calls securityManager.authenticate() which results in login modules being called. We use the ClientLoginModule which stores information on the SecurityContext via SecurityAssociationActions.setPrincipalInfo > After authentication the JaasCallbackHandler calls securityManager.pop() which resets the SecurityContext back its state before authentication - thus losing the context set in the ClientLoginModule. > This only occurs via a remote ejb call, not via a call made from the web tier (as it does not use JaasLoginHandler) > Ideally I'd like some way to stop the JaasCallbackHandler reseting the SecurityContext (even if it was incredibly simple by checking for an attribute on the current security context) > The same operations work in EAP 6.3 / JBoss 7.2 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1303) NPE in principal-to-group group searching

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1303?page=com.atlassian.jira.plugi... ] Ondrej Lukas updated WFCORE-1303: --------------------------------- Description: In case when ldap authorization with principal-to-group group searching is used in security realm and LDAP entry found by value of 'group-attribute' does not include attribute mentioned in 'group-name-attribute' then it causes authentication fail. It is caused by missing null check for groupNameAttr and hidden NPE thrown from [1]. [1] https://github.com/wildfly/wildfly-core/blob/bcc56983730d976ec77ede0d5901... was: In case when ldap authorization with principal-to-group group searching is used in security realm and LDAP entry found by value of 'group-attribute' does not include attribute mentioned in 'group-name-attribute' then it causes authentication fail. It is caused by missing null check for groupNameAttr and hidden NPE thrown from [1]. [1] https://github.com/jbossas/wildfly-core-eap/blob/a8aa0199b64957df65f70695... > NPE in principal-to-group group searching > ----------------------------------------- > > Key: WFCORE-1303 > URL: https://issues.jboss.org/browse/WFCORE-1303 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.7.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > In case when ldap authorization with principal-to-group group searching is used in security realm and LDAP entry found by value of 'group-attribute' does not include attribute mentioned in 'group-name-attribute' then it causes authentication fail. It is caused by missing null check for groupNameAttr and hidden NPE thrown from [1]. > [1] https://github.com/wildfly/wildfly-core/blob/bcc56983730d976ec77ede0d5901... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1303) NPE in principal-to-group group searching

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1303?page=com.atlassian.jira.plugi... ] Ondrej Lukas updated WFCORE-1303: --------------------------------- Affects Version/s: 2.0.7.Final > NPE in principal-to-group group searching > ----------------------------------------- > > Key: WFCORE-1303 > URL: https://issues.jboss.org/browse/WFCORE-1303 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Affects Versions: 2.0.7.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > In case when ldap authorization with principal-to-group group searching is used in security realm and LDAP entry found by value of 'group-attribute' does not include attribute mentioned in 'group-name-attribute' then it causes authentication fail. It is caused by missing null check for groupNameAttr and hidden NPE thrown from [1]. > [1] https://github.com/wildfly/wildfly-core/blob/bcc56983730d976ec77ede0d5901... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6005) NPE in principal-to-group group searching

by Ondrej Lukas (JIRA)

Ondrej Lukas created WFLY-6005: ---------------------------------- Summary: NPE in principal-to-group group searching Key: WFLY-6005 URL: https://issues.jboss.org/browse/WFLY-6005 Project: WildFly Issue Type: Bug Components: Domain Management, Security Reporter: Ondrej Lukas Assignee: Brian Stansberry In case when ldap authorization with principal-to-group group searching is used in security realm and LDAP entry found by value of 'group-attribute' does not include attribute mentioned in 'group-name-attribute' then it causes authentication fail. It is caused by missing null check for groupNameAttr and hidden NPE thrown from [1]. [1] https://github.com/jbossas/wildfly-core-eap/blob/a8aa0199b64957df65f70695... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1303) NPE in principal-to-group group searching

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1303?page=com.atlassian.jira.plugi... ] Ondrej Lukas moved WFLY-6005 to WFCORE-1303: -------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-1303 (was: WFLY-6005) Component/s: Domain Management Security (was: Domain Management) (was: Security) > NPE in principal-to-group group searching > ----------------------------------------- > > Key: WFCORE-1303 > URL: https://issues.jboss.org/browse/WFCORE-1303 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Security > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > In case when ldap authorization with principal-to-group group searching is used in security realm and LDAP entry found by value of 'group-attribute' does not include attribute mentioned in 'group-name-attribute' then it causes authentication fail. It is caused by missing null check for groupNameAttr and hidden NPE thrown from [1]. > [1] https://github.com/jbossas/wildfly-core-eap/blob/a8aa0199b64957df65f70695... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016