July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4963) During Phase.CONFIGURE_MODULE populate SecurityMetaData with the name of any Virtual SecurityDomain

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-4963?page=com.atlassian.jira.plug... ] Darran Lofthouse updated WFCORE-4963: ------------------------------------- Fix Version/s: 13.0.0.Beta2 (was: 12.0.4.Final) > During Phase.CONFIGURE_MODULE populate SecurityMetaData with the name of any Virtual SecurityDomain > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-4963 > URL: https://issues.redhat.com/browse/WFCORE-4963 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta2 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-4962) Add a SecurityMetaData for all deployments

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-4962?page=com.atlassian.jira.plug... ] Darran Lofthouse updated WFCORE-4962: ------------------------------------- Fix Version/s: 13.0.0.Beta2 (was: 12.0.4.Final) > Add a SecurityMetaData for all deployments > ------------------------------------------ > > Key: WFCORE-4962 > URL: https://issues.redhat.com/browse/WFCORE-4962 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta2 > > > For all deployments we should associate a new class SecurityMetaData with the deployment, initially the purpose of this will be to hold the ServiceName of any Elytron SecurityDomain if one is being used. > At a later point additional security policy information can be added as we move away from the ApplicationSecurityDomain resources. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13220) A DeploymentException must be thrown if configured to use a PrivateKey

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13220?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFLY-13220: --------------------------------------- Assignee: (was: Darran Lofthouse) > A DeploymentException must be thrown if configured to use a PrivateKey > ---------------------------------------------------------------------- > > Key: WFLY-13220 > URL: https://issues.redhat.com/browse/WFLY-13220 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Affects Versions: 19.0.0.Beta3 > Reporter: Darran Lofthouse > Priority: Major > Fix For: 21.0.0.Beta1 > > > From section 9.2.0 of the Eclipse MicroProfile JWT specification, implementations are required to throw a DeploymentException when given a PrivateKey in any format. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

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 reassigned WFLY-12977: --------------------------------------- Assignee: (was: Darran Lofthouse) > 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 > 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

1
0
0 / 0

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

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12951?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFLY-12951: --------------------------------------- Assignee: (was: Darran Lofthouse) > JWT signed by 1024 bit long key is rejected > ------------------------------------------- > > Key: WFLY-12951 > URL: https://issues.redhat.com/browse/WFLY-12951 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: 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

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 reassigned WFLY-12978: --------------------------------------- Assignee: (was: Darran Lofthouse) > 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 > 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

1
0
0 / 0

[JBoss JIRA] (WFLY-13164) When "corrupted" public key is supplied to server, user is not informed

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13164?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFLY-13164: --------------------------------------- Assignee: (was: Darran Lofthouse) > When "corrupted" public key is supplied to server, user is not informed > ----------------------------------------------------------------------- > > Key: WFLY-13164 > URL: https://issues.redhat.com/browse/WFLY-13164 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Affects Versions: 19.0.0.Beta2, 20.0.0.Beta1 > Reporter: Jan Kasik > Priority: Critical > Attachments: CorruptedKeyTest.war > > > When corrupted public key (a valid key cannot be extracted from the string value) is supplied to JWT verifier, user is not informed since there is no error message in log and clients receives 401 status code in response instead of an error code of 500. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

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

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12975?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFLY-12975: --------------------------------------- Assignee: (was: Darran Lofthouse) > 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 (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5439) DMN 1.3 clean up range function

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5439?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5439: ----------------------------------- Description: Move temporal/range/interval functions into basic profile since they are DMNv1.3 To be checked, but these: “overlapped by” “overlapped before by” “overlapped after by” are to be removed was: To be checked, but these: “overlapped by” “overlapped before by” “overlapped after by” are to be removed > DMN 1.3 clean up range function > ------------------------------- > > Key: DROOLS-5439 > URL: https://issues.redhat.com/browse/DROOLS-5439 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > Move temporal/range/interval functions into basic profile since they are DMNv1.3 > To be checked, but these: > “overlapped by” > “overlapped before by” > “overlapped after by” > are to be removed -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13655) LOG INFO level message if the Hibernate second level cache is enabled

by Scott Marlow (Jira)

Scott Marlow created WFLY-13655: ----------------------------------- Summary: LOG INFO level message if the Hibernate second level cache is enabled Key: WFLY-13655 URL: https://issues.redhat.com/browse/WFLY-13655 Project: WildFly Issue Type: Enhancement Components: JPA / Hibernate Reporter: Scott Marlow Assignee: Scott Marlow Fix For: 21.0.0.Beta1 The idea is to log at INFO level if the Hibernate second level cache is to be enabled by org.jboss.as.jpa.hibernate5.service.WildFlyCustomRegionFactoryInitiator. Note that org.hibernate.cache.internal.RegionFactoryInitiator#resolveRegionFactory still needs to be able to create the second level cache. Update WildFlyCustomRegionFactoryInitiator#resolveRegionFactory to log at INFO level the "WildFlyCustomRegionFactoryInitiator#resolveRegionFactory will create second level cache %s" message. This message will only be logged during application deployment. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

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 July 2020