[JBoss JIRA] (SECURITY-895) LdapExtLoginModule throws FailedLoginException when rolesCtxDN and roleFilter attributes are not set
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/SECURITY-895?page=com.atlassian.jira.plug... ]
Ondrej Lukas moved JBEAP-327 to SECURITY-895:
---------------------------------------------
Project: PicketBox (was: JBoss Enterprise Application Platform)
Key: SECURITY-895 (was: JBEAP-327)
Workflow: classic default workflow (was: CDW v1)
Affects Version/s: PicketBox_4_9_0.Beta2
(was: EAP 7.0.0.DR1)
Component/s: PicketBox
(was: Security)
Target Release: (was: EAP 7.0.0.GA)
> LdapExtLoginModule throws FailedLoginException when rolesCtxDN and roleFilter attributes are not set
> ----------------------------------------------------------------------------------------------------
>
> Key: SECURITY-895
> URL: https://issues.jboss.org/browse/SECURITY-895
> Project: PicketBox
> Issue Type: Bug
> Components: PicketBox
> Affects Versions: PicketBox_4_9_0.Beta2
> Reporter: Ondrej Lukas
> Assignee: Peter Skopek
> Priority: Minor
> Labels: eap-qe-pool-security
>
> In case when LdapExtLoginModule is correctly configured for authentication, but its attributes rolesCtxDN and roleFilter are not set, then authentication with correct username and password leads to FailedLoginException.
> Expected behavior is that user should be authenticated but no roles should be assigned to them.
> Possible EAP configuration:
> <security-domain name="ldap">
> <authentication>
> <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required">
> <module-option name="baseFilter" value="(uid={0})"/>
> <module-option name="bindDN" value="uid=admin,ou=system"/>
> <module-option name="baseCtxDN" value="ou=People,o=MyOrg,o=primary,dc=jboss,dc=org"/>
> <module-option name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
> <module-option name="java.naming.security.authentication" value="simple"/>
> <module-option name="java.naming.provider.url" value="ldap://localhost:10389"/>
> <module-option name="bindCredential" value="secret"/>
> </login-module>
> </authentication>
> </security-domain>
> In case when these attributes are added
> <module-option name="rolesCtxDN" value="ou=Roles,o=MyOrg,o=primary,dc=jboss,dc=org"/>
> <module-option name="roleFilter" value="(member={0})"/>
> then user is correctly authenticated (even in case when no role is assigned to them).
> It is caused by internal NPE thrown from method rolesSearch in LdapExtLoginModule class on line:
> results = ldapCtx.search(rolesCtxDN, roleFilter, filterArgs, constraints);
> DEBUG [org.jboss.security] (default task-2) PBOX000206: Login failure: javax.security.auth.login.FailedLoginException: PBOX000070: Password invalid/Password required
> at org.jboss.security.auth.spi.UsernamePasswordLoginModule.login(UsernamePasswordLoginModule.java:284)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:762)
> at javax.security.auth.login.LoginContext.access$000(LoginContext.java:203)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:690)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:688)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:687)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:595)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:411)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:350)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:338)
> at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:148)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verifyCredential(JAASIdentityManagerImpl.java:111)
> at org.wildfly.extension.undertow.security.JAASIdentityManagerImpl.verify(JAASIdentityManagerImpl.java:82)
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:118)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:339)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:356)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:325)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:138)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:113)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:106)
> 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:51)
> 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:56)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 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:274)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JGRP-1931) Don't drop UNICAST3 message when the window is not created
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1931?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on JGRP-1931:
-----------------------------------
The idea is that once the message is really received, we shouldn't just throw that away.
{quote}
This is needed to know the lowest seqno of the sender.
{quote}
Can't be the table in a state when it would store the received messages but the lowest seqno is not required yet? (I was not checking the code how complicated this would be).
It's not a critical issue - the tests expected the RPC to be propagated in 200 ms, so I have rewritten them to the assertEventually-style (with polling for long timeout).
> Don't drop UNICAST3 message when the window is not created
> -----------------------------------------------------------
>
> Key: JGRP-1931
> URL: https://issues.jboss.org/browse/JGRP-1931
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.3
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.4
>
>
> When an application sends first two (or more) messages in parallel and the the second one is marked as DONT_BUNDLE, usually this one arrives as the first one and is dropped (see https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...). After first message arrives, the connection is properly set up, but we need to wait until retransmission for the message (and other non-OOB) messages to be delivered.
> In practice this behaviour should be acceptable, but it causes failures in some time-sensitive tests (particularly in Hibernate ORM 2nd level cache).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-4789) Cannot remove property from client configuration
by Katerina Novotna (JIRA)
[ https://issues.jboss.org/browse/WFLY-4789?page=com.atlassian.jira.plugin.... ]
Katerina Novotna reassigned WFLY-4789:
--------------------------------------
Assignee: Katerina Novotna (was: Stuart Douglas)
> Cannot remove property from client configuration
> ------------------------------------------------
>
> Key: WFLY-4789
> URL: https://issues.jboss.org/browse/WFLY-4789
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Reporter: Katerina Novotna
> Assignee: Katerina Novotna
>
> The javadoc [1] for javax.ws.rs.core Configurable interface says that:
> "An existing property can be removed by assigning a null value to the property. "
> By client.property(some_property, null) this is not possible.
> ResteasyProviderFactory.property() method only adds the properties, but has no way to remove it if the value of the property is null.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-4789) Cannot remove property from client configuration
by Katerina Novotna (JIRA)
Katerina Novotna created WFLY-4789:
--------------------------------------
Summary: Cannot remove property from client configuration
Key: WFLY-4789
URL: https://issues.jboss.org/browse/WFLY-4789
Project: WildFly
Issue Type: Bug
Components: REST
Reporter: Katerina Novotna
Assignee: Stuart Douglas
The javadoc [1] for javax.ws.rs.core Configurable interface says that:
"An existing property can be removed by assigning a null value to the property. "
By client.property(some_property, null) this is not possible.
ResteasyProviderFactory.property() method only adds the properties, but has no way to remove it if the value of the property is null.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (JGRP-1931) Don't drop UNICAST3 message when the window is not created
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1931?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1931 at 6/16/15 8:35 AM:
---------------------------------------------------------
What's the use case here ? The {{DONT_BUNDLE}} flag should be used sparingly and is actually ignored unless coupled with {{OOB}}. Note that only a few internal JGroups messages use {{DONT_BUNDLE, OOB}}.
OK, this can still hapen if you send a _regular_ and an _OOB_ message as first messages to a new member, or a member which closed its connection to us.
Retransmission of the dropped message should be quick; by default the retransmission interval in {{UNICAST3}} ({{xmit_interval}}) is 500 ms.
was (Author: belaban):
What's the use case here ? The {{DONT_BUNDLE}} flag should be used sparingly and is actually ignored unless coupled with {{OOB}}. Note that only a few internal JGroups messages use {{DONT_BUNDLE, OOB}}.
> Don't drop UNICAST3 message when the window is not created
> -----------------------------------------------------------
>
> Key: JGRP-1931
> URL: https://issues.jboss.org/browse/JGRP-1931
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.3
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.6.4
>
>
> When an application sends first two (or more) messages in parallel and the the second one is marked as DONT_BUNDLE, usually this one arrives as the first one and is dropped (see https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...). After first message arrives, the connection is properly set up, but we need to wait until retransmission for the message (and other non-OOB) messages to be delivered.
> In practice this behaviour should be acceptable, but it causes failures in some time-sensitive tests (particularly in Hibernate ORM 2nd level cache).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months
[JBoss JIRA] (WFLY-4788) Upgrade HAL to 2.7.2.Final
by Harald Pehl (JIRA)
Harald Pehl created WFLY-4788:
---------------------------------
Summary: Upgrade HAL to 2.7.2.Final
Key: WFLY-4788
URL: https://issues.jboss.org/browse/WFLY-4788
Project: WildFly
Issue Type: Component Upgrade
Components: Web Console
Reporter: Harald Pehl
Assignee: Harald Pehl
Fix For: 9.0.0.CR2
HAL 2.7.1 contains a critical bugfix for HAL-617.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 10 months