January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12733) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12733?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-12733: ----------------------------------------- [~cfang] Sorry, your question from November got buried. We should avoid making accessing the management layer from application code a requirement for a feature. An application user is not an administrative user and would not be trusted. To work around that the application would likely try to do things such that the application code is privileged, and by doing that they would be opening up a security hole. > EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment > -------------------------------------------------------------------------------------- > > Key: WFLY-12733 > URL: https://issues.redhat.com/browse/WFLY-12733 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Rhuan Rocha > Assignee: Cheng Fang > Priority: Major > > The EJB Timer has a way to persist timers in a database using datasources. It is described [here|https://docs.jboss.org/author/display/WFLY10/EJB3+Clustered+Database...]. The database-data-store has an attribute called refresh-interval that define a time in milliseconds to refresh the timers reading the timers from database. Look this sample of configuration. > > {code:java} > <data-stores> > <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/> > <database-data-store name="clustered-store" datasource-jndi-name="java:/jdbc/MyDataSource" partition="timer" refresh-interval="60000" allow-execution="true"/> > </data-stores> > {code} > The RFE is to Wildfly provide a way to force the refresh programmatically. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12978) Current implementation of MP-JWT doesn't require claims which should be required

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12978?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-293 to WFLY-12978: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12978 (was: WFWIP-293) Component/s: MP JWT (was: MP JWT) > Current implementation of MP-JWT doesn't require claims which should be required > -------------------------------------------------------------------------------- > > Key: WFLY-12978 > URL: https://issues.redhat.com/browse/WFLY-12978 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > Chapter 4.1 of MP-JWT 1.1 recommends minimal set of JWT claims which should be required. > Current implementation doesn't check for following claims and returns 200/OK if they are missing: > * {{upn}} > * {{jti}} > * {{groups}} > * {{iat}} > * {{sub}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12979) JWT signed by 1024 bit long key is rejected

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12979?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-288 to WFLY-12979: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12979 (was: WFWIP-288) Component/s: MP JWT (was: MP JWT) > JWT signed by 1024 bit long key is rejected > ------------------------------------------- > > Key: WFLY-12979 > URL: https://issues.redhat.com/browse/WFLY-12979 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > According to MP-JWT 1.1 specification, 1024 and 2048 bit key sizes must be supported. Though when there is JWT signed by 1024 bit long key presented to the server, it is rejected and client receives "Unauthorized" (code 401) message. > See chapter 9.2. Supported Public Key Formats: > {quote} > Support for RSA Public Keys of 1024 or 2048 bits in length is required. Other key sizes are allowed, but should be considered vendor-specific. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12980) Full reload is needed after microprofile-jwt-smallrye subsystem removal

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12980?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-298 to WFLY-12980: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12980 (was: WFWIP-298) Component/s: MP JWT (was: MP JWT) > Full reload is needed after microprofile-jwt-smallrye subsystem removal > ----------------------------------------------------------------------- > > Key: WFLY-12980 > URL: https://issues.redhat.com/browse/WFLY-12980 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > When user is removing MP subsystem, full reload is required. This is partly a benefit because it provides a fast fail solution for deployments which requires classes from this subsystem. On the other hand, reload might not be feasible for user under in their current conditions. This is why it has to be reduced as much as possible. > Is there other way to provide fast fail without requiring full reload? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-297) Base64 encoded JWKS from a file fails to resolve

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-297?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFWIP-297: ----------------------------------- Priority: Critical (was: Blocker) > Base64 encoded JWKS from a file fails to resolve > ------------------------------------------------ > > Key: WFWIP-297 > URL: https://issues.redhat.com/browse/WFWIP-297 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Critical > > JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log. > This breaks specification compatibility because according to MP-JWT 1.1 which specifies in section 9.2.3: > {quote} > The JWKS may be supplied in plain JSON or Base64 URL encoded JSON format. > {quote} > {code} > 12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks > ... > 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key... > 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format > at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205) > ... > Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=] > at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271) > at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433) > at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88) > ... 40 more > Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks > at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101) > at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213) > ... 42 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12976) Base64 encoded JWKS from a file fails to resolve

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12976?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-297 to WFLY-12976: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12976 (was: WFWIP-297) Component/s: MP JWT (was: MP JWT) > Base64 encoded JWKS from a file fails to resolve > ------------------------------------------------ > > Key: WFLY-12976 > URL: https://issues.redhat.com/browse/WFLY-12976 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Critical > > JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log. > This breaks specification compatibility because according to MP-JWT 1.1 which specifies in section 9.2.3: > {quote} > The JWKS may be supplied in plain JSON or Base64 URL encoded JSON format. > {quote} > {code} > 12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks > ... > 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key... > 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format > at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205) > ... > Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=] > at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271) > at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433) > at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88) > ... 40 more > Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks > at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101) > at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213) > ... 42 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-280) Warnings propagated from io.smallrye.jwt.auth.* don't have assigned ID

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-280?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFWIP-280: ----------------------------------- Priority: Major (was: Critical) > Warnings propagated from io.smallrye.jwt.auth.* don't have assigned ID > ---------------------------------------------------------------------- > > Key: WFWIP-280 > URL: https://issues.redhat.com/browse/WFWIP-280 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > Warning which are propagated to log from io.smallrye.jwt.auth package don't have assigned logging ID. > Example: > {code} > 11:52:50,705 WARN [io.smallrye.jwt.auth.mechanism.JWTHttpAuthenticationMechanism] (default task-1) Unable to validate bearer token: Failed to verify token: io.smallrye.jwt.auth.principal.ParseException: Failed to verify token > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12977) Warnings propagated from io.smallrye.jwt.auth.* don't have assigned ID

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12977?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-280 to WFLY-12977: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12977 (was: WFWIP-280) Component/s: MP JWT (was: MP JWT) > Warnings propagated from io.smallrye.jwt.auth.* don't have assigned ID > ---------------------------------------------------------------------- > > Key: WFLY-12977 > URL: https://issues.redhat.com/browse/WFLY-12977 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > Warning which are propagated to log from io.smallrye.jwt.auth package don't have assigned logging ID. > Example: > {code} > 11:52:50,705 WARN [io.smallrye.jwt.auth.mechanism.JWTHttpAuthenticationMechanism] (default task-1) Unable to validate bearer token: Failed to verify token: io.smallrye.jwt.auth.principal.ParseException: Failed to verify token > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-293) Current implementation of MP-JWT doesn't require claims which should be required

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-293?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFWIP-293: ----------------------------------- Priority: Major (was: Critical) > Current implementation of MP-JWT doesn't require claims which should be required > -------------------------------------------------------------------------------- > > Key: WFWIP-293 > URL: https://issues.redhat.com/browse/WFWIP-293 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > Chapter 4.1 of MP-JWT 1.1 recommends minimal set of JWT claims which should be required. > Current implementation doesn't check for following claims and returns 200/OK if they are missing: > * {{upn}} > * {{jti}} > * {{groups}} > * {{iat}} > * {{sub}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFWIP-294: ----------------------------------- Priority: Critical (was: Blocker) > JWT is rejected if signature matching public key is not first in JWK set > ------------------------------------------------------------------------ > > Key: WFWIP-294 > URL: https://issues.redhat.com/browse/WFWIP-294 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > 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 (v7.13.8#713008)

6 years, 5 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 2020