March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-2497: ------------------------------------------ Due to other commitments this is going to be postponed to 4 anyway so hopefully we can consider both at the same time. > Convert *-authentication-factory resources to be child resources of security-domain > ----------------------------------------------------------------------------------- > > Key: WFCORE-2497 > URL: https://issues.jboss.org/browse/WFCORE-2497 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > This is a good example of where child resources work. > The authentication factory resources have a mandatory dependency on a single security domain. > The configuration within the factory is related to it's security domain. > There is only a single resource that can provide security domains. > The behaviour of the parent is unaffected by the existence or configuration of the child. > The parent and child manage their own services independently with the child's service depending on the parent's service. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2497) Convert *-authentication-factory resources to be child resources of security-domain

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2497: ------------------------------------- Fix Version/s: 4.0.0.Alpha1 (was: 3.0.0.Beta12) > Convert *-authentication-factory resources to be child resources of security-domain > ----------------------------------------------------------------------------------- > > Key: WFCORE-2497 > URL: https://issues.jboss.org/browse/WFCORE-2497 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 4.0.0.Alpha1 > > > This is a good example of where child resources work. > The authentication factory resources have a mandatory dependency on a single security domain. > The configuration within the factory is related to it's security domain. > There is only a single resource that can provide security domains. > The behaviour of the parent is unaffected by the existence or configuration of the child. > The parent and child manage their own services independently with the child's service depending on the parent's service. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code

by István Tóth (JIRA)

[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ] István Tóth commented on WFLY-8431: ----------------------------------- I have attached a test case for the getFactory race. 1. Build the attached servlet into into a war (no config needed) 2. Deploy to a wildfly instance 3. restart wildfly instance 4. Access the servlet All displayed objects should be the same, but they are not. The bug only triggers on the first access, and sometimes takes a few restarts to trigger. > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: István Tóth > Assignee: Darran Lofthouse > Attachments: GetFactoryTestCase.java > > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code

by István Tóth (JIRA)

[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ] István Tóth updated WFLY-8431: ------------------------------ Attachment: GetFactoryTestCase.java > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: István Tóth > Assignee: Darran Lofthouse > Attachments: GetFactoryTestCase.java > > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1898) Ability to store HttpSession in a external store

by Eric B (JIRA)

[ https://issues.jboss.org/browse/WFLY-1898?page=com.atlassian.jira.plugin.... ] Eric B commented on WFLY-1898: ------------------------------ [~swd847] Do you have an example of a custom SessionManager that I could look at? I'm trying to figure out how to setup/configure/use Redis as my persistence mechanism for sessions, but can't quite figure out how to create a SessionManager that would user Redis. Any help, examples would be appreciated. > Ability to store HttpSession in a external store > ------------------------------------------------ > > Key: WFLY-1898 > URL: https://issues.jboss.org/browse/WFLY-1898 > Project: WildFly > Issue Type: Feature Request > Components: Web (Undertow) > Reporter: Adrian Mitev > Assignee: Stuart Douglas > > I would like to keep the http session in an external store like Redis. There is a post how to configure that with older JBoss AS versions - https://community.jboss.org/wiki/HAWebSessionsViaDatabasePersistence -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1560) Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1560?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1560: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Cli calls leak resources in Host Controller when repeatedly calling jboss-cli.sh > -------------------------------------------------------------------------------- > > Key: WFCORE-1560 > URL: https://issues.jboss.org/browse/WFCORE-1560 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.8.Final > Environment: OS: CentOS 7.2 > Java HotSpot(TM) 64-Bit Server VM (build 25.77-b03, mixed mode) > Wildfly-10.0.0-Final > Reporter: Michael Noack > Assignee: Ken Wills > Priority: Critical > Fix For: 3.0.0.Beta12 > > Attachments: JVM-DC.png, console-dc.log, host-controller.log, process-controller.log > > > When executing management commands using jboss-cli.sh against the domain controller of a cluster repeatedly the host controller uses up more and more memory in oldgen. After several thousands of runs of jboss-cli the host controller eventually becomes unresponsive (see attached picture for memory consumption, dc became entirely unresponsive at roughly 6:30am): > [root@dc broken]# /opt/wildfly-10.0.0.Final-DC/bin/./jboss-cli.sh --connect --user="username" --password="password" --command=":read-children-names(child-type=host)" > Failed to connect to the controller: The controller is not available at xx.xx.xx.xx:9993: java.net.ConnectException: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out: WFLYPRT0023: Could not connect to https-remoting://xx.xx.xx.xx:9993. The connection timed out > I discovered the issue when testing whether https://issues.jboss.org/browse/WFCORE-974 was actually resolved in wildfly-10.0.0.Final as advertised. I can confirm that the issue is different, since no OOM-Exceptions are thrown. However the DC still becomes useless, since it won't accept any connections anymore. -I will check whether the work-around from WFCORE-974 applies to this issue as well.- However the work-around from WFCORE-974 doesn't fix this issue. > Please note that the attached logs are UTC, while the monitoring is UTC+2. Also the collection values are misleading since I haven't adapted my monitoring to the new output of jstat in JDK8. PU and PC are thus MU and MC. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1059) RestartParentResourceAdd/RemoveHandler should handle capability registration

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1059?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1059: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > RestartParentResourceAdd/RemoveHandler should handle capability registration > ---------------------------------------------------------------------------- > > Key: WFCORE-1059 > URL: https://issues.jboss.org/browse/WFCORE-1059 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.CR6 > Reporter: Paul Ferraro > Assignee: Tomaz Cerar > Fix For: 3.0.0.Beta12 > > > RestartParentResourceAddHandler and RestartParentResourceRemoveHandler do not extend the respective AbstractAddStepHandler and AbstractRemoveStepHandler base classes, and thus does not handle capability [un]registration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1282: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta12 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1145) Review of HostController / Application Server Remoting connections

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1145?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1145: ------------------------------------- Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Review of HostController / Application Server Remoting connections > ------------------------------------------------------------------ > > Key: WFCORE-1145 > URL: https://issues.jboss.org/browse/WFCORE-1145 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron, domain-mode > Fix For: 3.0.0.Beta12 > > > Where an application server connects back to it's host controller in domain mode it used the same Remoting connector exposed possibly for native domain management access. > The problem with this is that as soon as any security restrictions are placed on the connector exposed by the host controller then the application servers require something to work with this - this is even though we are only ever talking about loopback communication between two process on the same machine. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-396: ------------------------------------ Fix Version/s: 3.0.0.Beta12 (was: 3.0.0.Beta11) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta12 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 March 2017