April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-1103?page=com.atlassian.jira.plugin.s... ] David Lloyd commented on ELY-1103: ---------------------------------- My personal opinion is that we should reject this issue and require users to specify real user names. This would save us having to perform a somewhat complex modification to our server code for what is arguably an error condition. > Special handling for JBOSS-LOCAL-USER server side authentication > ---------------------------------------------------------------- > > Key: ELY-1103 > URL: https://issues.jboss.org/browse/ELY-1103 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Server, SASL > Reporter: David Lloyd > Fix For: 1.1.0.Beta39 > > > If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails. In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity. > With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side. Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name. Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}. Configurations which do not specify a user name will not have this problem. > While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations. If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name. Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity. > If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested. > Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8647) MapBasedInitialContextEjbClientTestCase fails (with -Delytron)

by David Lloyd (JIRA)

David Lloyd created WFLY-8647: --------------------------------- Summary: MapBasedInitialContextEjbClientTestCase fails (with -Delytron) Key: WFLY-8647 URL: https://issues.jboss.org/browse/WFLY-8647 Project: WildFly Issue Type: Bug Reporter: David Lloyd Fix For: 11.0.0.Beta1 The test failure can be found on private CI [here|https://ci.wildfly.org/viewLog.html?buildId=55905&buildTypeId=WF_Pul...]. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1103) Special handling for JBOSS-LOCAL-USER server side authentication

by David Lloyd (JIRA)

David Lloyd created ELY-1103: -------------------------------- Summary: Special handling for JBOSS-LOCAL-USER server side authentication Key: ELY-1103 URL: https://issues.jboss.org/browse/ELY-1103 Project: WildFly Elytron Issue Type: Enhancement Components: Authentication Server, SASL Reporter: David Lloyd Fix For: 1.1.0.Beta39 If an authentication attempt comes in using the JBOSS-LOCAL-USER mechanism with an authentication name that does not correspond to a real identity, authentication fails. In previous releases, we allowed such authentications to proceed, mapping them to a "special" identity. With the Elytron-based authentication client and server, this occurs when a specific authentication principal is explicitly set, and that authentication principal does not correspond to a real identity on the server side. Another way to trigger this problem is to have a custom callback handler which handles NameCallback and explicitly specifies a non-existent name. Note that callback handlers which accept the suggested default name will not have this problem, nor will callback handlers which are explicitly aware of the special {{OptionalNameCallback}}. Configurations which do not specify a user name will not have this problem. While logically it is an error condition to specify a user name that does not exist, historically we have allowed such authentications to proceed because of the privileged nature of local invocations. If we decide to continue doing so, we will need to introduce a special hook into the ServerAuthenticationContext's callback handler to detect when the local user mechanism is being used, and attempt to look up the user, and if the user is not found, fall back to the special "$local" user name. Another alternative is to produce an ad-hoc identity, however this would differ in behavior in a few key ways compared to using a fallback identity. If we decide to reject this enhancement, then the corresponding application server tests must be updated to specify a real user name or to accept the default name that is suggested. Note that if an authorization ID is set in the authentication request, it should be respected and the run-as authorization check should happen as per normal. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8646) MapBasedInitialContextEjbClientTestCase fails (with -Delytron)

by David Lloyd (JIRA)

David Lloyd created WFLY-8646: --------------------------------- Summary: MapBasedInitialContextEjbClientTestCase fails (with -Delytron) Key: WFLY-8646 URL: https://issues.jboss.org/browse/WFLY-8646 Project: WildFly Issue Type: Bug Reporter: David Lloyd Fix For: 11.0.0.Beta1 The test failure can be found on private CI [here|https://ci.wildfly.org/viewLog.html?buildId=55905&buildTypeId=WF_Pul...]. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2691) Elytron modifiable realms should show existing identities in subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2691?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2691: ------------------------------------------ [~okotek] Good question. Yes, I think we need to file something to at least reconsider this. >From a naive point of view, the "identity" case seemed particularly troublesome, as standard identity stores are things like LDAP servers or databases which typically are 1) remote and 2) may have a very great number of entries. While a credential-store seems more likely to at least be on the local system, perhaps with the contents in memory anyway and the number of aliases not in the thousands. But that "seems more likely" is what I mean by a naive point of view. JBEAP-8971 also relates to this. In a domain if you invoke an "add" or "remove" operation against a resource address, people have a natural expectation for a certain behavior pattern, but that can't be achieved with these alias resources. > Elytron modifiable realms should show existing identities in subsystem > ---------------------------------------------------------------------- > > Key: WFCORE-2691 > URL: https://issues.jboss.org/browse/WFCORE-2691 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta15 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: filesystem-realm, security-realm > > Elytron {{filesystem-realm}} should load existing identities from file system. The steps to reproduce results in: > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:read-identity > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0216: Management resource '[ > (\"subsystem\" => \"elytron\"), > (\"filesystem-realm\" => \"realm\"), > (\"identity\" => \"user\") > ]' not found", > "rolled-back" => true > } > [standalone@localhost:9990 /] /subsystem=elytron/filesystem-realm=realm/identity=user:add > { > "outcome" => "failed", > "failure-description" => "WFLYELY01000: Identity with name [user] already exists.", > "rolled-back" => true > } > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8643) RestEasy GZIP Compression Not Setting Content-Encoding

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8643?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-8643: --------------------------------- Assignee: Alessio Soldano > RestEasy GZIP Compression Not Setting Content-Encoding > ------------------------------------------------------ > > Key: WFLY-8643 > URL: https://issues.jboss.org/browse/WFLY-8643 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 11.0.0.Alpha1 > Environment: Encountered the issue running in a Windows 7 environment > Reporter: Xavier Hammond > Assignee: Alessio Soldano > > The Content-Encoding is not set to gzip when a RESTful service endpoint returns GZIP compressed data. > This only occurs when I deploy to the Wildfly 11 Alpha release. No issues with Wildfly 10 Final. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8643) RestEasy GZIP Compression Not Setting Content-Encoding

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8643?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-8643: ------------------------------ Component/s: REST (was: EE) > RestEasy GZIP Compression Not Setting Content-Encoding > ------------------------------------------------------ > > Key: WFLY-8643 > URL: https://issues.jboss.org/browse/WFLY-8643 > Project: WildFly > Issue Type: Feature Request > Components: REST > Affects Versions: 11.0.0.Alpha1 > Environment: Encountered the issue running in a Windows 7 environment > Reporter: Xavier Hammond > > The Content-Encoding is not set to gzip when a RESTful service endpoint returns GZIP compressed data. > This only occurs when I deploy to the Wildfly 11 Alpha release. No issues with Wildfly 10 Final. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8643) RestEasy GZIP Compression Not Setting Content-Encoding

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8643?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-8643: ------------------------------ Issue Type: Bug (was: Feature Request) > RestEasy GZIP Compression Not Setting Content-Encoding > ------------------------------------------------------ > > Key: WFLY-8643 > URL: https://issues.jboss.org/browse/WFLY-8643 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 11.0.0.Alpha1 > Environment: Encountered the issue running in a Windows 7 environment > Reporter: Xavier Hammond > > The Content-Encoding is not set to gzip when a RESTful service endpoint returns GZIP compressed data. > This only occurs when I deploy to the Wildfly 11 Alpha release. No issues with Wildfly 10 Final. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8645) LdapUrlInSearchBaseTestCase is failing due to WFNC-29

by David Lloyd (JIRA)

David Lloyd created WFLY-8645: --------------------------------- Summary: LdapUrlInSearchBaseTestCase is failing due to WFNC-29 Key: WFLY-8645 URL: https://issues.jboss.org/browse/WFLY-8645 Project: WildFly Issue Type: Bug Reporter: David Lloyd Fix For: 11.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFLY-8644) LdapUrlInSearchBaseTestCase is failing due to WFNC-29

by David Lloyd (JIRA)

David Lloyd created WFLY-8644: --------------------------------- Summary: LdapUrlInSearchBaseTestCase is failing due to WFNC-29 Key: WFLY-8644 URL: https://issues.jboss.org/browse/WFLY-8644 Project: WildFly Issue Type: Bug Reporter: David Lloyd Fix For: 11.0.0.Beta1 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 April 2017