[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)
7 years, 6 months
[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)
7 years, 6 months
[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)
7 years, 6 months
[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)
7 years, 6 months
[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)
7 years, 6 months
[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)
7 years, 6 months
[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)
7 years, 6 months
[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)
7 years, 6 months