August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-485) Add JavaDoc for the 'org.wildfly.security.auth.server' package and sub packages.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-485?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-485: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.Final) > Add JavaDoc for the 'org.wildfly.security.auth.server' package and sub packages. > -------------------------------------------------------------------------------- > > Key: ELY-485 > URL: https://issues.jboss.org/browse/ELY-485 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-375) Server-side channel binding can cause mismatches

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-375?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-375: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.Final) > Server-side channel binding can cause mismatches > ------------------------------------------------ > > Key: ELY-375 > URL: https://issues.jboss.org/browse/ELY-375 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Mechanisms, Callbacks > Reporter: David Lloyd > Fix For: 1.2.0.Beta1 > > > At present, the client and the server both locally query their connection situation to determine whether channel binding aware mechanisms should be made available for authentication. This is done by handling a {{ChannelBindingCallback}} and letting the callback handler determine what type of channel binding should be used, and what the data is. > However, this strategy fails if the client and server choose a different channel binding type, which is very likely to happen if at any point JSSE begins support for acquisition of the tls-unique channel binding data. A newer JDK would have tls-unique data, but an older JDK might only have tls-server-end-point available, resulting in a channel-binding-mismatch type error. > SCRAM allows the client to specify one channel binding type. So if the client supports multiple types, it has to guess at the type most likely to be supported by the server. > SCRAM allows the server to read the client's channel binding type. Ideally, the server would then select the matching channel binding type if it is available, instead of querying for it ahead of time. > So I propose the following: > # On the SCRAM client, continue to use the ChannelBindingCallback to choose the binding type and data. > # Introduce a callback type which allows a mechanism participant to provide a list of available channel binding types. > # On the SCRAM server, instead of using ChannelBindingCallback to select a binding type *and* acquire the binding data, use this channel binding types callback to acquire the set of available channel bindings within the server factory. > # On the SCRAM server, validate the client's selected binding type against the set of available channel bindings. > # Change the ChannelBindingCallback contract, so that if a binding type name is already provided, the corresponding binding data should be provided (or an exception thrown). If no channel binding type name is given, then the callback continues to function as it does today, where a type is chosen and provided along with its data. > # On the SCRAM server, use the modified ChannelBindingCallback contract to acquire the binding data for a pre-selected channel binding type. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 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 updated ELY-261: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.Final) > 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.2.0.Beta1 > > > 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, 8 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.2.0.Beta1 (was: 1.1.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 > Priority: Blocker > Fix For: 1.2.0.Beta1 > > > 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.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-155) Condense Message IDs

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-155?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-155: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.Final) > Condense Message IDs > -------------------- > > Key: ELY-155 > URL: https://issues.jboss.org/browse/ELY-155 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.2.0.Beta1 > > > This is a task to complete at the point of tagging, condense the message IDs to close any gaps in the numbering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-134) Complete API JavaDoc

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-134?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-134: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.Final) > Complete API JavaDoc > -------------------- > > Key: ELY-134 > URL: https://issues.jboss.org/browse/ELY-134 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Priority: Blocker > Fix For: 1.2.0.Beta1 > > > All API components and members must be JavaDoc'd. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-183) Protocols for password changing

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-183?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-183: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.Final) > Protocols for password changing > ------------------------------- > > Key: ELY-183 > URL: https://issues.jboss.org/browse/ELY-183 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta1 > > > Potentially this is a bit of a research task, as I have mentioned in a couple of places I don't like relying on SSL exclusively for confidentiality - my reasons being it is perfect until their is a compromise and then it is as useful as a chocolate tea pot ;-) > A lot of the emphasis in the Elytron development so far has been implementation of the more secure SASL mechanisms to eliminate weak password exchanges between a client and the server - however we still have the need for password to be set remotely, this task is to explore some of those options. > Are there any existing protocols to remotely set a password securely? > Is there anything specific to our current password types we can take advantage of? > Are there features of any of our SASL mechanisms to apply a second layer of confidentiality? > Any other options? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1309) Channel binding callback cannot support tls-unique

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1309?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1309: ---------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.Final) > Channel binding callback cannot support tls-unique > -------------------------------------------------- > > Key: ELY-1309 > URL: https://issues.jboss.org/browse/ELY-1309 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI, Authentication Client, Authentication Server, Callbacks, SASL > Reporter: David Lloyd > Assignee: David Lloyd > Priority: Blocker > Fix For: 1.2.0.Beta1 > > > The revised API for the channel binding callback uses SSL sessions, but the standard TLS channel binding types [according to the RFC|https://tools.ietf.org/html/rfc5929] are associated with the connection, not the session. It is likely that the proposed channel bindings JDK API will exist on SSLSocket/SSLEngine. Introduce an API that allows the callback handlers to acquire the connection information using a forward-compatible API. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-1031) Make the CredentialStore class final

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1031?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1031: ---------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.Final) > Make the CredentialStore class final > ------------------------------------ > > Key: ELY-1031 > URL: https://issues.jboss.org/browse/ELY-1031 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Credential Store > Reporter: Darran Lofthouse > Assignee: Peter Skopek > Priority: Critical > Fix For: 1.2.0.Beta1 > > > Unless there is a reason this has not already be done the class should probably be made final to be sure extension is not possible. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ELY-929) AuthenticationConfiguration uniqueness enhancements

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-929?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-929: --------------------------------- Fix Version/s: 1.2.0.Beta1 (was: 1.1.0.Final) > AuthenticationConfiguration uniqueness enhancements > --------------------------------------------------- > > Key: ELY-929 > URL: https://issues.jboss.org/browse/ELY-929 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.2.0.Beta1 > > > Apply some enhancements to AuthenticationConfiguration uniqueness. > * Add admonishing JavaDoc to {{useCallbackHandler}} to point out the importance of per-identity uniqueness of the callback handler > The following also may be possible and useful: > * Modify the {{AuthenticationConfiguration}} process to capture instances for {{Supplier}}-driven components at the time the configuration is used via the {{AuthenticationContextConfigurationClient}} > * Add a variation of {{useCallbackHandler}} which accepts a {{Supplier<CallbackHandler>}}, or a {{Function<T, CallbackHandler}} and a {{T}}, allowing constructor refs to be given -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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