February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-928) Wrong type of Elytron match-no-user in XSD

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev reassigned ELY-928: --------------------------------- Assignee: Darran Lofthouse (was: Ilia Vassilev) > Wrong type of Elytron match-no-user in XSD > ------------------------------------------ > > Key: ELY-928 > URL: https://issues.jboss.org/browse/ELY-928 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Labels: user_experience > Fix For: 1.1.0.Beta28 > > > {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-928) Wrong type of Elytron match-no-user in XSD

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/ELY-928?page=com.atlassian.jira.plugin.sy... ] Ilia Vassilev reassigned ELY-928: --------------------------------- Assignee: Ilia Vassilev (was: Darran Lofthouse) > Wrong type of Elytron match-no-user in XSD > ------------------------------------------ > > Key: ELY-928 > URL: https://issues.jboss.org/browse/ELY-928 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Client > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Labels: user_experience > Fix For: 1.1.0.Beta28 > > > {{wildfly-elytron_1_0.xsd}} includes wrong type of {{match-no-user}} attribute from Elytron authentication-context. According to XSD it is type {{type="xs:string"}}, but it should be {{type="xs:boolean"}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8090) Changing Elytron default-authentication-context requires server restart

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-8090?page=com.atlassian.jira.plugin.... ] Kabir Khan resolved WFLY-8090. ------------------------------ Fix Version/s: 11.0.0.Alpha1 Resolution: Done > Changing Elytron default-authentication-context requires server restart > ----------------------------------------------------------------------- > > Key: WFLY-8090 > URL: https://issues.jboss.org/browse/WFLY-8090 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 11.0.0.Alpha1 > > Attachments: AuthnContextApp.war > > > In case when Elytron subsystem attribute default-authentication-context is changed (through write-attribute or undefine-attribute operation) then operation succeed and server is NOT set to reload-required state. However changed value is not used until server is reload. > Before fixing, it must be decided whether change of default-authentication-context should require server reload or not. [~dlofthouse] What should be correct behavior? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8229) When Elytron is used redirect from j_security_check uses HTTP code 303

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-8229?page=com.atlassian.jira.plugin.... ] Kabir Khan resolved WFLY-8229. ------------------------------ Resolution: Done > When Elytron is used redirect from j_security_check uses HTTP code 303 > ---------------------------------------------------------------------- > > Key: WFLY-8229 > URL: https://issues.jboss.org/browse/WFLY-8229 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Reporter: Josef Cacek > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 11.0.0.Alpha1 > > > Form authentication backed by Elytron in the web applications uses status code 303 (See Other) to redirect user after processing /j_security_check. > We see two serious issues here: > * Legacy security uses status code 302 (Moved Temporarily/Found) to handle this redirect and existing applications/clients may behave differently for these different codes. (e.g. default behavior of Apache HTTP client is to follow redirect for 303, but not to follow for 302) > * The 303 status code was introduced in HTTP 1.1 so it's not part of HTTP 1.0, but the 303 is returned also for HTTP/1.0 request as a HTTP/1.0 response, which is wrong. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8233) Messaging SecurityTestCase fails with Elytron profile in AS TS

by Josef Cacek (JIRA)

Josef Cacek created WFLY-8233: --------------------------------- Summary: Messaging SecurityTestCase fails with Elytron profile in AS TS Key: WFLY-8233 URL: https://issues.jboss.org/browse/WFLY-8233 Project: WildFly Issue Type: Bug Components: JMS, Test Suite Reporter: Josef Cacek Assignee: Jeff Mesnil The {{SecurityTestCase#testFailedAuthenticationBlankUserPass()}} test fails when executed with Elytron profile ({{-Delytron}}). {code} cd testsuite/integration/basic mvn clean test -Dtest=SecurityTestCase -Delytron ... Failed tests: SecurityTestCase.testFailedAuthenticationBlankUserPass:84 must not allow to create a session without any authentication Tests run: 6, Failures: 1, Errors: 0, Skipped: 0 {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-396) Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-396?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-396: ------------------------------ Fix Version/s: 3.0.0.Beta6 (was: 3.0.0.Beta5) > Look into whether READ_ONLY but not RUNTIME_ONLY domain server ops should be visible to users > --------------------------------------------------------------------------------------------- > > Key: WFCORE-396 > URL: https://issues.jboss.org/browse/WFCORE-396 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 3.0.0.Beta6 > > > Ops registered on a domain server without the RUNTIME_ONLY flag are hidden from users (e.g. in read-operation-names results etc) in order to not delude users into thinking they can do something like :write-attribute directly on a server (instead of modifying host or domain config elements.) > But shouldn't a READ_ONLY flag be sufficient as well? An op that only reads config should be valid. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-266) Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-266?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-266: ------------------------------ Fix Version/s: 3.0.0.Beta6 (was: 3.0.0.Beta5) > Deprecate the ParameterValidator constructor variants that accept allowNull and allowExpressions params > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-266 > URL: https://issues.jboss.org/browse/WFCORE-266 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 3.0.0.Beta6 > > > Most of the ParameterValidator implementations that get passed to AttributeDefinition accept params to control whether null and expressions are allowed. These are now redundant, as AttributeDefinition wraps the provided validator with NillableOrExpressionParameterValidator, and it handles that aspect of validation based on the settings of the AD. > So we should deprecate these constructor variants to let people know they aren't needed. Ideally shift the code as well. > CRITICAL: before doing this, make sure the AttributeDefinition variants that support complex types properly wrap any validators that are configured for *element* validation. A quick look shows that ListAttributeDefinition.Builder and MapAttributeDefinition.Builder do. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Kabir Khan updated WFCORE-13: ----------------------------- Fix Version/s: 3.0.0.Beta6 (was: 3.0.0.Beta5) > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Labels: EAP > Fix For: 3.0.0.Beta6 > > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-107) Update whoami operation to return authentication mechanism where verbose=true

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-107?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFCORE-107: ------------------------------ Fix Version/s: 3.0.0.Beta6 (was: 3.0.0.Beta5) > Update whoami operation to return authentication mechanism where verbose=true > ----------------------------------------------------------------------------- > > Key: WFCORE-107 > URL: https://issues.jboss.org/browse/WFCORE-107 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta6 > > > The admin console currently contains a "logout" handler that follows a round of HTTP message exchanges to trick the web browser into forgetting the credentials it has cached. > This only makes sense where the browser has cached a credential - if we return the authentication mechanism then the console can make a better decision regarding displaying the logout link or could change the implementation so display a message to the user explaining why logout does not make sense. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ] Kabir Khan updated WFCORE-1282: ------------------------------- Fix Version/s: 3.0.0.Beta6 (was: 3.0.0.Beta5) > Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string > --------------------------------------------------------------------------------------- > > Key: WFCORE-1282 > URL: https://issues.jboss.org/browse/WFCORE-1282 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 1.0.2.Final > Environment: Oracle Java > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta6 > > Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log > > > User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7. > Setting as critical as these cipher suites, are considered for strong and widely used in my opinion. > In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all. > Note, that analogous configuration in EAP6 works fine. > Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites(). > Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

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