September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-816) Support for masked passwords in client XML config

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-816?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-816: --------------------------------- Fix Version/s: 1.7.0.CR3 (was: 1.7.0.CR2) > Support for masked passwords in client XML config > ------------------------------------------------- > > Key: ELY-816 > URL: https://issues.jboss.org/browse/ELY-816 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.7.0.CR3 > > > We need a way to support masked passwords in the auth configuration file, either as: > * A dedicated masked-password-type XML type > * Adding necessary fields to hashed-password-type > * Adding a modular crypt format > Needs to be supported anywhere passwords are allowed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-533?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-533: --------------------------------- Fix Version/s: 1.7.0.CR3 (was: 1.7.0.CR2) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.jboss.org/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.7.0.CR3 > > > In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-243) Ensure reference to repository is removed from pom

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-243?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-243: --------------------------------- Fix Version/s: 1.7.0.CR3 (was: 1.7.0.CR2) > Ensure reference to repository is removed from pom > -------------------------------------------------- > > Key: ELY-243 > URL: https://issues.jboss.org/browse/ELY-243 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Fix For: 1.7.0.CR3 > > > We need to ensure the reference to the JBoss repo is removed from the pom and artefacts are available from Maven Central. > Also at this point probably good to put the steps in place for Elytron to also be available from Maven Central. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1655) Provide Java 9 Implementation avoiding sun.reflect and sun.misc classes

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1655?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1655: ---------------------------------- Fix Version/s: 1.7.0.CR3 (was: 1.7.0.CR2) > Provide Java 9 Implementation avoiding sun.reflect and sun.misc classes > ----------------------------------------------------------------------- > > Key: ELY-1655 > URL: https://issues.jboss.org/browse/ELY-1655 > Project: WildFly Elytron > Issue Type: Task > Components: Security Manager > Reporter: Darran Lofthouse > Assignee: Justin Cook > Fix For: 1.7.0.CR3 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1653) JDK 11 Support

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1653?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1653: ---------------------------------- Fix Version/s: 1.7.0.CR3 (was: 1.7.0.CR2) > JDK 11 Support > -------------- > > Key: ELY-1653 > URL: https://issues.jboss.org/browse/ELY-1653 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Assignee: Justin Cook > Fix For: 1.7.0.CR3 > > > I suspect this will likely take three / four steps: - > # Convert he project to a multi-release built using Java 9 > # Eliminate the use of APIs in sun.misc and sun.reflect in the Java 9 variant > # Ensure the project can be build on JDK 11 > This final step may not be achievable in the short term until we can drop support for JDK 8 but by moving to the Java 9 MR jar our jar should be compatible on Java 10 and 11 as well. We may want to define a PR run that builds on Java 9 but tests in Java 11, this would mean the testsuite at least needs to be buildable on Java 11. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1525) When SSO is enabled, multipart form and form enconding stop working.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1525?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1525: ---------------------------------- Fix Version/s: 1.7.0.CR3 (was: 1.7.0.CR2) > When SSO is enabled, multipart form and form enconding stop working. > -------------------------------------------------------------------- > > Key: ELY-1525 > URL: https://issues.jboss.org/browse/ELY-1525 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.6.Final, 1.2.1.Final > Reporter: Estevão Freitas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 1.7.0.CR3 > > > I developed a JSF application with "h:inputFile" component and it requires a form with " enctype="multipart/form-data" ". > I use this tutorial for SSO: https://docs.jboss.org/author/display/WFLY/Web+Single+Sign-On . > When I execute the last step: " /subsystem=undertow/application-security-domain=other/setting=single-sign-on:add(key-store=example-keystore, key-alias=localhost, domain=localhost, credential-reference=clear-text=secret}) ", all commandButtons stop working. > If I remove the "h:inputFile" component and " enctype="multipart/form-data" " from form all buttons works again, but all words with accents are corrupted. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

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.7.0.CR3 (was: 1.7.0.CR2) > 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.7.0.CR3 > > > 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

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.7.0.CR3 (was: 1.7.0.CR2) > 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.7.0.CR3 > > > 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

1
0
0 / 0

[JBoss JIRA] (ELY-1684) Release WildFly Elytron 1.7.0.CR2

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1684?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1684: ---------------------------------- Fix Version/s: 1.7.0.CR3 (was: 1.7.0.CR2) > Release WildFly Elytron 1.7.0.CR2 > --------------------------------- > > Key: ELY-1684 > URL: https://issues.jboss.org/browse/ELY-1684 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.7.0.CR3 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1682: ---------------------------------- Fix Version/s: 1.7.0.CR3 (was: 1.7.0.CR2) > Fallback to another SASL client mechanism when SASL client initialisation fails > ------------------------------------------------------------------------------- > > Key: ELY-1682 > URL: https://issues.jboss.org/browse/ELY-1682 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.7.0.CR1 > Reporter: Martin Choma > Fix For: 1.7.0.CR3 > > Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt > > > {code:title=HipChat conversation} > Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. > But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. > I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for? > Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected > Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). > In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved. > Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting > though for that one as that is where that loop happens but start with an ELY issue > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2018