May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1425) Add support for JASPIC / JSR-196

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1425?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1425: ---------------------------------- Fix Version/s: 1.3.2.CR1 (was: 1.3.1.Final) > Add support for JASPIC / JSR-196 > -------------------------------- > > Key: ELY-1425 > URL: https://issues.jboss.org/browse/ELY-1425 > Project: WildFly Elytron > Issue Type: Feature Request > Components: EE, HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.3.2.CR1 > > > This is an overall tracking task for changes required to WildFly Elytron to support JASPIC. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1409) Update HTTP authentication mechanism API to support re-use of response handlers

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1409?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1409: ---------------------------------- Fix Version/s: 1.3.2.CR1 (was: 1.3.1.Final) > Update HTTP authentication mechanism API to support re-use of response handlers > ------------------------------------------------------------------------------- > > Key: ELY-1409 > URL: https://issues.jboss.org/browse/ELY-1409 > Project: WildFly Elytron > Issue Type: Task > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.3.2.CR1 > > > At the moment the response handler can only access the response, it can not access anything from the request unless created with access to the request. > Making the scopes available should allow for state to be transferred on the request scope. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1575) Release WildFly Elytron 1.3.1.Final

by Darran Lofthouse (JIRA)

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

8 years, 2 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.3.2.CR1 (was: 1.3.1.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.3.2.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)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1500) Coverity, Infinite Loop in FactoryCredentialSource

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1500?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1500: ---------------------------------- Fix Version/s: 1.3.2.CR1 (was: 1.3.1.Final) > Coverity, Infinite Loop in FactoryCredentialSource > -------------------------------------------------- > > Key: ELY-1500 > URL: https://issues.jboss.org/browse/ELY-1500 > Project: WildFly Elytron > Issue Type: Bug > Components: Credentials > Affects Versions: 1.2.0.Beta12 > Reporter: Martin Choma > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.3.2.CR1 > > > Effectivelly Elytron contains infinite recursion implemented. > {code:java|title=FactoryCredentialSource.java} > @Override > public SupportLevel getCredentialAcquireSupport(Class<? extends Credential> credentialType, String algorithmName, AlgorithmParameterSpec parameterSpec) throws IOException { > return getCredentialAcquireSupport(credentialType, algorithmName, parameterSpec) != null ? SupportLevel.SUPPORTED : SupportLevel.UNSUPPORTED; > } > {code} > [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46596... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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.3.2.CR1 (was: 1.3.1.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.3.2.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)

8 years, 2 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.3.2.CR1 (was: 1.3.1.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.3.2.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)

8 years, 2 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.3.2.CR1 (was: 1.3.1.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.3.2.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)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3799) FIPS mode is not detected correctly

by Martin Choma (JIRA)

Martin Choma created WFCORE-3799: ------------------------------------ Summary: FIPS mode is not detected correctly Key: WFCORE-3799 URL: https://issues.jboss.org/browse/WFCORE-3799 Project: WildFly Core Issue Type: Bug Components: Security Affects Versions: 5.0.0.Alpha4 Reporter: Martin Choma Assignee: Darran Lofthouse Priority: Blocker Trying SSL in FIPS mode I get "KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used" {code} 17:45:32,678 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.ssl-context.server-ssl-context: org.jboss.msc.service.StartException in service org.wildfly.security.ssl-context.server-ssl-context: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:926) at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714) at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693) at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) at java.lang.Thread.run(Thread.java:748) Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149) at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66) at javax.net.ssl.SSLContext.init(SSLContext.java:282) at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372) at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53) at org.wildfly.extension.elytron.SSLDefinitions$6.lambda$getValueSupplier$1(SSLDefinitions.java:924) ... 9 more 17:45:32,686 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0013: Operation ("add") failed - address: ([ ("subsystem" => "elytron"), ("server-ssl-context" => "server-ssl-context") ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.ssl-context.server-ssl-context" => "java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used"}} {code} Debugging revealed problem is in this call {code:java|title=SSLDefinitions.java} final Class<?> providerClazz = SSLDefinitions.class.getClassLoader().loadClass("com.sun.net.ssl.internal.ssl.Provider"); {code} which ends with ClassNotFoundException {code} java.lang.ClassNotFoundException: com.sun.net.ssl.internal.ssl.Provider from [Module "org.wildfly.extension.elytron" version 5.0.0.Alpha-redhat-20180502 from local module loader @41ee392b (finder: local module finder @1e67a849 (roots: /home/mchoma/Repos/tests-security/fips/target/dist/jboss-eap/modules,/home/mchoma/Repos/tests-security/fips/target/dist/jboss-eap/modules/system/layers/base))] {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1532) Deprecate AuthConf setHost, setProtocol, setPort properties

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1532?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1532: ------------------------------------- Assignee: David Lloyd > Deprecate AuthConf setHost, setProtocol, setPort properties > ----------------------------------------------------------- > > Key: ELY-1532 > URL: https://issues.jboss.org/browse/ELY-1532 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Critical > Fix For: 1.3.1.Final, 1.4.0.CR1 > > > 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.5.0#75005)

8 years, 2 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 May 2018