June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-214) Add support for OpenSSL-style key and certificate files

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-214?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-214: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.CR2) > Add support for OpenSSL-style key and certificate files > ------------------------------------------------------- > > Key: ELY-214 > URL: https://issues.jboss.org/browse/ELY-214 > Project: WildFly Elytron > Issue Type: Enhancement > Components: KeyStores > Reporter: David Lloyd > Assignee: Pedro Igor > Fix For: 1.2.0.Beta1 > > > Do the following: > * Research the various supported key and cert file formats supported by OpenSSL > * Determine what the JSSE equivalent is of each, if any > * Add {{KeyStore}} support for keys of any type or format which is not supported by JSSE -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-211) Client-side trust store configuration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-211?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-211. ---------------------------------- Resolution: Out of Date > Client-side trust store configuration > ------------------------------------- > > Key: ELY-211 > URL: https://issues.jboss.org/browse/ELY-211 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.CR2 > > > Lest I forget. The client needs the ability to supplement the default trust store, to restrict the set of acceptable peer certificates/signers, for mutual authentication purposes. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-262) The equivalent of wrap and unwrap for HTTP authentication mechanisms

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-262?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-262: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.CR2) > The equivalent of wrap and unwrap for HTTP authentication mechanisms > -------------------------------------------------------------------- > > Key: ELY-262 > URL: https://issues.jboss.org/browse/ELY-262 > Project: WildFly Elytron > Issue Type: Sub-task > Components: HTTP > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-261) Rework (and move) UsernamePasswordHashUtil

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-261?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-261: -------------------------------------- +1 to deprecation - maybe we should also remove the impl and adjust this class so it uses the PasswordFactory APIs > Rework (and move) UsernamePasswordHashUtil > ------------------------------------------ > > Key: ELY-261 > URL: https://issues.jboss.org/browse/ELY-261 > Project: WildFly Elytron > Issue Type: Feature Request > Components: API / SPI, Passwords > Reporter: Darran Lofthouse > Fix For: 1.1.0.CR2 > > > Firstly this class is not really SASL specific so should be in a general util package. > Secondly we now have password specs and a PasswordFactory - if this class still has a future then maybe it should be using those instead of it's own custom implementation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-252) Take into account username after failed authentication for available mechs

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-252?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-252: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.CR2) > Take into account username after failed authentication for available mechs > -------------------------------------------------------------------------- > > Key: ELY-252 > URL: https://issues.jboss.org/browse/ELY-252 > Project: WildFly Elytron > Issue Type: Task > Components: SASL > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > > This is something we would need to be cautious about as it does risk revealing information to an attacker but after a files attempt we may have more information and be able to offer mechanisms based on this. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-298) load-from/uri keystore xsd/parser mismatch

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-298?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-298. ---------------------------------- Resolution: Out of Date > load-from/uri keystore xsd/parser mismatch > ------------------------------------------ > > Key: ELY-298 > URL: https://issues.jboss.org/browse/ELY-298 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Kabir Khan > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR2 > > > The xsd has > {code} > <xsd:complexType name="key-store-type"> > <xsd:sequence minOccurs="1" maxOccurs="1"> >  > <xsd:choice minOccurs="1" maxOccurs="1"> > <xsd:element name="file" type="name-type" minOccurs="1" maxOccurs="1"/> > <xsd:element name="load-from" type="uri-type" minOccurs="1" maxOccurs="1"/> > <xsd:element name="resource" type="name-type" minOccurs="1" maxOccurs="1"/> > {code} > The parser seems to look for 'uri' rather than 'load-from' -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-286) HTTP Digest Authentication

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-286?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-286: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.CR2) > HTTP Digest Authentication > -------------------------- > > Key: ELY-286 > URL: https://issues.jboss.org/browse/ELY-286 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > > Original Digest RFC [https://tools.ietf.org/html/rfc2069] > Current Digest RFC [https://tools.ietf.org/html/rfc2617] > HTTP 1.1 Authentication (Updates RFC2617) [https://tools.ietf.org/html/rfc7235] > Draft currently under discussion - [https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/] > RFC7616 Now Proposed Standard > "HTTP Digest Access Authentication", September 2015 > [https://www.rfc-editor.org/info/rfc7616] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-271) EJB authentication via Kerberos does not work with wildfly-security-api

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-271?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-271. ---------------------------------- Resolution: Out of Date > EJB authentication via Kerberos does not work with wildfly-security-api > ----------------------------------------------------------------------- > > Key: ELY-271 > URL: https://issues.jboss.org/browse/ELY-271 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.0.0.Alpha3 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Fix For: 1.1.0.CR2 > > Attachments: client.zip, server.jar > > > EJB authentication via Kerberos does not work for projects using EJB Client with dependency on org.wildfly:wildfly-security-api. EJB invocation failed with exception: > {noformat} > java.lang.RuntimeException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"] > at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:92) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:80) > at org.jboss.ejb.client.remoting.RemotingConnectionManager.getConnection(RemotingConnectionManager.java:51) > at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.setupEJBReceivers(ConfigBasedEJBClientContextSelector.java:158) > at org.jboss.ejb.client.remoting.ConfigBasedEJBClientContextSelector.getCurrent(ConfigBasedEJBClientContextSelector.java:115) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.createIdentifiableEjbClientContext(EjbNamingContext.java:258) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.setupScopedEjbClientContextIfNeeded(EjbNamingContext.java:123) > at org.jboss.ejb.client.naming.ejb.EjbNamingContext.<init>(EjbNamingContext.java:98) > at org.jboss.ejb.client.naming.ejb.ejbURLContextFactory.getObjectInstance(ejbURLContextFactory.java:38) > at javax.naming.spi.NamingManager.getURLObject(NamingManager.java:601) > at javax.naming.spi.NamingManager.getURLContext(NamingManager.java:550) > at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:345) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at client.Client.main(Client.java:19) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:745) > Caused by: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed: > GSSAPI: javax.security.sasl.SaslException: ELY05108: [GSSAPI] Unable to create response token [Caused by javax.security.sasl.SaslException: ELY05127: [GSSAPI] No security layer supported by server but maximum message size received: "65536"] > at org.jboss.remoting3.remote.ClientConnectionOpenListener.allMechanismsFailed(ClientConnectionOpenListener.java:114) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:393) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:243) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:199) > at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:113) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.ChannelListeners$DelegatingChannelListener.handleEvent(ChannelListeners.java:1092) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > at ...asynchronous invocation...(Unknown Source) > at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272) > at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:388) > at org.jboss.ejb.client.remoting.EndpointPool$PooledEndpoint.connect(EndpointPool.java:192) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:153) > at org.jboss.ejb.client.remoting.NetworkUtil.connect(NetworkUtil.java:133) > at org.jboss.ejb.client.remoting.ConnectionPool.getConnection(ConnectionPool.java:78) > ... 18 more > {noformat} > Note: > Dependency org.wildfly:wildfly-security-api has transitive dependency on org.wildfly.security:wildfly-elytron. Artifact wildfly-elytron using service org.wildfly.security.sasl.gssapi.GssapiClientFactory which is added via Java SPI as javax.security.sasl.SaslClientService. Adding this service causes that Kerberos authentication is handled by org.wildfly.security.sasl.gssapi.GssapiClient which leads to authentication failures. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-415) Eliminate RuntimeExceptions thrown from SecurityRealm implementations.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-415?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-415. ---------------------------------- Resolution: Out of Date > Eliminate RuntimeExceptions thrown from SecurityRealm implementations. > ---------------------------------------------------------------------- > > Key: ELY-415 > URL: https://issues.jboss.org/browse/ELY-415 > Project: WildFly Elytron > Issue Type: Task > Components: Realms > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.1.0.CR2 > > > Where a realm is temporarily unavailable we have the RealmUnavailableException - in other cases however our API generally requires that null or empty representations are returned when identities can not be loaded or validation. > In a few cases RuntimeExceptions have crept into the implementations, we need to eliminate these as any code written according the API and not expecting them risks breaking for unexpected RuntimeExceptions. > Each method on the API should also be double checked to ensure it clearly documents what should happen if it can not return the desired result. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-355) HTTP Authentication Mechanism Testing

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-355?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-355: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.CR2) > HTTP Authentication Mechanism Testing > ------------------------------------- > > Key: ELY-355 > URL: https://issues.jboss.org/browse/ELY-355 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Testsuite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > > We don't want to create a full HTTP server but we should have a sufficient wrapper to test the HTTP authentication framework and test out specific mechanims. > This will leave the Elytron Web project to smoke test integration and not focus on testing the actual mechanisms. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 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 June 2017