January 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-12975) JWT is rejected if signature matching public key is not first in JWK set

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/WFLY-12975?page=com.atlassian.jira.plugi... ] Sonia Zaldana updated WFLY-12975: --------------------------------- Git Pull Request: https://github.com/smallrye/smallrye-jwt/pull/160, https://github.com/smallrye/smallrye-jwt/pull/166 (was: https://github.com/smallrye/smallrye-jwt/pull/160) > JWT is rejected if signature matching public key is not first in JWK set > ------------------------------------------------------------------------ > > Key: WFLY-12975 > URL: https://issues.redhat.com/browse/WFLY-12975 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Priority: Critical > Attachments: jwks.json, jwt.base64 > > > When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array. > This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property. > Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair. > This breaks MP-JWT specification compatibility because the MP-JWT 1.1 states: > In section 9.2.3: > {quote} > If the incoming JWT uses the kid header field and there is a key in the supplied JWK set with the same kid, only that key is considered for verification of the JWT’s digital signature. > {quote} > In section 4.1: > {quote} > kid - This JOSE header parameter is a hint indicating which key was used to secure the JWT. RFC7515, Section-4.1.4 > {quote} > And the RFC7515, Section-4.1.4 states: > {quote} > When used with a JWK, the "kid" value is used to match a JWK "kid" parameter value. > {quote} -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2043) Incorrect and confusing trace message

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/ELY-2043?page=com.atlassian.jira.plugin.... ] Sonia Zaldana updated ELY-2043: ------------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/1480 > Incorrect and confusing trace message > ------------------------------------- > > Key: ELY-2043 > URL: https://issues.redhat.com/browse/ELY-2043 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.14.0.Final > Reporter: Mike Douglass > Assignee: Sonia Zaldana > Priority: Minor > > org.wildfly.security.http.util.AggregateServerMechanismFactory > has one incorrect trace message and one which could be more helpful: > getMechanismNames has > {color:#0033b3}if {color}(log.isTraceEnabled()) { > log.tracef({color:#067d17}"No %s provided by factories in %s: %s"{color}, HttpServerAuthenticationMechanismFactory.{color:#0033b3}class{color}.getSimpleName(), getClass().getSimpleName(), Arrays.toString(factories)); > } > {color:#0033b3}return {color}names.toArray({color:#0033b3}new {color}String[names.size()]); > should that be > {color:#0033b3}if {color}(log.isTraceEnabled()) { > log.tracef({color:#067d17}"%s factories in %s: %s"{color}, HttpServerAuthenticationMechanismFactory.{color:#0033b3}class{color}.getSimpleName(), getClass().getSimpleName(), Arrays.toString(factories)); > } > {color:#0033b3}return {color}names.toArray({color:#0033b3}new {color}String[names.size()]); > ? > Same message in createAuthenticationMechanism > {color:#0033b3}if {color}(log.isTraceEnabled()) { > log.tracef({color:#067d17}"No %s provided by factories in %s: %s"{color}, HttpServerAuthenticationMechanismFactory.{color:#0033b3}class{color}.getSimpleName(), getClass().getSimpleName(), Arrays.toString(factories)); > } > It would be useful if it supplied the mechanism e.g: > {color:#0033b3}if {color}(log.isTraceEnabled()) { > log.tracef({color:#067d17}"Mechanism %s not %s provided by factories in %s: %s"{color}, mechanism, HttpServerAuthenticationMechanismFactory.{color:#0033b3}class{color}.getSimpleName(), getClass().getSimpleName(), Arrays.toString(factories)); > } > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-11999) WildFly creates too many instances of all web service classes

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-11999?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-11999: ------------------------------------ Fix Version/s: 22.0.0.Final 22.0.0.Beta1 > WildFly creates too many instances of all web service classes > ------------------------------------------------------------- > > Key: WFLY-11999 > URL: https://issues.redhat.com/browse/WFLY-11999 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.0.0.Final, 16.0.0.Final, 19.0.0.Final > Environment: Ubuntu 18.10 64bit, Open JDK 8 or Open JDK 11 > Reporter: Stefan Frings > Assignee: Parul Sharma > Priority: Minor > Fix For: 22.0.0.Beta1, 22.0.0.Final > > Attachments: Test-1.0-SNAPSHOT.war, Test.zip, standalone.xml > > > 1) My @Webservice classes are all constructed multiple times (3x - 4x) but I expected only one instance. > 2) Only the second instance receives a call to the observer method for initialization. I expect that this method is called in each instance. > The issue can be reproduced with the attached minimum project on Wildfly 8 with JDK 8 as well as Wildfly 16 with JDK 11. > Complete source code of the whole application: > {code} > package com.mvneco.test; > import javax.enterprise.context.ApplicationScoped; > import javax.enterprise.context.Initialized; > import javax.enterprise.event.Observes; > import javax.jws.WebMethod; > import javax.jws.WebService; > import org.apache.commons.logging.Log; > import org.apache.commons.logging.LogFactory; > @ApplicationScoped > @WebService > public class SoapService > { > private Log log = LogFactory.getLog(SoapService.class); > public SoapService() > { > log.debug("Init SoapService 1"); > } > @WebMethod(exclude = true) > public void init(@Observes @Initialized(ApplicationScoped.class) Object init) > { > log.debug("Init SoapService 2"); > } > @WebMethod > public String test(String payload) > { > log.debug("Start test(). payload="+payload); > return "OK"; > } > } > {code} > Extract from Log messages that show the issue (the complete log is in the attached ZIP): > {code} > 2019-04-17 13:12:21,399 DEBUG [com.mvneco.test.SoapService] (MSC service thread 1-2) Init SoapService 1 > 2019-04-17 13:12:23,068 DEBUG [com.mvneco.test.SoapService] (ServerService Thread Pool -- 74) Init SoapService 1 > 2019-04-17 13:12:23,070 DEBUG [com.mvneco.test.SoapService] (ServerService Thread Pool -- 74) Init SoapService 2 > 2019-04-17 13:12:23,475 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 16.0.0.Final (WildFly Core 8.0.0.Final) started in 10514ms - Started 510 of 699 services (337 services are lazy, passive or on-demand) > 2019-04-17 13:12:28,920 INFO [org.apache.cxf.services.SoapService.REQ_IN] (default task-1) REQ_IN > Address: http://localhost:8080/Test-1.0-SNAPSHOT/SoapService > ... > 2019-04-17 13:12:28,932 DEBUG [com.mvneco.test.SoapService] (default task-1) Init SoapService 1 > 2019-04-17 13:12:28,937 DEBUG [com.mvneco.test.SoapService] (default task-1) Init SoapService 1 > 2019-04-17 13:12:28,937 DEBUG [com.mvneco.test.SoapService] (default task-1) Start test(). payload=? > 2019-04-17 13:12:28,969 INFO [org.apache.cxf.services.SoapService.RESP_OUT] (default task-1) RESP_OUT > Content-Type: text/xml > ... > {code} -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (JGRP-2524) Replace XML parser with simple parser for magic-map and protocol-ids

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2524?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2524. ---------------------------- Resolution: Done Backported to 4.x > Replace XML parser with simple parser for magic-map and protocol-ids > -------------------------------------------------------------------- > > Key: JGRP-2524 > URL: https://issues.redhat.com/browse/JGRP-2524 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.11, 5.1.3 > > > Even when configuring a stack programmatically, the reading of magic-map-ids.xml and protocol-ids.xml requires {{javax.xml}}, which pulls in a lot of classes, which remain in memory for the duration of the program. > Todo: replace this with a simple XML parser. > Perhaps use the same method to parse XML configuration, too -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2043) Incorrect and confusing trace message

by Sonia Zaldana (Jira)

[ https://issues.redhat.com/browse/ELY-2043?page=com.atlassian.jira.plugin.... ] Sonia Zaldana reassigned ELY-2043: ---------------------------------- Assignee: Sonia Zaldana > Incorrect and confusing trace message > ------------------------------------- > > Key: ELY-2043 > URL: https://issues.redhat.com/browse/ELY-2043 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Affects Versions: 1.14.0.Final > Reporter: Mike Douglass > Assignee: Sonia Zaldana > Priority: Minor > > org.wildfly.security.http.util.AggregateServerMechanismFactory > has one incorrect trace message and one which could be more helpful: > getMechanismNames has > {color:#0033b3}if {color}(log.isTraceEnabled()) { > log.tracef({color:#067d17}"No %s provided by factories in %s: %s"{color}, HttpServerAuthenticationMechanismFactory.{color:#0033b3}class{color}.getSimpleName(), getClass().getSimpleName(), Arrays.toString(factories)); > } > {color:#0033b3}return {color}names.toArray({color:#0033b3}new {color}String[names.size()]); > should that be > {color:#0033b3}if {color}(log.isTraceEnabled()) { > log.tracef({color:#067d17}"%s factories in %s: %s"{color}, HttpServerAuthenticationMechanismFactory.{color:#0033b3}class{color}.getSimpleName(), getClass().getSimpleName(), Arrays.toString(factories)); > } > {color:#0033b3}return {color}names.toArray({color:#0033b3}new {color}String[names.size()]); > ? > Same message in createAuthenticationMechanism > {color:#0033b3}if {color}(log.isTraceEnabled()) { > log.tracef({color:#067d17}"No %s provided by factories in %s: %s"{color}, HttpServerAuthenticationMechanismFactory.{color:#0033b3}class{color}.getSimpleName(), getClass().getSimpleName(), Arrays.toString(factories)); > } > It would be useful if it supplied the mechanism e.g: > {color:#0033b3}if {color}(log.isTraceEnabled()) { > log.tracef({color:#067d17}"Mechanism %s not %s provided by factories in %s: %s"{color}, mechanism, HttpServerAuthenticationMechanismFactory.{color:#0033b3}class{color}.getSimpleName(), getClass().getSimpleName(), Arrays.toString(factories)); > } > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5942) Bump Mvel version to 2.4.12+

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5942?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-5942. --------------------------------- Resolution: Done Done https://github.com/kiegroup/droolsjbpm-build-bootstrap/commit/7e0cf17fac5... > Bump Mvel version to 2.4.12+ > ---------------------------- > > Key: DROOLS-5942 > URL: https://issues.redhat.com/browse/DROOLS-5942 > Project: Drools > Issue Type: Task > Components: core engine > Affects Versions: 7.48.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Priority: Major > > Bump Mvel version to 2.4.12+ for Drools 7.49 -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14287) NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList: org/bouncycastle/util/Iterable

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-14287?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-14287: ----------------------------------------- [~rady66] What's the full stack trace? What we'd consider doing about this would depend on how Bouncycastle is being used when this problem happens. > NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList: org/bouncycastle/util/Iterable > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-14287 > URL: https://issues.redhat.com/browse/WFLY-14287 > Project: WildFly > Issue Type: Bug > Affects Versions: 21.0.1.Final > Reporter: Radoslav Ivanov > Assignee: Sudeshna Sur > Priority: Major > > Could you please add missing dependencies in Bouncycastle modules? > Problem (we got): > {code:java} > Caused by: java.lang.NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList (Module "org.bouncycastle.bcpg" version 1.66.00.0 from local module loader @1d1f7216 (finder: local module finder @423e4cbb (roots: /data/avoka/transact/manager/server/modules,/data/avoka/transact/manager/server/modules/system/layers/base))): org/bouncycastle/util/Iterable > {code} > > Solution (adding dependency from bcpg to bcprov modules solves the issue): > {code:java} > modules\system\layers\base\org\bouncycastle\bcpg\main\module.xml{code} > {code:java} > <dependencies> > <module name="org.bouncycastle.bcprov" export="true" services="export"/> > </dependencies> > {code} > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14287) NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList: org/bouncycastle/util/Iterable

by Sudeshna Sur (Jira)

[ https://issues.redhat.com/browse/WFLY-14287?page=com.atlassian.jira.plugi... ] Sudeshna Sur reassigned WFLY-14287: ----------------------------------- Assignee: Sudeshna Sur (was: Brian Stansberry) > NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList: org/bouncycastle/util/Iterable > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-14287 > URL: https://issues.redhat.com/browse/WFLY-14287 > Project: WildFly > Issue Type: Bug > Affects Versions: 21.0.1.Final > Reporter: Radoslav Ivanov > Assignee: Sudeshna Sur > Priority: Major > > Could you please add missing dependencies in Bouncycastle modules? > Problem (we got): > {code:java} > Caused by: java.lang.NoClassDefFoundError: Failed to link org/bouncycastle/openpgp/PGPEncryptedDataList (Module "org.bouncycastle.bcpg" version 1.66.00.0 from local module loader @1d1f7216 (finder: local module finder @423e4cbb (roots: /data/avoka/transact/manager/server/modules,/data/avoka/transact/manager/server/modules/system/layers/base))): org/bouncycastle/util/Iterable > {code} > > Solution (adding dependency from bcpg to bcprov modules solves the issue): > {code:java} > modules\system\layers\base\org\bouncycastle\bcpg\main\module.xml{code} > {code:java} > <dependencies> > <module name="org.bouncycastle.bcprov" export="true" services="export"/> > </dependencies> > {code} > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2069) JWT token validation uses int instead of long for the dates: exp (expiration) and nbf

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/ELY-2069?page=com.atlassian.jira.plugin.... ] Ilia Vassilev updated ELY-2069: ------------------------------- Component/s: Realms > JWT token validation uses int instead of long for the dates: exp (expiration) and nbf > ------------------------------------------------------------------------------------- > > Key: ELY-2069 > URL: https://issues.redhat.com/browse/ELY-2069 > Project: WildFly Elytron > Issue Type: Bug > Components: Realms > Affects Versions: 1.14.1.Final > Reporter: Chris Dolphy > Assignee: Ilia Vassilev > Priority: Major > > JwtValidator is reading the exp and nbf field as a Java int instead of long: > [https://github.com/wildfly-security/wildfly-elytron/blob/master/auth/real...] > This means the maximum expiration date is ~January 18, 2038. Also, with Javascript a NumericDate this would be a 64-bit value. The JWT spec also leaves open the possibility of a decimal value so that should possibly be accounted for. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-2069) JWT token validation uses int instead of long for the dates: exp (expiration) and nbf

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/ELY-2069?page=com.atlassian.jira.plugin.... ] Ilia Vassilev updated ELY-2069: ------------------------------- Affects Version/s: 1.14.1.Final Issue Type: Bug (was: Feature Request) > JWT token validation uses int instead of long for the dates: exp (expiration) and nbf > ------------------------------------------------------------------------------------- > > Key: ELY-2069 > URL: https://issues.redhat.com/browse/ELY-2069 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.14.1.Final > Reporter: Chris Dolphy > Assignee: Ilia Vassilev > Priority: Major > > JwtValidator is reading the exp and nbf field as a Java int instead of long: > [https://github.com/wildfly-security/wildfly-elytron/blob/master/auth/real...] > This means the maximum expiration date is ~January 18, 2038. Also, with Javascript a NumericDate this would be a 64-bit value. The JWT spec also leaves open the possibility of a decimal value so that should possibly be accounted for. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 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 January 2021