July 2018 - jboss-jira - Jboss List Archives

[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: 1.5.1.CR1 (was: 1.5.0.Final) > 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 > Fix For: 1.5.1.CR1 > > > 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.5.0#75005)

7 years, 11 months

1
0
0 / 0

[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.5.1.CR1 (was: 1.5.0.Final) > 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.5.1.CR1 > > > 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, 11 months

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.5.1.CR1 (was: 1.5.0.Final) > 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.5.1.CR1 > > > 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, 11 months

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.5.1.CR1 (was: 1.5.0.Final) > 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.5.1.CR1 > > > 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, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-787) SASL mechanisms are not IANA registered and specifications are not provided

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-787?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-787: --------------------------------- Fix Version/s: 1.5.1.CR1 (was: 1.5.0.Final) > SASL mechanisms are not IANA registered and specifications are not provided > --------------------------------------------------------------------------- > > Key: ELY-787 > URL: https://issues.jboss.org/browse/ELY-787 > Project: WildFly Elytron > Issue Type: Task > Reporter: Josef Cacek > Priority: Critical > Labels: sasl > Fix For: 1.5.1.CR1 > > > Elytron comes with set of SASL mechanisms (as requested by EAP7-530), but they don't fit SASL requirements. > New mechanisms has to be registered by IANA as requested by [SASL RFC 4422 section 5|https://tools.ietf.org/html/rfc4422#section-5] and Java [SaslClientFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] and [SaslServerFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] contracts. > Current list of mechanisms provided by Elytron, which are not IANA registered: > * DIGEST-SHA > * DIGEST-SHA-256 > * DIGEST-SHA-512 > * JBOSS-LOCAL-USER > *Suggestion for improvement:* > Provide specifications for the new mechanisms and register the names by IANA (see [section 7 in RFC-4422|https://tools.ietf.org/html/rfc4422#section-7]). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1609) constraint drive authentication method in undertow doesn't work with elytron

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1609?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1609: ---------------------------------- Fix Version/s: 1.5.1.CR1 (was: 1.5.0.Final) > constraint drive authentication method in undertow doesn't work with elytron > ---------------------------------------------------------------------------- > > Key: ELY-1609 > URL: https://issues.jboss.org/browse/ELY-1609 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.4.0.Final > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.5.1.CR1 > > > When elytron is enabled constraint driven authentication method (i.e. proactive-authentication=false) has no effect. > If you try to request an unsecured page sending in an invalid user with basic authentication, you should get the page returned with constraint drive authentication and a 401 with proactive authentication. This is what happens without Elytron enabled. But if you enable Elytron it gives a 401 in both cases. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1597) Identity Restoration where the Principal is not quite enough.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1597?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1597: ---------------------------------- Fix Version/s: 1.5.1.CR1 (was: 1.5.0.Final) > Identity Restoration where the Principal is not quite enough. > ------------------------------------------------------------- > > Key: ELY-1597 > URL: https://issues.jboss.org/browse/ELY-1597 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.5.1.CR1 > > > Presently our authentication process is build around a SecurityRealm being able to create a RealmIdentity which we then convert to an AuthorizationIdentity which is then converted to a SecurityIdentity after applying appropriate SecurityDomain configured mappings. > Generally in a SecurityRealm one of two different methods tend to be used to create the RealmIdentity. > {code:java} > RealmIdentity getRealmIdentity(Principal principal) throws RealmUnavailableException > {code} > or > {code:java} > RealmIdentity getRealmIdentity(Evidence evidence) throws RealmUnavailableException > {code} > Generally from the realms we know about, where the Principal form of the method is used the realm will likely load the attributes that go into the AuthorizationIdentity from another source, however for the form that takes Evidence often the attributes can be derived from the evidence. > Where we persist identities to be restored later such as identity propagation, batch, clustering etc we persist the name of the identity and use it to restore the identity using the Principal form of the above methods. For cases where an identity was originally created using evidence we no longer have sufficient information to recreate the identity. > This Enhancement is to review how we can address this. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[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.1.CR1 (was: 1.5.0.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.1.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.1.CR1 (was: 1.5.0.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.1.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.1.CR1 (was: 1.5.0.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.1.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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2018