[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ]
Jan Kasik updated WFWIP-294:
----------------------------
Description:
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}
was:
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}
> 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: Blocker
> 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, 6 months
[JBoss JIRA] (DROOLS-4925) forall pattern with date constraint fail to match
by Matteo Casalino (Jira)
Matteo Casalino created DROOLS-4925:
---------------------------------------
Summary: forall pattern with date constraint fail to match
Key: DROOLS-4925
URL: https://issues.redhat.com/browse/DROOLS-4925
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.31.0.Final, 7.30.0.Final, 7.29.0.Final
Reporter: Matteo Casalino
Assignee: Mario Fusco
Attachments: forall-date-constraint.tgz, network.png
As of Drools 7.29.0.Final, {{forall}} patterns containing equality constraints on dates won't match as expected.
For instance, given the following drl
{noformat}
declare Fact
d : java.util.Date
end
rule "forall with date"
when
forall(Fact(d == "01-Jan-2020"))
then
end
{noformat}
and the following working memory:
{noformat}
Fact( d=Wed Jan 01 00:00:00 CET 2020 )
Fact( d=Wed Jan 01 00:00:00 CET 2020 )
Fact( d=Wed Jan 01 00:00:00 CET 2020 )
{noformat}
Drools <= 7.28.0.Final will fire 1 rule, whereas Drools >= 7.29.0.Final will fire 0 rules.
This is probably due to the fact that the rewriting implemented in [DROOLS-4632] fails to negate the constraint on the date, as visible in the attached picture of the network.
I am wondering whether there would be an equivalent problem with any constraint on dates (e.g., >=, <=, ...)?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ]
Jan Kasik updated WFWIP-294:
----------------------------
Description:
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}
was:
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.
> 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: Blocker
> 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFWIP-297) Base64 encoded JWKS from a file fails to resolve
by Jan Kasik (Jira)
[ https://issues.redhat.com/browse/WFWIP-297?page=com.atlassian.jira.plugin... ]
Jan Kasik updated WFWIP-297:
----------------------------
Description:
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}
was:
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.
{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}
> 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: Blocker
>
> 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, 6 months