October 2016 - jboss-jira - Jboss List Archives

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

by Stefan Guilhen (JIRA)

Stefan Guilhen created SECURITY-961: --------------------------------------- Summary: A security-domain can only load login-modules from a single JBoss module Key: SECURITY-961 URL: https://issues.jboss.org/browse/SECURITY-961 Project: PicketBox Issue Type: Bug Components: JBossSX, Security-SPI 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] (REMJMX-120) Enable All Security Tests Backed By Elytron

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-120: --------------------------------------- Summary: Enable All Security Tests Backed By Elytron Key: REMJMX-120 URL: https://issues.jboss.org/browse/REMJMX-120 Project: Remoting JMX Issue Type: Enhancement Components: Security, Tests Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha3 By enabling the tests I mean get them all working ;-) We most likely need a wildfly-client-config.xml for default settings, also tests should be updated to cover both direct JMXConnector use and cases where AuthenticationConfiguration can be set before. Some clients such as jconsole will not be calling AuthenticationConfiguration first. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-120) Enable All Security Tests Backed By Elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-120?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated REMJMX-120: ------------------------------------ Priority: Blocker (was: Major) > Enable All Security Tests Backed By Elytron > ------------------------------------------- > > Key: REMJMX-120 > URL: https://issues.jboss.org/browse/REMJMX-120 > Project: Remoting JMX > Issue Type: Enhancement > Components: Security, Tests > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Alpha3 > > > By enabling the tests I mean get them all working ;-) > We most likely need a wildfly-client-config.xml for default settings, also tests should be updated to cover both direct JMXConnector use and cases where AuthenticationConfiguration can be set before. > Some clients such as jconsole will not be calling AuthenticationConfiguration first. -- 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 commented on ELY-699: --------------------------------- Rather than changing the API to require a URI to be given to org.wildfly.security.auth.client.AuthenticationConfiguration#getPrincipal, which would be fairly complex, a better approach might be to modify org.wildfly.security.auth.client.AuthenticationContextConfigurationClient#getAuthenticationConfiguration() to automatically add information from the URI in to the configuration before returning it, like this: * If auth is anonymous, check for userInfo; if present, add it as a setName * If no SetHost*Configuration is set, add the URI host (if any) as setHost * Same for port # Then we can add methods on AuthenticationContextConfigurationClient which do not require a URI to be given, and deprecate those old ones. > 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 > > 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] (ELY-699) Client authentication should default to using the URI userInfo if present

by David Lloyd (JIRA)

David Lloyd created ELY-699: ------------------------------- Summary: 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 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] (REMJMX-119) Where a username and credential are supplied accept the default realm

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-119: --------------------------------------- Summary: Where a username and credential are supplied accept the default realm Key: REMJMX-119 URL: https://issues.jboss.org/browse/REMJMX-119 Project: Remoting JMX Issue Type: Enhancement Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha3 -- 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 commented on ELY-698: --------------------------------- The present requirements for an AuthenticationConfiguration are: * Ordering is insignificant for non-overlapping configurations. For example, if A then B are added into a configuration, and A and B do not logically overlap, the result will be identical to adding B then A. * Equals/hashCode must respect the ordering rule. In the previous example, both configurations must have the same hash code and be equal to one another. * In order to meet this rule, two logically overlapping configurations may not coexist on a configuration. For example, two different configurations that both logically establish a cleartext password will be exclusive, such that whichever one is added last is retained and the other one is dropped. I suppose these rules really should be on the JavaDoc. > 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 > 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] (WFLY-7410) CommandDispatcher.submitOnCluster() futures throw NPEs

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7410?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-7410: ------------------------------- Description: Calling Future.get() on a response from CommandDispatcher.submitOnCluster(...) will always throw an NPE. We also need to handle the case where the response from a node was filtered. > CommandDispatcher.submitOnCluster() futures throw NPEs > ------------------------------------------------------ > > Key: WFLY-7410 > URL: https://issues.jboss.org/browse/WFLY-7410 > 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 > > > Calling Future.get() on a response from CommandDispatcher.submitOnCluster(...) will always throw an NPE. > We also need to handle the case where the response from a node was filtered. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7411) CommandDispatcher.submitOnCluster() futures throw NPEs

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-7411: ---------------------------------- Summary: CommandDispatcher.submitOnCluster() futures throw NPEs Key: WFLY-7411 URL: https://issues.jboss.org/browse/WFLY-7411 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 Calling Future.get() on a response from CommandDispatcher.submitOnCluster(...) will always throw an NPE. We also need to handle the case where the response from a node was filtered. -- This message was sent by Atlassian JIRA (v7.2.2#72004)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7410) CommandDispatcher.submitOnCluster() futures throw NPEs

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-7410?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-7410: ------------------------------- Summary: CommandDispatcher.submitOnCluster() futures throw NPEs (was: CommandDispatcher.submitOnCluster() futures can throw NPEs) > CommandDispatcher.submitOnCluster() futures throw NPEs > ------------------------------------------------------ > > Key: WFLY-7410 > URL: https://issues.jboss.org/browse/WFLY-7410 > 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

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