May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1204) RealmIdentity should have a three-argument version of getCredential()

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1204?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1204: ---------------------------------- Fix Version/s: 1.1.0.Beta49 (was: 1.1.0.Beta48) > RealmIdentity should have a three-argument version of getCredential() > --------------------------------------------------------------------- > > Key: ELY-1204 > URL: https://issues.jboss.org/browse/ELY-1204 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Server, Realms > Reporter: David Lloyd > Fix For: 1.1.0.Beta49 > > > {quote} > I observe that there is no method overload for {{RealmIdentity#getCredential()}} which accepts an {{AlgorithmParameterSpec}} as the {{CredentialSource}} types do. This theoretically limits the range of selectivity of credentials that can be used by a mechanism; though things like salt or nonce are usually derived from the stored credential rather than the other way around, it is possible that there are other parameters which might have an impact on the selection of the appropriate credential (like realm name, as I think this issue is about). > An appropriate three-argument overload can be added to this interface as a {{default}} method. An additional {{applyToCredential}} method can also be added accordingly. An additional {{getCredentialAcquireSupport}} method should be added as well; though it could be {{default}}, the default implementation would be less than optimal as it would have to delegate to {{getCredential}} to function properly. > It might be a good idea to add this overload now while the compatibility impact would be minimal; in this case, the new {{getCredentialAcquireSupport}} method would not have to be {{default}} (instead, the two-argument form could be made {{default}} or removed completely in favor of the three-argument version). > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1196) PrivilegedSaslClientFactory does not construct the delegate client under the privileged block

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1196?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1196: ---------------------------------- Fix Version/s: 1.1.0.Beta49 (was: 1.1.0.Beta48) > PrivilegedSaslClientFactory does not construct the delegate client under the privileged block > --------------------------------------------------------------------------------------------- > > Key: ELY-1196 > URL: https://issues.jboss.org/browse/ELY-1196 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta49 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1191) Undertow CLIENT_CERT via Elytron and HTTP/2 does not work

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1191?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1191: ---------------------------------- Fix Version/s: 1.1.0.Beta49 (was: 1.1.0.Beta48) > Undertow CLIENT_CERT via Elytron and HTTP/2 does not work > --------------------------------------------------------- > > Key: ELY-1191 > URL: https://issues.jboss.org/browse/ELY-1191 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Priority: Blocker > Fix For: 1.1.0.Beta49 > > > When I setup CLIENT_CERT authentication for an application (see Steps to Reproduce) and utilize HTTP/2 protocol, I get always 403 Forbidden even in case I use correct client certificate that should allow me access to a secured content. > I can see following TRACE messages in server.log: > {code} > 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) X500 principal [CN=client] decoded as name [client] (attribute values: [client]) > 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Principal assigning: [CN=client], pre-realm rewritten: [client], realm name: [ksRealm], post-realm rewritten: [client], realm rewritten: [client] > 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Role mapping: principal [client] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [gooduser] > 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing principal client. > 2017-05-23 10:58:31,110 TRACE [org.wildfly.security] (default task-7) Authorizing against the following attributes: [] => [] > 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Permission mapping: identity [client] with roles [gooduser] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true > 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authorization succeed > 2017-05-23 10:58:31,111 TRACE [org.wildfly.security] (default task-7) Authentication succeed for principal [CN=client] > 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) Handling MechanismInformationCallback type='HTTP' name='CLIENT_CERT' host-name='localhost' protocol='https' > 2017-05-23 10:58:31,117 TRACE [org.wildfly.security] (default task-10) CLIENT-CERT no SSL session > {code} > Authentication seems that it succeed just fine. But notice the last line - {{CLIENT-CERT no SSL session}}. > When I disable 'http2' in https-listener: > {code} > /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=enable-http2,value=false) > reload > {code} > I can now access secured content as expected. Also trace log contains different (more healthy) messages now. > This happens both when I utilize HTTP/2 with EAP 'alpn-hack' mechanism and also with ALPN provided by OpenSSL library. > As described in JBEAP-9803, Undertow needs to write into ssl-context when HTTP/2 with ALPN is utilized. Maybe this might be the source of this problem? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1190) Capture Subject into AuthenticationConfiguration

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1190?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1190: ---------------------------------- Fix Version/s: 1.1.0.Beta49 (was: 1.1.0.Beta48) > Capture Subject into AuthenticationConfiguration > ------------------------------------------------ > > Key: ELY-1190 > URL: https://issues.jboss.org/browse/ELY-1190 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI, Authentication Client, SASL > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 1.1.0.Beta49 > > > When an AuthenticationConfiguration is captured, it represents the identity being authenticated. Some mechanisms require a Subject to be established in order to retrieve the identity and credentials to use. The combination of these two facts implies that the AuthenticationConfiguration must encapsulate the Subject that was present at the time the configuration is realized by the ACCC. This Subject in turn must be propagated to the SASL authentication client (and later, possibly SSLContext to support KRB mechanisms). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1180) Ensure a cipher suite filter for HTTP/2 compatible cipher suites can be specified.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1180?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1180: ---------------------------------- Fix Version/s: 1.1.0.Beta49 (was: 1.1.0.Beta48) > Ensure a cipher suite filter for HTTP/2 compatible cipher suites can be specified. > ---------------------------------------------------------------------------------- > > Key: ELY-1180 > URL: https://issues.jboss.org/browse/ELY-1180 > Project: WildFly Elytron > Issue Type: Task > Components: SSL > Reporter: Darran Lofthouse > Fix For: 1.1.0.Beta49 > > > This may be more verification but we should ensure we can return an SSLContext optimised for HTTP/2. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1194) Elytron - failed OAUTHBEARER authentication doesn't close connection

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1194?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse reassigned ELY-1194: ------------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Elytron - failed OAUTHBEARER authentication doesn't close connection > -------------------------------------------------------------------- > > Key: ELY-1194 > URL: https://issues.jboss.org/browse/ELY-1194 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > Labels: eap71_beta_candidate > > When token verification in OAUTHBEARER SASL mechanism fails (e.g. token is already expired), the connection remain open and it hangs (until it timeouts). -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1210) Release WildFly Elytron 1.1.0.Beta48

by Darran Lofthouse (JIRA)

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

7 years

1
0
0 / 0

[JBoss JIRA] (ELY-1210) Release WildFly Elytron 1.1.0.Beta48

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1210: ------------------------------------- Summary: Release WildFly Elytron 1.1.0.Beta48 Key: ELY-1210 URL: https://issues.jboss.org/browse/ELY-1210 Project: WildFly Elytron Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta48 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2886) remove-handler operation succeeds when removing non-existent handler

by Michal Petrov (JIRA)

Michal Petrov created WFCORE-2886: ------------------------------------- Summary: remove-handler operation succeeds when removing non-existent handler Key: WFCORE-2886 URL: https://issues.jboss.org/browse/WFCORE-2886 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: Michal Petrov Assignee: Michal Petrov When trying to remove a handler that doesn't exist the operation should fail. E.g. {code} /subsystem=logging/root-logger=ROOT:remove-handler(name="ABC") {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2885) list-remove operation succeeds when removing non-existent item

by Michal Petrov (JIRA)

Michal Petrov created WFCORE-2885: ------------------------------------- Summary: list-remove operation succeeds when removing non-existent item Key: WFCORE-2885 URL: https://issues.jboss.org/browse/WFCORE-2885 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Michal Petrov Assignee: Michal Petrov When removing an item from a list the operation should fail if the item doesn't exist. E.g. {code} /subsystem=logging/root-logger=ROOT:list-remove(name=handlers,value="ABC") {code} the operation already fails when using an invalid index. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017