October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7415) Add backup service support for singleton services

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7415: ---------------------------------- Summary: Add backup service support for singleton services Key: WFLY-7415 URL: https://issues.jboss.org/browse/WFLY-7415 Project: WildFly Issue Type: Feature Request Components: Clustering Affects Versions: 10.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 Currently, singleton services are started on the primary node only - no service is started on the backup nodes. We can generalize this use case by building a singleton service using 2 services: one to be started on the primary node, and the other to be installed on backup nodes. When a node is elected as the primary provider, we stop the backup service, and start the primary service. Conversely, when a primary node loses a re-election, it stops its primary service and starts its backup service. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-700) Fix AuthenticationClient comparison behavior

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-700?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-700: --------------------------------- Other helpful things: equal/hashCode-stable suppliers/functions/etc. > Fix AuthenticationClient comparison behavior > -------------------------------------------- > > Key: ELY-700 > URL: https://issues.jboss.org/browse/ELY-700 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > > The authentication client's comparison behavior is more or less banjaxed. It needs to be fixed, starting probably with killing off multi-valued configuration items. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-700) Fix AuthenticationClient comparison behavior

by David Lloyd (JIRA)

David Lloyd created ELY-700: ------------------------------- Summary: Fix AuthenticationClient comparison behavior Key: ELY-700 URL: https://issues.jboss.org/browse/ELY-700 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client Reporter: David Lloyd Assignee: David Lloyd The authentication client's comparison behavior is more or less banjaxed. It needs to be fixed, starting probably with killing off multi-valued configuration items. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7413) Singleton policy quorum attribute is missing a validator

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7413: ---------------------------------- Summary: Singleton policy quorum attribute is missing a validator Key: WFLY-7413 URL: https://issues.jboss.org/browse/WFLY-7413 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7414) Singleton policy quorum attribute is missing a validator

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7414: ---------------------------------- Summary: Singleton policy quorum attribute is missing a validator Key: WFLY-7414 URL: https://issues.jboss.org/browse/WFLY-7414 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.1.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 11.0.0.Alpha1 -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-698) Rework the constructor exclusion logic for authentication rules and configurations

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-698?page=com.atlassian.jira.plugin.sy... ] David Lloyd reassigned ELY-698: ------------------------------- Assignee: David Lloyd > Rework the constructor exclusion logic for authentication rules and configurations > ---------------------------------------------------------------------------------- > > Key: ELY-698 > URL: https://issues.jboss.org/browse/ELY-698 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Minor > > The current authentication rule and configuration classes are designed to ensure that mutually incompatible rules and configurations cannot coexist. However the implementation is applied a bit erratically. There may be problems with commutatively applying checks. Some checks may be missing or extraneous. > We need a new approach where the mutual exclusion set is somehow enforced centrally. One option is to have literal sets, and each class that is a member of one or more sets must remove all other handlers that are also within the set(s). A predicate could be used to make this efficient by only sweeping the list one time, in contrast to the current mechanism which sweeps the list once per exclusive type. > Another option is to have a marker interface for each capability, and to remove all peers with the same capability. A predicate can also be used in this case. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-699) Client authentication should default to using the URI userInfo if present

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-699?page=com.atlassian.jira.plugin.sy... ] David Lloyd reassigned ELY-699: ------------------------------- Assignee: David Lloyd > Client authentication should default to using the URI userInfo if present > ------------------------------------------------------------------------- > > Key: ELY-699 > URL: https://issues.jboss.org/browse/ELY-699 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > > The client should be using the userInfo from the connection URI in preference to anonymous authentication if that information is present. The challenge is that the API does not presently require a URI to be given when getting the authentication principal. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-930) A security-domain can only load login-modules from a single JBoss module

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plug... ] Stefan Guilhen resolved SECURITY-930. ------------------------------------- Fix Version/s: PicketBox_5_0_0.Beta1 Resolution: Done The PicketBox side has been fixed. WildFly has been updated to use the latest PicketBox release that includes the fix and we need to change the WildFly side to use the new API that allows for the specification of multiple modules. I've cloned this into WFLY-7412 to track the WildFly side of the issue. > A security-domain can only load login-modules from a single JBoss module > -------------------------------------------------------------------------- > > Key: SECURITY-930 > URL: https://issues.jboss.org/browse/SECURITY-930 > Project: PicketBox > Issue Type: Bug > Components: JBossSX, Security-SPI > Reporter: Derek Horton > Assignee: Stefan Guilhen > Fix For: PicketBox_5_0_0.Beta1 > > > A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates. > For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module: > <security-domain name="jmx-console" cache-type="default"> > <authentication> > <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required"> > <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> > <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> > </login-module> > <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required"> > <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> > <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> > </login-module> > </authentication> > </security-domain> > Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules. > There seems to be two issues. 1) The security subsystem code only "remembers" the last module that is defined within a single security domain. 2) I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code. The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7412) A security-domain can only load login-modules from a single JBoss module

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFLY-7412?page=com.atlassian.jira.plugin.... ] Stefan Guilhen moved SECURITY-961 to WFLY-7412: ----------------------------------------------- Project: WildFly (was: PicketBox ) Key: WFLY-7412 (was: SECURITY-961) Workflow: GIT Pull Request workflow (was: classic default workflow) Component/s: Security (was: JBossSX, Security-SPI) > A security-domain can only load login-modules from a single JBoss module > -------------------------------------------------------------------------- > > Key: WFLY-7412 > URL: https://issues.jboss.org/browse/WFLY-7412 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Derek Horton > Assignee: Stefan Guilhen > > A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates. > For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module: > <security-domain name="jmx-console" cache-type="default"> > <authentication> > <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required"> > <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> > <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> > </login-module> > <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required"> > <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> > <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> > </login-module> > </authentication> > </security-domain> > Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules. > There seems to be two issues. 1) The security subsystem code only "remembers" the last module that is defined within a single security domain. 2) I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code. The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7412) A security-domain can only load login-modules from a single JBoss module

by Stefan Guilhen (JIRA)

[ https://issues.jboss.org/browse/WFLY-7412?page=com.atlassian.jira.plugin.... ] Stefan Guilhen updated WFLY-7412: --------------------------------- Description: A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates. For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module: <security-domain name="jmx-console" cache-type="default"> <authentication> <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required"> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> </login-module> <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required"> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> </login-module> </authentication> </security-domain> Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules. was: A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates. For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module: <security-domain name="jmx-console" cache-type="default"> <authentication> <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required"> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> </login-module> <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required"> <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> </login-module> </authentication> </security-domain> Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules. There seems to be two issues. 1) The security subsystem code only "remembers" the last module that is defined within a single security domain. 2) I think issue #1 is happening because the JBoss authentication code (org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate()) defers to the JVM's login module handling code. The JVM appears to treat the login modules as one atomic until and so a single classloader is set and then the JVM login module code is invoked to handle the authentication requests. > A security-domain can only load login-modules from a single JBoss module > -------------------------------------------------------------------------- > > Key: WFLY-7412 > URL: https://issues.jboss.org/browse/WFLY-7412 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Derek Horton > Assignee: Stefan Guilhen > > A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates. > For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module: > <security-domain name="jmx-console" cache-type="default"> > <authentication> > <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required"> > <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> > <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> > </login-module> > <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required"> > <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> > <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> > </login-module> > </authentication> > </security-domain> > Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 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 October 2016