March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1023) Use authentication context in OAuth2CredentialSource to obtain additional credentials from callback handlers

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/ELY-1023?page=com.atlassian.jira.plugin.s... ] Pedro Igor updated ELY-1023: ---------------------------- Summary: Use authentication context in OAuth2CredentialSource to obtain additional credentials from callback handlers (was: Use authentication context to obtain additional credentials from callback handlers) > Use authentication context in OAuth2CredentialSource to obtain additional credentials from callback handlers > ------------------------------------------------------------------------------------------------------------ > > Key: ELY-1023 > URL: https://issues.jboss.org/browse/ELY-1023 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Affects Versions: 1.1.0.Beta32 > Reporter: Pedro Igor > Assignee: Pedro Igor > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2456) Obtain password from external source (CMD, EXT) doesn't work on Windows.

by Dmitrii Tikhomirov (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2456?page=com.atlassian.jira.plugi... ] Dmitrii Tikhomirov reassigned WFCORE-2456: ------------------------------------------ Assignee: Dmitrii Tikhomirov (was: Darran Lofthouse) > Obtain password from external source (CMD, EXT) doesn't work on Windows. > ------------------------------------------------------------------------ > > Key: WFCORE-2456 > URL: https://issues.jboss.org/browse/WFCORE-2456 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Dmitrii Tikhomirov > > Obtain password from external source (CMD, EXT) doesn't work on Windows. > Try to create new CS which obtains password from external source: > {code} > /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) > {code} > pass.bat file contains only this > {code} > echo %1 > {code} > Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: > Add new alias to CS -> JCEKS file is created > Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. > In my opinion there is problem with back slashes in script path. > https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src... > Because when I add there back slashed to path then it works. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2386) Legacy Kerberos in management, unable to configure fallback authentication.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2386?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2386: ------------------------------------- Fix Version/s: 3.0.0.Beta10 > Legacy Kerberos in management, unable to configure fallback authentication. > --------------------------------------------------------------------------- > > Key: WFCORE-2386 > URL: https://issues.jboss.org/browse/WFCORE-2386 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > Fix For: 3.0.0.Beta11 > > > In EAP 7.0 there was possible to configure fallback (e.g. BASIC) authentication, if client does not support SPNEGO authentication. In EAP 7.1 this feature does not work anymore. > In EAP 7.0 server returns multiple chalanges (Negotiate/Basic) and client could choose which he will use. > {code:title=EAP 7.0} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > WWW-Authenticate: Basic realm="FallBackKerberosRealm" > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:02:45 GMT > <html><head><title>Error</title></head><body>401 - Unauthorized</body></html> > {code} > In EAP 7.1 (with same configuration) server returns only one chalange - Negotiate so client not supporting SPNEGO, can't fallback to Basic. > {code:title=EAP 7.1} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:01:28 GMT > <html><head><title>Error</title></head><body>401 - Unauthorized</body></html> > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2386) Legacy Kerberos in management, unable to configure fallback authentication.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2386?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2386: ------------------------------------- Fix Version/s: 3.0.0.Beta11 (was: 3.0.0.Beta10) > Legacy Kerberos in management, unable to configure fallback authentication. > --------------------------------------------------------------------------- > > Key: WFCORE-2386 > URL: https://issues.jboss.org/browse/WFCORE-2386 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > Labels: regression > Fix For: 3.0.0.Beta11 > > > In EAP 7.0 there was possible to configure fallback (e.g. BASIC) authentication, if client does not support SPNEGO authentication. In EAP 7.1 this feature does not work anymore. > In EAP 7.0 server returns multiple chalanges (Negotiate/Basic) and client could choose which he will use. > {code:title=EAP 7.0} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > WWW-Authenticate: Basic realm="FallBackKerberosRealm" > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:02:45 GMT > <html><head><title>Error</title></head><body>401 - Unauthorized</body></html> > {code} > In EAP 7.1 (with same configuration) server returns only one chalange - Negotiate so client not supporting SPNEGO, can't fallback to Basic. > {code:title=EAP 7.1} > HTTP/1.1 401 Unauthorized > Connection: keep-alive > WWW-Authenticate: Negotiate > X-Frame-Options: SAMEORIGIN > Content-Length: 77 > Content-Type: text/html > Date: Mon, 30 Jan 2017 11:01:28 GMT > <html><head><title>Error</title></head><body>401 - Unauthorized</body></html> > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2438) Legacy Kerberos for management interface returns 500 instead of 401

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2438?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2438: ------------------------------------- Fix Version/s: 3.0.0.Beta11 (was: 4.0.0.Alpha1) > Legacy Kerberos for management interface returns 500 instead of 401 > ------------------------------------------------------------------- > > Key: WFCORE-2438 > URL: https://issues.jboss.org/browse/WFCORE-2438 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta11 > > > On first access server should response with 401 http code. Subsequent response could be 500, as it express properly server is misconfigured. In EAP 7.0 it was 403, that is not ideal as 403 mean user is authenticated but has not proper roles, which is not true in this case. > Also some ERROR log message would be helpful for administrators to find cause of problem. Now there are just TRACE level messages > {code:title=server.log} > 07:40:04,134 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for name 'http/localhost.localdomain' to KeytabService, attempting to use host only match. > 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No mapping for host 'localhost.localdomain' to KeytabService, attempting to use default. > 07:40:04,135 TRACE [org.jboss.as.domain.management.security] (management task-6) No KeytabService available for host 'localhost.localdomain' unable to return SubjectIdentity. > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2486) Legacy ldap realm returns 401 if LDAP is unreachable

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2486?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2486: ------------------------------------- Fix Version/s: 3.0.0.Beta11 > Legacy ldap realm returns 401 if LDAP is unreachable > ---------------------------------------------------- > > Key: WFCORE-2486 > URL: https://issues.jboss.org/browse/WFCORE-2486 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta11 > > > Contradics JBEAP-8125 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1022) Elytron Audit Logging does not support sending messages over TLS

by Jan Tymel (JIRA)

[ https://issues.jboss.org/browse/ELY-1022?page=com.atlassian.jira.plugin.s... ] Jan Tymel reassigned ELY-1022: ------------------------------ Assignee: (was: Darran Lofthouse) > Elytron Audit Logging does not support sending messages over TLS > ---------------------------------------------------------------- > > Key: ELY-1022 > URL: https://issues.jboss.org/browse/ELY-1022 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Tymel > Priority: Blocker > > Currently, Elytron Audit Logging supports only UDP and TCP transport protocols for sending messages to Syslog server. There should be a possibility to send messages over TLS as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1022) Elytron Audit Logging does not support sending messages over TLS

by Jan Tymel (JIRA)

Jan Tymel created ELY-1022: ------------------------------ Summary: Elytron Audit Logging does not support sending messages over TLS Key: ELY-1022 URL: https://issues.jboss.org/browse/ELY-1022 Project: WildFly Elytron Issue Type: Bug Reporter: Jan Tymel Assignee: Darran Lofthouse Priority: Blocker Currently, Elytron Audit Logging supports only UDP and TCP transport protocols for sending messages to Syslog server. There should be a possibility to send messages over TLS as well. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2396) credential-store and authentication-context in Elytron dir-context should be mutually exclusive

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2396?page=com.atlassian.jira.plugi... ] Jan Kalina reassigned WFCORE-2396: ---------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > credential-store and authentication-context in Elytron dir-context should be mutually exclusive > ----------------------------------------------------------------------------------------------- > > Key: WFCORE-2396 > URL: https://issues.jboss.org/browse/WFCORE-2396 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > > To avoid possibility when two different credentials are configured in Elytron dir-context, its attributes credential-store and authentication-context should be mutually exclusive. > This jira is based on discussion in JBEAP-8026. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8358) Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX

by Mario García García (JIRA)

[ https://issues.jboss.org/browse/WFLY-8358?page=com.atlassian.jira.plugin.... ] Mario García García updated WFLY-8358: -------------------------------------- Description: Performing a typical AJAX call with JQUERY ($.ajax function) to a Servlet from a JSP with method POST and sending a parameter that contains a String with latin characters such as 'ó'. This is the String that is sent into a parameter: "Código" No content type specified so JQUERY.AJAX takes the default one (contentType: 'application/x-www-form-urlencoded, charset=UTF-8'). The received parameter in HttpServletRequest (doPost method) is showed like this: "C??digo". In Hex this is the content: 43 3f3f 6469676f (spaces added for better reading pourposes) This is not UTF-8. The proper encoding should be: 43 c3b3 6469676f (spaces added for better reading pourposes) Wildfly Configuration: Subsystems Subsystem: Web/HTTP - Undertow Settings: Servlet/JSP Default encoding: (empty) Java encoding: UTF8 Subsystems Subsystem: Web/HTTP - Undertow Settings: HTTP Url charset: UTF-8 was: Performing a typical AJAX call with JQUERY ($.ajax function) to a Servlet from a JSP with method POST and sending a parameter that contains a String with latin characters such as 'ó'. This is the String that is sent into a parameter: "Código" No content type specified so JQUERY.AJAX takes the default one (contentType: 'application/x-www-form-urlencoded, charset=UTF-8'). The received parameter in HttpServletRequest (doPost method) is showed like this: "C??digo". In Hex this is the content: 43 3f3f 6469676f (spaces added for better reading pourposes) This is no UTF-8. The proper encoding should be: 43 c3b3 6469676f (spaces added for better reading pourposes) Wildfly Configuration: Subsystems Subsystem: Web/HTTP - Undertow Settings: Servlet/JSP Default encoding: (empty) Java encoding: UTF8 Subsystems Subsystem: Web/HTTP - Undertow Settings: HTTP Url charset: UTF-8 > Wrong charset received in HttpServletRequest sent by POST method with JQUERY AJAX > --------------------------------------------------------------------------------- > > Key: WFLY-8358 > URL: https://issues.jboss.org/browse/WFLY-8358 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 10.1.0.Final > Environment: Tested in Windows 7 Enterprise and tested in Linux 3.16.6-2-desktop > Reporter: Mario García García > Assignee: Jason Greene > Attachments: MiServlet.java, index.jsp > > > Performing a typical AJAX call with JQUERY ($.ajax function) to a Servlet from a JSP with method POST and sending a parameter that contains a String with latin characters such as 'ó'. > This is the String that is sent into a parameter: > "Código" > No content type specified so JQUERY.AJAX takes the default one (contentType: 'application/x-www-form-urlencoded, charset=UTF-8'). > The received parameter in HttpServletRequest (doPost method) is showed like this: > "C??digo". > In Hex this is the content: > 43 3f3f 6469676f (spaces added for better reading pourposes) > This is not UTF-8. The proper encoding should be: > 43 c3b3 6469676f (spaces added for better reading pourposes) > Wildfly Configuration: > Subsystems Subsystem: Web/HTTP - Undertow Settings: Servlet/JSP > Default encoding: (empty) > Java encoding: UTF8 > Subsystems Subsystem: Web/HTTP - Undertow Settings: HTTP > Url charset: UTF-8 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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