May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13319) Wildfly 19 MP-JWT & EJB Integration

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13319?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13319: ------------------------------------ Component/s: Test Suite > Wildfly 19 MP-JWT & EJB Integration > ----------------------------------- > > Key: WFLY-13319 > URL: https://issues.redhat.com/browse/WFLY-13319 > Project: WildFly > Issue Type: Bug > Components: MP JWT, Test Suite > Affects Versions: 19.0.0.Final > Reporter: Radu Cimpean > Assignee: Darran Lofthouse > Priority: Major > Fix For: 20.0.0.Beta1 > > Attachments: server-cli.txt, web.xml > > > ===Previous configuration & situation=== > As written https://groups.google.com/forum/#!topic/wildfly/L1BxATschCU, > We were running wildfly 18 and used jwt for securing the application. We did this via a series of cli commands (see server-cli.txt) to configure the server, as well as referencing the created domains in the web.xml. > Under jboss-web.xml we are referencing the "ejb-domain" created in the CLIs. The web.xml (see attachments) protects the resource wit the role referenced in the CLIs (role present in the token) > All our jax-rs resources are annotated with @Stateless and are calling EJBs which in turn are @Statless and declare allowed roles. > ===Current situation=== > We've upgraded to wildfly 19 in hopes of using microprofile jwt. To do this, we've annotated the Application class with > @LoginConfig(authMethod = "MP-JWT", realmName = "MP-JWT-REALM"), removed the login-config from the web.xml, and removed the security-domain from jboss-web.xml (since otherwise I would receive an error: ELY01148: A SecurityDomain has already been associated with the specified ClassLoader"). > After also removing the security-constraint tag from the web.xml I was able to get to the resource and noticed that the JWTToken was properly injected (all claims and entries are there), and the SecurityContext injected in the resource also contained the jwt specific values. From what I can tell, in the context of the jax-rs classloader, I am authenticated. > I would, however, always receive a "Invocation on method... is not allowed" the second the resource would try calling a bean, even if the role matched. Upon checking the logs, and what the injected SessionContext contained, I noticed the principal was anonymous and had no roles allowed. > I therefore believe that the credentials are somehow not being properly passed. > Is there a documented way of properly integrating jax-rs&ejb with microprofile jwt? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13319) Wildfly 19 MP-JWT & EJB Integration

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13319?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13319: ------------------------------------ Fix Version/s: 20.0.0.Beta1 > Wildfly 19 MP-JWT & EJB Integration > ----------------------------------- > > Key: WFLY-13319 > URL: https://issues.redhat.com/browse/WFLY-13319 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Affects Versions: 19.0.0.Final > Reporter: Radu Cimpean > Assignee: Darran Lofthouse > Priority: Major > Fix For: 20.0.0.Beta1 > > Attachments: server-cli.txt, web.xml > > > ===Previous configuration & situation=== > As written https://groups.google.com/forum/#!topic/wildfly/L1BxATschCU, > We were running wildfly 18 and used jwt for securing the application. We did this via a series of cli commands (see server-cli.txt) to configure the server, as well as referencing the created domains in the web.xml. > Under jboss-web.xml we are referencing the "ejb-domain" created in the CLIs. The web.xml (see attachments) protects the resource wit the role referenced in the CLIs (role present in the token) > All our jax-rs resources are annotated with @Stateless and are calling EJBs which in turn are @Statless and declare allowed roles. > ===Current situation=== > We've upgraded to wildfly 19 in hopes of using microprofile jwt. To do this, we've annotated the Application class with > @LoginConfig(authMethod = "MP-JWT", realmName = "MP-JWT-REALM"), removed the login-config from the web.xml, and removed the security-domain from jboss-web.xml (since otherwise I would receive an error: ELY01148: A SecurityDomain has already been associated with the specified ClassLoader"). > After also removing the security-constraint tag from the web.xml I was able to get to the resource and noticed that the JWTToken was properly injected (all claims and entries are there), and the SecurityContext injected in the resource also contained the jwt specific values. From what I can tell, in the context of the jax-rs classloader, I am authenticated. > I would, however, always receive a "Invocation on method... is not allowed" the second the resource would try calling a bean, even if the role matched. Upon checking the logs, and what the injected SessionContext contained, I noticed the principal was anonymous and had no roles allowed. > I therefore believe that the credentials are somehow not being properly passed. > Is there a documented way of properly integrating jax-rs&ejb with microprofile jwt? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-13319) Wildfly 19 MP-JWT & EJB Integration

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13319?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13319: ------------------------------------ Security: (was: Security Issue) > Wildfly 19 MP-JWT & EJB Integration > ----------------------------------- > > Key: WFLY-13319 > URL: https://issues.redhat.com/browse/WFLY-13319 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Affects Versions: 19.0.0.Final > Reporter: Radu Cimpean > Assignee: Darran Lofthouse > Priority: Major > Attachments: server-cli.txt, web.xml > > > ===Previous configuration & situation=== > As written https://groups.google.com/forum/#!topic/wildfly/L1BxATschCU, > We were running wildfly 18 and used jwt for securing the application. We did this via a series of cli commands (see server-cli.txt) to configure the server, as well as referencing the created domains in the web.xml. > Under jboss-web.xml we are referencing the "ejb-domain" created in the CLIs. The web.xml (see attachments) protects the resource wit the role referenced in the CLIs (role present in the token) > All our jax-rs resources are annotated with @Stateless and are calling EJBs which in turn are @Statless and declare allowed roles. > ===Current situation=== > We've upgraded to wildfly 19 in hopes of using microprofile jwt. To do this, we've annotated the Application class with > @LoginConfig(authMethod = "MP-JWT", realmName = "MP-JWT-REALM"), removed the login-config from the web.xml, and removed the security-domain from jboss-web.xml (since otherwise I would receive an error: ELY01148: A SecurityDomain has already been associated with the specified ClassLoader"). > After also removing the security-constraint tag from the web.xml I was able to get to the resource and noticed that the JWTToken was properly injected (all claims and entries are there), and the SecurityContext injected in the resource also contained the jwt specific values. From what I can tell, in the context of the jax-rs classloader, I am authenticated. > I would, however, always receive a "Invocation on method... is not allowed" the second the resource would try calling a bean, even if the role matched. Upon checking the logs, and what the injected SessionContext contained, I noticed the principal was anonymous and had no roles allowed. > I therefore believe that the credentials are somehow not being properly passed. > Is there a documented way of properly integrating jax-rs&ejb with microprofile jwt? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-4989) JACCAuthzPropagationTestCase failures are intermittent on CI

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-4989?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFLY-4989: ---------------------------------------- Within the next couple of WildFly releases we are going to need to start looking at our approach within the testsuite and start to look at making Elytron backed testing the default with legacy security being split out into separate runs, this may mean that for now issues such as this may be better held until we undertake that activity as that will trigger a load of CI runs where we can see the current issues in the testsuite. > JACCAuthzPropagationTestCase failures are intermittent on CI > ------------------------------------------------------------ > > Key: WFLY-4989 > URL: https://issues.redhat.com/browse/WFLY-4989 > Project: WildFly > Issue Type: Bug > Components: Security, Test Suite > Reporter: James Perkins > Priority: Major > Labels: testsuite_stability > > http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF_PullReque... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-311) OpenShift XP image doubled its size to 2GB compared to 7.3.0.GA 1GB

by Martin Choma (Jira)

[ https://issues.redhat.com/browse/WFWIP-311?page=com.atlassian.jira.plugin... ] Martin Choma closed WFWIP-311. ------------------------------ Resolution: Explained > OpenShift XP image doubled its size to 2GB compared to 7.3.0.GA 1GB > ------------------------------------------------------------------- > > Key: WFWIP-311 > URL: https://issues.redhat.com/browse/WFWIP-311 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Major > Attachments: Screenshot from 2020-04-23 06-56-37.png, Screenshot from 2020-05-05 10-00-15.png > > > I have started to play with OpenShift XP image {{docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel7:EAP7-1484}} and I have noticed it is nearly 2GB big. Used to be 0.92 GB for 7.3.0.GA or CD19. > Also strange is there is much more layers compared to several layers in previous releases > From dive output it seems every bash command result in own layer. Dive is reporting 624MB of waste space. > !Screenshot from 2020-04-23 06-56-37.png|thumbnail! > I am setting priority just to major because it is not official image yet. But if this will be the case of official image as well, I will raise priority. In OCP 4 there is no image/layer cache so image must be "downloaded" for each build from registry into pod. > [1] > {code} > docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel... 1.93 GB > registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-eap73-openjdk11... 920 MB > registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-tech-preview-ea... 921 MB > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-311) OpenShift XP image doubled its size to 2GB compared to 7.3.0.GA 1GB

by Martin Choma (Jira)

[ https://issues.redhat.com/browse/WFWIP-311?page=com.atlassian.jira.plugin... ] Martin Choma edited comment on WFWIP-311 at 5/5/20 4:03 AM: ------------------------------------------------------------ I confirm with productized image we are back to normal. Size is little bit smaller. There are 3 layers in image. {code} registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-eap-xp1-openjdk... 887 MB {code} !Screenshot from 2020-05-05 10-00-15.png|thumbnail! was (Author: mchoma): I confirm with productized image we are back to normal. Size is little bit smaller. There are 4 layers in image. {code} registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-eap-xp1-openjdk... 887 MB {code} !Screenshot from 2020-05-05 10-00-15.png|thumbnail! > OpenShift XP image doubled its size to 2GB compared to 7.3.0.GA 1GB > ------------------------------------------------------------------- > > Key: WFWIP-311 > URL: https://issues.redhat.com/browse/WFWIP-311 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Major > Attachments: Screenshot from 2020-04-23 06-56-37.png, Screenshot from 2020-05-05 10-00-15.png > > > I have started to play with OpenShift XP image {{docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel7:EAP7-1484}} and I have noticed it is nearly 2GB big. Used to be 0.92 GB for 7.3.0.GA or CD19. > Also strange is there is much more layers compared to several layers in previous releases > From dive output it seems every bash command result in own layer. Dive is reporting 624MB of waste space. > !Screenshot from 2020-04-23 06-56-37.png|thumbnail! > I am setting priority just to major because it is not official image yet. But if this will be the case of official image as well, I will raise priority. In OCP 4 there is no image/layer cache so image must be "downloaded" for each build from registry into pod. > [1] > {code} > docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel... 1.93 GB > registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-eap73-openjdk11... 920 MB > registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-tech-preview-ea... 921 MB > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-5132) DMN Drools TCK runner updates

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5132?page=com.atlassian.jira.plug... ] Matteo Mortari updated DROOLS-5132: ----------------------------------- Sprint: 2020 Week 19-21 (from May 4) > DMN Drools TCK runner updates > ----------------------------- > > Key: DROOLS-5132 > URL: https://issues.redhat.com/browse/DROOLS-5132 > Project: Drools > Issue Type: Task > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > > Activities on upstream DMN TCK is on hold as no meetings are being held -> no PRs merged on DMN TCK repo. > Hence this PR is pending: https://github.com/dmn-tck/tck/pull/360 > In that branch/PR, I am aligning with the original TCK intention that "errorResult" flag is an hint, but cannot be enforced, over the runners. > Example, in case > * the result from a DMN expression evaluation is null, > * the TCK expect a null, > * IFF TCK did not flagged as "errorResult", we no longer just fail simply because the Drools DMN engine reported an error (which was not indicated by the TCK test). > https://github.com/dmn-tck/tck/pull/360/files#diff-49ce6a21913fba22bc06e7... > Before, if the Drools DMN engine raised an error, but the TCK did not indicated as "errorResult" we were reporting a failure, even if the actual value was consistent with the expected one! > Now is aligned as explained. > Naturally, I've in parallel raised already PR to TCK to fix the test and to provide the proper "errorResult" hint. (https://github.com/dmn-tck/tck/pull/359) > Once the DMN-TCK-upstream PR for the Drools TCK runner is merged, the commit https://github.com/kiegroup/drools/commit/ca70199cf5edccf5261f153dde3296c... can be reverted. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-311) OpenShift XP image doubled its size to 2GB compared to 7.3.0.GA 1GB

by Martin Choma (Jira)

[ https://issues.redhat.com/browse/WFWIP-311?page=com.atlassian.jira.plugin... ] Martin Choma commented on WFWIP-311: ------------------------------------ I confirm with productized image we are back to normal. Size is little bit smaller. There are 4 layers in image. {code} registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-eap-xp1-openjdk... 887 MB {code} !Screenshot from 2020-05-05 10-00-15.png|thumbnail! > OpenShift XP image doubled its size to 2GB compared to 7.3.0.GA 1GB > ------------------------------------------------------------------- > > Key: WFWIP-311 > URL: https://issues.redhat.com/browse/WFWIP-311 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Major > Attachments: Screenshot from 2020-04-23 06-56-37.png, Screenshot from 2020-05-05 10-00-15.png > > > I have started to play with OpenShift XP image {{docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel7:EAP7-1484}} and I have noticed it is nearly 2GB big. Used to be 0.92 GB for 7.3.0.GA or CD19. > Also strange is there is much more layers compared to several layers in previous releases > From dive output it seems every bash command result in own layer. Dive is reporting 624MB of waste space. > !Screenshot from 2020-04-23 06-56-37.png|thumbnail! > I am setting priority just to major because it is not official image yet. But if this will be the case of official image as well, I will raise priority. In OCP 4 there is no image/layer cache so image must be "downloaded" for each build from registry into pod. > [1] > {code} > docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel... 1.93 GB > registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-eap73-openjdk11... 920 MB > registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-tech-preview-ea... 921 MB > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFWIP-311) OpenShift XP image doubled its size to 2GB compared to 7.3.0.GA 1GB

by Martin Choma (Jira)

[ https://issues.redhat.com/browse/WFWIP-311?page=com.atlassian.jira.plugin... ] Martin Choma updated WFWIP-311: ------------------------------- Attachment: Screenshot from 2020-05-05 10-00-15.png > OpenShift XP image doubled its size to 2GB compared to 7.3.0.GA 1GB > ------------------------------------------------------------------- > > Key: WFWIP-311 > URL: https://issues.redhat.com/browse/WFWIP-311 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Choma > Assignee: Jeff Mesnil > Priority: Major > Attachments: Screenshot from 2020-04-23 06-56-37.png, Screenshot from 2020-05-05 10-00-15.png > > > I have started to play with OpenShift XP image {{docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel7:EAP7-1484}} and I have noticed it is nearly 2GB big. Used to be 0.92 GB for 7.3.0.GA or CD19. > Also strange is there is much more layers compared to several layers in previous releases > From dive output it seems every bash command result in own layer. Dive is reporting 624MB of waste space. > !Screenshot from 2020-04-23 06-56-37.png|thumbnail! > I am setting priority just to major because it is not official image yet. But if this will be the case of official image as well, I will raise priority. In OCP 4 there is no image/layer cache so image must be "downloaded" for each build from registry into pod. > [1] > {code} > docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel... 1.93 GB > registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-eap73-openjdk11... 920 MB > registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-tech-preview-ea... 921 MB > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (WFLY-11013) Hash encoding Exception when using @DatabaseIdentityStoreDefinition

by Moulali Shikalwadi (Jira)

[ https://issues.redhat.com/browse/WFLY-11013?page=com.atlassian.jira.plugi... ] Moulali Shikalwadi commented on WFLY-11013: ------------------------------------------- [~f_marchioni], Could you please let me know what is the update on this? > Hash encoding Exception when using @DatabaseIdentityStoreDefinition > ------------------------------------------------------------------- > > Key: WFLY-11013 > URL: https://issues.redhat.com/browse/WFLY-11013 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 14.0.0.Final > Environment: WildFly 14. Generic Linux. JDK 8/9 > Reporter: Francesco Marchioni > Priority: Major > Attachments: javaee8-secure-servlet.zip > > > When deploying one application using @DatabaseIdentityStoreDefinition, upon successful login, the following exception is thrown > {code:java} > java.lang.IllegalArgumentException: Bad hash encoding > at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl$EncodedPasswordHash.decode(Pbkdf2PasswordHashImpl.java:209) > at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl$EncodedPasswordHash.<init>(Pbkdf2PasswordHashImpl.java:191) > at org.glassfish.soteria.identitystores.hash.Pbkdf2PasswordHashImpl.verify(Pbkdf2PasswordHashImpl.java:147) > at org.glassfish.soteria.identitystores.DatabaseIdentityStore.validate(DatabaseIdentityStore.java:121) > at org.glassfish.soteria.identitystores.DatabaseIdentityStore.validate(DatabaseIdentityStore.java:101) > at org.jboss.weldx.security.enterprise.identitystore.IdentityStore$635317201$Proxy$_$$_WeldClientProxy.validate(Unknown Source) > at org.glassfish.soteria.cdi.DefaultIdentityStoreHandler.validate(DefaultIdentityStoreHandler.java:97) > {code} -- 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 May 2020