February 2018 - 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: (was: 1.3.0.CR1) > 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 > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-138) Client timed logout options

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-138?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-138: --------------------------------- Fix Version/s: (was: 1.3.0.CR1) > Client timed logout options > --------------------------- > > Key: ELY-138 > URL: https://issues.jboss.org/browse/ELY-138 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > > It should be possible to configure a client-side authentication to auto-logout after either an absolute duration, or after some amount of idle time, or both. > The client-side authentication cache, whatever form it takes, must be aware of usages to update the logout time, for idle timeouts. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-60) Update the local authentication mechanism to allow permissions to be specified for the challenge file.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-60?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse updated ELY-60: -------------------------------- Fix Version/s: (was: 1.3.0.CR1) > Update the local authentication mechanism to allow permissions to be specified for the challenge file. > ------------------------------------------------------------------------------------------------------ > > Key: ELY-60 > URL: https://issues.jboss.org/browse/ELY-60 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > > (This would include switching to a dependency on Java 7 server side at least) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

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

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-490?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-490: --------------------------------- Fix Version/s: (was: 1.3.0.CR1) > Add JavaDoc for the 'org.wildfly.security.ssl' package and sub packages. > ------------------------------------------------------------------------ > > Key: ELY-490 > URL: https://issues.jboss.org/browse/ELY-490 > Project: WildFly Elytron > Issue Type: Enhancement > Reporter: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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: (was: 1.3.0.CR1) > 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 > > 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.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 reassigned ELY-1504: ------------------------------------- Fix Version/s: (was: 1.3.0.CR1) Assignee: (was: Darran Lofthouse) > 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 > > 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-422) Default SSLContext?

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-422?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-422: --------------------------------- Fix Version/s: (was: 1.3.0.CR1) > Default SSLContext? > ------------------- > > Key: ELY-422 > URL: https://issues.jboss.org/browse/ELY-422 > Project: WildFly Elytron > Issue Type: Task > Components: SSL > Reporter: Darran Lofthouse > > We know we want one, what we don't know is exactly that it means and is it an Elytron concern or subsystem concern. > One issue is within Elytron our SSLContext implementations are either server side specific or client side specific - we may even want to review if there is any way to review what it is being used for and act accordingly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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: (was: 1.3.0.CR1) > 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 > > 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.5.0#75005)

8 years, 2 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: (was: 1.3.0.CR1) > 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: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > > For example, for DIGEST is in RFC 7616 defined integrity protection - qop=auth-int. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-151) Ability to supply additional information during credential acquisition

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-151?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-151: --------------------------------- Fix Version/s: (was: 1.3.0.CR1) > Ability to supply additional information during credential acquisition > ---------------------------------------------------------------------- > > Key: ELY-151 > URL: https://issues.jboss.org/browse/ELY-151 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI, Passwords > Reporter: Darran Lofthouse > > I think this is the final known gap in our credential acquisition and validation API/SPI. > There are a couple of specifications that also allow for additional information to be used when obtaining a representation of a users credential, the most obvious being the session based variant of digest authentication where a nonce and cnonce are also incorporated. > A second variant with two different modes of operation would be the realm associated with the digest credential, currently we assume it is tightly associated with the storage representation of the credential but it could also be the case that the mech is requesting it for a specific realm. -- 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 February 2018