August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1504) Support Elytron specific callbacks with JASPIC ServerAuthenticationModules

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1504?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1504: ---------------------------------- Fix Version/s: 1.5.6.CR1 (was: 1.5.5.Final) > Support Elytron specific callbacks with JASPIC ServerAuthenticationModules > -------------------------------------------------------------------------- > > Key: ELY-1504 > URL: https://issues.jboss.org/browse/ELY-1504 > Project: WildFly Elytron > Issue Type: Feature Request > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.5.6.CR1 > > > JASPIC already supports the use of a CallbackHandler for communication between the ServerAuthenticationModule and the container the first stage of implementation is to support the callbacks mandated by the spec - this task is to follow up and add support for Elytron specific callbacks. > The reason to split this out is we may still want to handle our core lifecycle related callbacks so of the remaining callbacks we will need to decide which ones we want to support. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1475) Empty username for FormAuthenticationMechanism causes IllegalArgumentException

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1475: ---------------------------------- Fix Version/s: 1.5.6.CR1 (was: 1.5.5.Final) > Empty username for FormAuthenticationMechanism causes IllegalArgumentException > ------------------------------------------------------------------------------ > > Key: ELY-1475 > URL: https://issues.jboss.org/browse/ELY-1475 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.2.0.Beta11 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Fix For: 1.5.6.CR1 > > > In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username. > See exception: > {code} > ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException > at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90) > at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172) > at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106) > at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114) > at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115) > at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94) > at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78) > at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100) > 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 org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > 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:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > 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:326) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > {code} > It seems that [1] should also check {{username.length() == 0}}. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3eca... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1466) Add configuration option to BASIC mechanism to switch off challenging

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1466?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1466: ---------------------------------- Fix Version/s: 1.5.6.CR1 (was: 1.5.5.Final) > Add configuration option to BASIC mechanism to switch off challenging > --------------------------------------------------------------------- > > Key: ELY-1466 > URL: https://issues.jboss.org/browse/ELY-1466 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.5.6.CR1 > > > This may be desirable where paired with FORM auth so users can use FORM auth and other clients use BASIC. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1464) Programatic authentication should be caching the SecurityIdentity not the name of the identity

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1464?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1464: ---------------------------------- Fix Version/s: 1.5.6.CR1 (was: 1.5.5.Final) > Programatic authentication should be caching the SecurityIdentity not the name of the identity > ---------------------------------------------------------------------------------------------- > > Key: ELY-1464 > URL: https://issues.jboss.org/browse/ELY-1464 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.5.6.CR1 > > > By only caching the name of the identity the server authentication context -> security domain -> security realm chain is called for each subsequent request when we should have been able to re-use an existing identity. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1641) Release WildFly Elytron 1.5.5.Final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1641?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse resolved ELY-1641. ----------------------------------- Resolution: Done > Release WildFly Elytron 1.5.5.Final > ----------------------------------- > > Key: ELY-1641 > URL: https://issues.jboss.org/browse/ELY-1641 > Project: WildFly Elytron > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.5.5.CR1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2282) Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2282?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2282: -------------------------------- Hmm, can you reproduce this? When a message is encrypted, it is actually *copied*, and the copy is encrypted and sent, to prevent multiple encryption when a message is retransmitted. On the receiver side, in both NAKACK2 and UNICAST3, messages are decrypted and passed up, but *not* retransmitted, as this happens only on the sender side. I cannot see how a message or message batch would end up not having an encrypt header... > Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT > -------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2282 > URL: https://issues.jboss.org/browse/JGRP-2282 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.13 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.14 > > > There seems to be a regression (in 4.0?) in SYM_ENCRYPT and ASYM_ENCRYPT dropping messages around topology changes (and possibly bypassing retransmission?). QE tests using these protocols observe a lot of the following: > {code} > [JBossINF] [0m[31m04:45:10,048 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ejb,perf18) perf18: received message without encrypt header from perf21; dropping it > {code} > which is followed by numerous infinispan exceptions/timeouts, see WFLY-10464. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2282) Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2282?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2282: --------------------------- Fix Version/s: 4.0.14 > Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT > -------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2282 > URL: https://issues.jboss.org/browse/JGRP-2282 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.13 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > Fix For: 4.0.14 > > > There seems to be a regression (in 4.0?) in SYM_ENCRYPT and ASYM_ENCRYPT dropping messages around topology changes (and possibly bypassing retransmission?). QE tests using these protocols observe a lot of the following: > {code} > [JBossINF] [0m[31m04:45:10,048 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ejb,perf18) perf18: received message without encrypt header from perf21; dropping it > {code} > which is followed by numerous infinispan exceptions/timeouts, see WFLY-10464. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2282) Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2282?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated JGRP-2282: --------------------------------- Description: There seems to be a regression (in 4.0?) in SYM_ENCRYPT and ASYM_ENCRYPT dropping messages around topology changes (and possibly bypassing retransmission?). QE tests using these protocols observe a lot of the following: {code} [JBossINF] [0m[31m04:45:10,048 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ejb,perf18) perf18: received message without encrypt header from perf21; dropping it {code} which is followed by numerous infinispan exceptions/timeouts, see WFLY-10464. was: There seems to be a regression (in 4.0?) in SYM_ENCRYPT and ASYM_ENCRYPT dropping messages (and possibly bypassing retransmission?). QE tests using these protocols observe a lot of the following: {code} [JBossINF] [0m[31m04:45:10,048 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ejb,perf18) perf18: received message without encrypt header from perf21; dropping it {code} which is followed by numerous infinispan exceptions/timeouts, see WFLY-10464. > Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT > -------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2282 > URL: https://issues.jboss.org/browse/JGRP-2282 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.13 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > > There seems to be a regression (in 4.0?) in SYM_ENCRYPT and ASYM_ENCRYPT dropping messages around topology changes (and possibly bypassing retransmission?). QE tests using these protocols observe a lot of the following: > {code} > [JBossINF] [0m[31m04:45:10,048 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ejb,perf18) perf18: received message without encrypt header from perf21; dropping it > {code} > which is followed by numerous infinispan exceptions/timeouts, see WFLY-10464. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2282) Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-2282?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on JGRP-2282: -------------------------------------- My hunch would be processing batches, messages are replaced in a batch with unencrypted version and then retrasmitted unencrypted? Maybe org.jgroups.protocols.EncryptTest could be extended to test this. > Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT > -------------------------------------------------------------------------------------------------------------- > > Key: JGRP-2282 > URL: https://issues.jboss.org/browse/JGRP-2282 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.0.13 > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Critical > > There seems to be a regression (in 4.0?) in SYM_ENCRYPT and ASYM_ENCRYPT dropping messages (and possibly bypassing retransmission?). QE tests using these protocols observe a lot of the following: > {code} > [JBossINF] [0m[31m04:45:10,048 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ejb,perf18) perf18: received message without encrypt header from perf21; dropping it > {code} > which is followed by numerous infinispan exceptions/timeouts, see WFLY-10464. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2282) Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT

by Radoslav Husar (JIRA)

Radoslav Husar created JGRP-2282: ------------------------------------ Summary: Frequent "received message without encrypt header from Y; dropping it" with both ASYM_ENCRYPT and SYM_ENCRYPT Key: JGRP-2282 URL: https://issues.jboss.org/browse/JGRP-2282 Project: JGroups Issue Type: Bug Affects Versions: 4.0.13 Reporter: Radoslav Husar Assignee: Bela Ban Priority: Critical There seems to be a regression (in 4.0?) in SYM_ENCRYPT and ASYM_ENCRYPT dropping messages (and possibly bypassing retransmission?). QE tests using these protocols observe a lot of the following: {code} [JBossINF] [0m[31m04:45:10,048 ERROR [org.jgroups.protocols.ASYM_ENCRYPT] (thread-9,ejb,perf18) perf18: received message without encrypt header from perf21; dropping it {code} which is followed by numerous infinispan exceptions/timeouts, see WFLY-10464. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 August 2018