December 2018 - jboss-jira - Jboss List Archives

[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.2.0.Beta12 (was: 1.8.0.CR1) > 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 > Priority: Major > Fix For: 1.2.0.Beta12 > > > 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.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1332) NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1332?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1332: ---------------------------------- Fix Version/s: (was: 1.8.0.CR1) > NSS tools based PKCS11 provider defined in Elytron doesn't survive server reload > -------------------------------------------------------------------------------- > > Key: ELY-1332 > URL: https://issues.jboss.org/browse/ELY-1332 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Priority: Major > > When a SunPKCS11 provider is defined in Elytron subsystem on the top of NSS keystore (e.g. a FIPS one), then the server reload fails with "ProviderException: Secmod module already configured". > The server.log contains: > {noformat} > 08:12:56,073 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.providers.nss: org.jboss.msc.service.StartException in service org.wildfly.security.providers.nss: java.lang.reflect.InvocationTargetException > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:224) > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:160) > at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955) > 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:748) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at org.wildfly.extension.elytron.ProviderDefinitions$1$1.get(ProviderDefinitions.java:190) > ... 7 more > Caused by: java.security.ProviderException: Secmod module already configured > at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:276) > at sun.security.pkcs11.SunPKCS11.<init>(SunPKCS11.java:107) > ... 12 more > .. > 08:12:56,140 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("provider-loader" => "nss") > ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.providers.nss" => "java.lang.reflect.InvocationTargetException > Caused by: java.lang.reflect.InvocationTargetException > Caused by: java.security.ProviderException: Secmod module already configured"}} > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1702) Update mockserver-netty to 5.4.1

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1702?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1702: ---------------------------------- Fix Version/s: 1.8.0.CR1 > Update mockserver-netty to 5.4.1 > -------------------------------- > > Key: ELY-1702 > URL: https://issues.jboss.org/browse/ELY-1702 > Project: WildFly Elytron > Issue Type: Component Upgrade > Components: Testsuite > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.8.0.CR1 > > > Update mockserver-netty to 5.4.1. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1693) Update AcmeClientSpi to make use of POST-as-GET instead of GET

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1693?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1693: ---------------------------------- Fix Version/s: 1.8.0.CR1 > Update AcmeClientSpi to make use of POST-as-GET instead of GET > -------------------------------------------------------------- > > Key: ELY-1693 > URL: https://issues.jboss.org/browse/ELY-1693 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.8.0.CR1 > > > The ACME protocol has been updated to replace unauthenticated GET requests to resources with “POST-as-GET” requests (this change was made during the final stages of IETF review). Once support for "POST-as-GET" requests has been added to Let's Encrypt's staging and production endpoints, we'll need to update our AcmeClientSpi to make use of "POST-as-GET" requests. Let's Encrypt will be removing support for unauthenticated GET requests on Nov. 1, 2019. More details can be found here: > https://community.letsencrypt.org/t/acme-v2-scheduled-deprecation-of-unau... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1519) Make restore of SecurityIdentity on replicated session configurable

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1519?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1519: ---------------------------------- Fix Version/s: 1.8.0.CR1 > Make restore of SecurityIdentity on replicated session configurable > ------------------------------------------------------------------- > > Key: ELY-1519 > URL: https://issues.jboss.org/browse/ELY-1519 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms > Affects Versions: 1.2.0.Final > Reporter: Martin Choma > Assignee: Ilia Vassilev > Priority: Major > Fix For: 1.8.0.CR1 > > > Currently in clustered environment Security Identity is restored during > * failover > * load balancer change node (not sticky behaviour) > * session passivation/activation > This is mainly expected and good. It ensures performance gain because no additional SPNEGO negotiation is performed. But it can make troubles for kerberos ticket propagation, as kerberos ticket can't be serialized and restored. > So idea is to have flag to turn this default behaviour off. When user authenticate to app1 on serverA and then wants to access app1 on serverB, SPNEGO authentication will be activated and kerberos ticket will be negotiated and will be available on serverB as well. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1539) Remove deprecated AuthConf setHost, setProtocol, setPort properties

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1539?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1539: ---------------------------------- Fix Version/s: 1.8.0.CR1 > Remove deprecated AuthConf setHost, setProtocol, setPort properties > ------------------------------------------------------------------- > > Key: ELY-1539 > URL: https://issues.jboss.org/browse/ELY-1539 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Priority: Critical > Fix For: 2.0.0.Alpha1 > > > We should deprecate (with a view towards removal) the setHost, setPort, and setProtocol properties of AuthenticationConfiguration. These properties are only sporadically utilized by backing systems, and often cause complex problems when they are used. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1539) Remove deprecated AuthConf setHost, setProtocol, setPort properties

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1539?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1539: ---------------------------------- Fix Version/s: 2.0.0.Alpha1 (was: 1.8.0.CR1) > Remove deprecated AuthConf setHost, setProtocol, setPort properties > ------------------------------------------------------------------- > > Key: ELY-1539 > URL: https://issues.jboss.org/browse/ELY-1539 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Priority: Critical > Fix For: 2.0.0.Alpha1 > > > We should deprecate (with a view towards removal) the setHost, setPort, and setProtocol properties of AuthenticationConfiguration. These properties are only sporadically utilized by backing systems, and often cause complex problems when they are used. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1690) JDK11 unknow cipher suites

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1690?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1690: ---------------------------------- Fix Version/s: 1.8.0.CR1 > JDK11 unknow cipher suites > --------------------------- > > Key: ELY-1690 > URL: https://issues.jboss.org/browse/ELY-1690 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Affects Versions: 1.7.0.CR2 > Reporter: Martin Choma > Assignee: Farah Juma > Priority: Critical > Labels: Java11 > Fix For: 1.8.0.CR1 > > > I have compared jdk supported ciphersuites with Elytron Mechanism Database. Here are cipher suites which does not match: > * TLS_AES_128_GCM_SHA256 > * TLS_AES_256_GCM_SHA384 > * TLS_EMPTY_RENEGOTIATION_INFO_SCSV > Especially first two seems important as are mentioned in TLS 1.3 rfc [1] > [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-28 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1675) Merge roles from entry and entry attributes

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1675?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1675: ---------------------------------- Fix Version/s: (was: 1.8.0.CR1) > Merge roles from entry and entry attributes > ------------------------------------------- > > Key: ELY-1675 > URL: https://issues.jboss.org/browse/ELY-1675 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.7.0.CR1 > Reporter: Martin Choma > Priority: Critical > > Double check Elytron ldap realm is capable doing this: > Having ldap entries like this > {code} > dn: cn=jduke,ou=Roles,ou=example2,${dnSuffix} > objectClass: top > objectClass: organizationalRole > description: cn=Echo,ou=Roles,ou=example2,${dnSuffix} > description: cn=TheDuke,ou=Roles,ou=example2,${dnSuffix} > cn: jduke > {code} > User will have roles jduke, Echo and TheDuke. > This was possible with Picketbox with this configuration > {code} > EapSetupTask roleAttributesConfiguration = > new LdapExtSecurityDomainBuilder(SECURITY_DOMAIN_NAME_PREFIX + DEP2) > .prepareDefaultForLdapServer(ldapServer) > .baseCtxDN("ou=People,ou=example2," + ldapServer.getDNSuffix()) > .rolesCtxDN("ou=Roles,ou=example2," + ldapServer.getDNSuffix()) > .referral("ignore") > .roleFilter("(|(objectClass=referral)(cn={0}))") > .roleAttributeID("description") > .roleAttributeIsDN("true") > .roleNameAttributeID("cn") > .roleRecursion("0") > .configure(); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1668) LDAP searchScope=OBJECT_SCOPE Elytron alternative

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/ELY-1668?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1668: ---------------------------------- Fix Version/s: (was: 1.8.0.CR1) > LDAP searchScope=OBJECT_SCOPE Elytron alternative > ------------------------------------------------- > > Key: ELY-1668 > URL: https://issues.jboss.org/browse/ELY-1668 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.6.1.Final > Reporter: Martin Choma > Priority: Critical > > During comparing PicketBox an Elytron we came to one scenario which I am not sure if is covered by Elytron. > "As a user I am able to authenticate and authorize into web application secured by LDAP (where the same is used for storing identities and roles) and roles are stored in tree structure and should be only referenced object." Author is Ondra Lukas which is not with us anymore so I tried to think about what could this be about? Based on context I came to conclusion this is about OBJECT_SCOPE value of property searchScope. > Could you revise if same is possible with Elytron? But anyway I am not sure how that feature can be useful. But maybe there is some corner case it can be useful I am not aware of. > {code} > dn: ou=People,${dnSuffix} > objectclass: top > objectclass: organizationalUnit > ou: People > dn: uid=jduke,ou=People,${dnSuffix} > objectclass: top > objectclass: person > objectclass: inetOrgPerson > uid: jduke > cn: Java Duke > sn: Duke > userPassword: Password1 > dn: ou=RolesLevel1,${dnSuffix} > objectclass: top > objectclass: organizationalUnit > ou: RolesLevel1 > dn: cn=RoleUnderLevel1,ou=RolesLevel1,${dnSuffix} > objectclass: top > objectclass: groupOfNames > cn: RoleUnderLevel1 > member: uid=jduke,ou=People,${dnSuffix} > description: the RoleUnderLevel1 group > {code} > [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 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 December 2018