[JBoss JIRA] (WFLY-7295) Wrong HTTP error code for Elytron authentication when LDAP server is unreachable
by Zach Rhoads (JIRA)
[ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.... ]
Zach Rhoads resolved WFLY-7295.
-------------------------------
Resolution: Done
> Wrong HTTP error code for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------
>
> Key: WFLY-7295
> URL: https://issues.jboss.org/browse/WFLY-7295
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Zach Rhoads
> Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> ... 45 more
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> ... 67 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7295) Wrong HTTP error code for Elytron authentication when LDAP server is unreachable
by Zach Rhoads (JIRA)
[ https://issues.jboss.org/browse/WFLY-7295?page=com.atlassian.jira.plugin.... ]
Zach Rhoads commented on WFLY-7295:
-----------------------------------
Added note in docs:
https://docs.jboss.org/author/display/WFLY/Elytron+Examples#ElytronExampl...
> Wrong HTTP error code for Elytron authentication when LDAP server is unreachable
> --------------------------------------------------------------------------------
>
> Key: WFLY-7295
> URL: https://issues.jboss.org/browse/WFLY-7295
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Zach Rhoads
> Priority: Critical
>
> In case when application uses authentication through Elytron ldap-realm and used LDAP server is unreachable then Internal server error (status code 500) is returned during authentication to the client.
> Exception in server log:
> {code}
> ERROR [io.undertow.request] (default task-10) UT005023: Exception handling request to /print-roles/protected/printRoles: java.lang.RuntimeException: ELY01078: Ldap-backed realm failed to obtain identity "jduke" from server
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:564)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:545)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.verifyEvidence(LdapSecurityRealm.java:513)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.verifyEvidence(ServerAuthenticationContext.java:1634)
> at org.wildfly.security.auth.server.ServerAuthenticationContext.verifyEvidence(ServerAuthenticationContext.java:654)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:818)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:752)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:850)
> at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:703)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$SecurityIdentityCallbackHandler.handle(SecurityIdentityServerMechanismFactory.java:113)
> at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:69)
> at org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(BasicAuthenticationMechanism.java:151)
> at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:115)
> at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:106)
> at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:90)
> at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:74)
> at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:82)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:207)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:810)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.naming.CommunicationException: 127.0.0.1:10389 [Root exception is java.net.ConnectException: Connection refused]
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:216)
> at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:137)
> at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1613)
> at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2746)
> at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
> at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
> at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
> at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
> at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114)
> at org.jboss.as.naming.InitialContext.init(InitialContext.java:99)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:89)
> at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)
> at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
> at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)
> at javax.naming.InitialContext.init(InitialContext.java:244)
> at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:286)
> at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:222)
> at org.wildfly.extension.elytron.DirContextDefinition.lambda$null$0(DirContextDefinition.java:148)
> at org.wildfly.extension.elytron.LdapRealmDefinition$RealmAddHandler.lambda$configureDirContext$0(LdapRealmDefinition.java:393)
> at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.getIdentity(LdapSecurityRealm.java:562)
> ... 45 more
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.sun.jndi.ldap.Connection.createSocket(Connection.java:350)
> at com.sun.jndi.ldap.Connection.<init>(Connection.java:203)
> ... 67 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[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 commented on SECURITY-930:
-----------------------------------------
[~ppalaga] Yeah, those two, in that order. The first one was ok if the PB upgrade and the WF changes were both done at the same time. As it turned out, this was not possible, so we had to update PicketBox first and then update WildFly to use the new API to register multiple modules. So I had to rework the commit to make sure the ClassLoaderLocator API was still compatible with the WF implementation.
I think backporting this should be perfectly possible. This is the WF commit that would need to be backported to EAP after PicketBox is updated: https://github.com/wildfly/wildfly/pull/9323/commits/88fbeb68a05da36362a4...
> 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.3#72005)
9 years, 5 months
[JBoss JIRA] (SECURITY-930) A security-domain can only load login-modules from a single JBoss module
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/SECURITY-930?page=com.atlassian.jira.plug... ]
Peter Palaga commented on SECURITY-930:
---------------------------------------
bq. The fix was applied a while ago to PicketBox master...
[~sguilhen], you mean this commit https://github.com/picketbox/picketbox/commit/66ca69979bd763662773944f549... and perhaps also this followup https://github.com/picketbox/picketbox/commit/548af1fe11909ceccb32909a408... ? I am asking to get an idea if backporting to EAP 6.4 is possible.
> 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.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7778) Remoting identity propagation does not work with Elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7778?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7778:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Remoting identity propagation does not work with Elytron
> --------------------------------------------------------
>
> Key: WFLY-7778
> URL: https://issues.jboss.org/browse/WFLY-7778
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Critical
>
> Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
> Identity is unauthorized on server side.
> *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference.
> Often error message:
> {code:java}
> SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: Server rejected authentication
> DIGEST-MD5: Server rejected authentication]
> at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7778) Remoting identity propagation does not work with Elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7778?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7778:
-----------------------------
Description:
Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
Identity is unauthorized on server side.
*Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference.
Often error message:
{code:java}
SaslException: Authentication failed: all available authentication mechanisms failed:
JBOSS-LOCAL-USER: Server rejected authentication
DIGEST-MD5: Server rejected authentication]
at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
{code}
was:
Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
Identity is unauthorized on server side.
*Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference.
Often error message:
{code:java}
SaslException: Authentication failed: all available authentication mechanisms failed:
JBOSS-LOCAL-USER: Server rejected authentication
DIGEST-MD5: Server rejected authentication]
{code}
> Remoting identity propagation does not work with Elytron
> --------------------------------------------------------
>
> Key: WFLY-7778
> URL: https://issues.jboss.org/browse/WFLY-7778
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
> Identity is unauthorized on server side.
> *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference.
> Often error message:
> {code:java}
> SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: Server rejected authentication
> DIGEST-MD5: Server rejected authentication]
> at org.wildfly.naming.client.remote.RemoteNamingProvider.getPeerIdentityForNaming(RemoteNamingProvider.java:110)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7778) Remoting identity propagation does not work with Elytron
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7778?page=com.atlassian.jira.plugin.... ]
Jan Kalina updated WFLY-7778:
-----------------------------
Description:
Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
Identity is unauthorized on server side.
*Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference.
Often error message:
{code:java}
SaslException: Authentication failed: all available authentication mechanisms failed:
JBOSS-LOCAL-USER: Server rejected authentication
DIGEST-MD5: Server rejected authentication]
{code}
was:
Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
Identity is unauthorized on server side.
Remoting does not work because it is not implemented - this issue created primary for tests ignore issue reference.
> Remoting identity propagation does not work with Elytron
> --------------------------------------------------------
>
> Key: WFLY-7778
> URL: https://issues.jboss.org/browse/WFLY-7778
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Kalina
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Even througth succesful obtaining LoginContext, identity is not propagated in EJB call.
> Identity is unauthorized on server side.
> *Remoting does not work because it is not implemented yet* - this issue created primary for tests ignore issue reference.
> Often error message:
> {code:java}
> SaslException: Authentication failed: all available authentication mechanisms failed:
> JBOSS-LOCAL-USER: Server rejected authentication
> DIGEST-MD5: Server rejected authentication]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2146) UDP: multiple unicast and multicast receiver threads
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2146?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2146.
----------------------------
Resolution: Done
> UDP: multiple unicast and multicast receiver threads
> ----------------------------------------------------
>
> Key: JGRP-2146
> URL: https://issues.jboss.org/browse/JGRP-2146
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> By default UDP has one thread which reads from the DatagramSocket for unicast datagram packets and another one for reading packets from the MulticastSocket.
> Because each thread deserializes the received packet into a {{Message}} or {{MessageBatch}}, if a lot of packets are received, this may slow things down.
> The new attributes {{ucast_receiver_threads}} (default:1) and {{mcast_receiver_threads}} (default:1) in UDP can create multiple unicast- or multicast- receiver threads. Note that all threads of the same type compete for the lock on the DatagramSocket or MulticastSocket respectively, so setting these attributes to high values is probably detrimental as context switching will increase.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months