May 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1822) security domain with multiple realms

by Christopher Willems (Jira)

[ https://issues.jboss.org/browse/ELY-1822?page=com.atlassian.jira.plugin.s... ] Christopher Willems updated ELY-1822: ------------------------------------- Description: we have an ear file with 2 war files and one ejb jar . Purpose of the war files is to allow for different authentication mechanisms, one for jwt (BEARER_TOKEN) the other one jdbc (BASIC) . After the authentication we have a call to the ejb layer which we expect to have the principal of the authentication. Everything works fine for one realm, the default realm. The other realm will return unauthorized . With no default nothing works. The relevant information from the standalone xml is pasted below and others are attached. <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> <default-security-domain value="other"/> <application-security-domains> <application-security-domain name="war-domain" security-domain="war-domain"/> </application-security-domains> <default-missing-method-permissions-deny-access value="false"/> <subsystem xmlns="urn:wildfly:elytron:6.0" <security-domain name="war-domain" default-realm="jdbc-realm" permission-mapper="default-permission-mapper" outflow-security-domains="ApplicationDomain"> <realm name="jdbc-realm"/> <realm name="jwt-realm"/> </security-domain> <http-authentication-factory name="war-http-authentication" security-domain="war-domain" http-server-mechanism-factory="global"> <mechanism-configuration> <mechanism mechanism-name="BEARER_TOKEN"> <mechanism-realm realm-name="jwt-realm"/> </mechanism> <mechanism mechanism-name="BASIC"> <mechanism-realm realm-name="jdbc-realm"/> </mechanism> </mechanism-configuration> </http-authentication-factory> was: we have an ear file with 2 war files and one ejb jar . Purpose of the war files is to allow for different authentication mechanisms, one for jwt (BEARER_TOKEN) the other one jdbc (BASIC) . After the authentication we have a call to the ejb layer which we expect to have the principal of the authentication. Everything works fine for one realm, the default realm. The other realm will return unauthorized . With no default nothing works. The relevant information from the standalone xml is pasted below and others are attached. <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> <default-security-domain value="other"/> <application-security-domains> <application-security-domain name="war-domain" security-domain="war-domain"/> </application-security-domains> <default-missing-method-permissions-deny-access value="false"/> <log-system-exceptions value="true"/> </subsystem> <subsystem xmlns="urn:wildfly:elytron:6.0" <security-domain name="war-domain" default-realm="jdbc-realm" permission-mapper="default-permission-mapper" outflow-security-domains="ApplicationDomain"> <realm name="jdbc-realm"/> <realm name="jwt-realm"/> </security-domain> > security domain with multiple realms > ------------------------------------- > > Key: ELY-1822 > URL: https://issues.jboss.org/browse/ELY-1822 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Server > Affects Versions: 1.8.0.Final > Environment: windows mssql > Reporter: Christopher Willems > Priority: Major > Attachments: jboss-ejb3.xml, jboss-web.xml, standalone.xml > > > we have an ear file with 2 war files and one ejb jar . Purpose of the war files is to allow for different authentication mechanisms, one for jwt (BEARER_TOKEN) the other one jdbc (BASIC) . > After the authentication we have a call to the ejb layer which we expect to have the principal of the authentication. > Everything works fine for one realm, the default realm. The other realm will return unauthorized . With no default nothing works. The relevant information from the standalone xml is pasted below and others are attached. > <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> > <default-security-domain value="other"/> > <application-security-domains> > <application-security-domain name="war-domain" security-domain="war-domain"/> > </application-security-domains> > <default-missing-method-permissions-deny-access value="false"/> > > <subsystem xmlns="urn:wildfly:elytron:6.0" > <security-domain name="war-domain" default-realm="jdbc-realm" permission-mapper="default-permission-mapper" outflow-security-domains="ApplicationDomain"> > <realm name="jdbc-realm"/> > <realm name="jwt-realm"/> > </security-domain> > > <http-authentication-factory name="war-http-authentication" security-domain="war-domain" http-server-mechanism-factory="global"> > <mechanism-configuration> > <mechanism mechanism-name="BEARER_TOKEN"> > <mechanism-realm realm-name="jwt-realm"/> > </mechanism> > <mechanism mechanism-name="BASIC"> > <mechanism-realm realm-name="jdbc-realm"/> > </mechanism> > </mechanism-configuration> > </http-authentication-factory> -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-12073) Hibernate51CompatibilityTransformer.showTransformedClassFolder output should reflect all changes

by Scott Marlow (Jira)

[ https://issues.jboss.org/browse/WFLY-12073?page=com.atlassian.jira.plugin... ] Scott Marlow updated WFLY-12073: -------------------------------- Summary: Hibernate51CompatibilityTransformer.showTransformedClassFolder output should reflect all changes (was: Hibernate bytecode transformer (Hibernate51CompatibilityTransformer.showTransformedClassFolder) output should reflect all changes) > Hibernate51CompatibilityTransformer.showTransformedClassFolder output should reflect all changes > ------------------------------------------------------------------------------------------------ > > Key: WFLY-12073 > URL: https://issues.jboss.org/browse/WFLY-12073 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Affects Versions: 14.0.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Major > > Currently Hibernate51CompatibilityTransformer.showTransformedClassFolder output doesn't show all changes that have been made to Hibernate applications, this jira is for addressing that. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1822) security domain with multiple realms

by Christopher Willems (Jira)

Christopher Willems created ELY-1822: ---------------------------------------- Summary: security domain with multiple realms Key: ELY-1822 URL: https://issues.jboss.org/browse/ELY-1822 Project: WildFly Elytron Issue Type: Bug Components: Authentication Server Affects Versions: 1.8.0.Final Environment: windows mssql Reporter: Christopher Willems Attachments: jboss-ejb3.xml, jboss-web.xml, standalone.xml we have an ear file with 2 war files and one ejb jar . Purpose of the war files is to allow for different authentication mechanisms, one for jwt (BEARER_TOKEN) the other one jdbc (BASIC) . After the authentication we have a call to the ejb layer which we expect to have the principal of the authentication. Everything works fine for one realm, the default realm. The other realm will return unauthorized . With no default nothing works. The relevant information from the standalone xml is pasted below and others are attached. <subsystem xmlns="urn:jboss:domain:ejb3:5.0"> <default-security-domain value="other"/> <application-security-domains> <application-security-domain name="war-domain" security-domain="war-domain"/> </application-security-domains> <default-missing-method-permissions-deny-access value="false"/> <log-system-exceptions value="true"/> </subsystem> <subsystem xmlns="urn:wildfly:elytron:6.0" <security-domain name="war-domain" default-realm="jdbc-realm" permission-mapper="default-permission-mapper" outflow-security-domains="ApplicationDomain"> <realm name="jdbc-realm"/> <realm name="jwt-realm"/> </security-domain> -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4498) HttpServerDefinitions should reuse the Provider[] it obtains to check HTTP mechs are supported

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-4498: ---------------------------------------- Summary: HttpServerDefinitions should reuse the Provider[] it obtains to check HTTP mechs are supported Key: WFCORE-4498 URL: https://issues.jboss.org/browse/WFCORE-4498 Project: WildFly Core Issue Type: Task Components: Security Reporter: Darran Lofthouse Assignee: Darran Lofthouse -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1821) ProviderUtil should contain overloaded methods which accept arrays of Providers

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1821: ------------------------------------- Summary: ProviderUtil should contain overloaded methods which accept arrays of Providers Key: ELY-1821 URL: https://issues.jboss.org/browse/ELY-1821 Project: WildFly Elytron Issue Type: Bug Components: Utils Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.9.2.CR1 Presently the methods only accept Supplier<Provider[]> - this means even if you have an array of Provider instances it needs wrapping in a Supplier just to use these methods. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-12083) Deployment failure if an explicit bean archive contain a Pojo with @NotNull annotation

by Matěj Novotný (Jira)

[ https://issues.jboss.org/browse/WFLY-12083?page=com.atlassian.jira.plugin... ] Matěj Novotný commented on WFLY-12083: -------------------------------------- bq. So that would look as an application problem - defining non-proxyable bean but requesting a functionality (validation) that requires a proxy? Yes, that corresponds to my previous comment. bq. There's already a configuration option in Weld that causes it to print a warning (instead of failing a deployment) when a final method is being intercepted: You are right, but this exists because in some cases you can have a class that's perfectly proxyable except for one final method that becomes a blocker. Otherwise the proxy is still usable. Also note that this has roots directly in CDI spec in several forms - as a [lifecycle event method|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#process_bean_attr...] or on an [interception factory|http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#interception_fac...]. Here, the story is different. Due to constructor you simply cannot create the proxy *at all*. I would argue that ignoring the class (even with logging) does more harm then actual fail-fast exception for the simple fact that the functionality you tried to apply will be missing altogether. > Deployment failure if an explicit bean archive contain a Pojo with @NotNull annotation > -------------------------------------------------------------------------------------- > > Key: WFLY-12083 > URL: https://issues.jboss.org/browse/WFLY-12083 > Project: WildFly > Issue Type: Bug > Components: Bean Validation > Affects Versions: 17.0.0.Alpha1 > Reporter: Joerg Baesner > Assignee: Brian Stansberry > Priority: Major > Attachments: playground.zip > > > If an exlicit bean archive ({{META-INF}} contains an empty {{beans.xml}}) contain a Pojo without any Bean defining annotations and it has {{@NotNull}} annotations, the deployment of that module fails with: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.deployment.unit."playground-jar.jar".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."playground-jar.jar".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1730) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001436: Type org.jboss.playground.PlaygroundToStringUtil is not proxyable because it has a private constructor [EnhancedAnnotatedConstructorImpl] private org.jboss.playground.PlaygroundToStringUtil() - class org.jboss.playground.PlaygroundToStringUtil. > at org.jboss.weld.injection.producer.InterceptionModelInitializer.init(InterceptionModelInitializer.java:117) > at org.jboss.weld.injection.producer.BeanInjectionTarget.buildInterceptionModel(BeanInjectionTarget.java:94) > at org.jboss.weld.injection.producer.BeanInjectionTarget.initializeInterceptionModel(BeanInjectionTarget.java:89) > at org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:99) > at org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42) > at org.jboss.weld.injection.producer.InjectionTargetService.initialize(InjectionTargetService.java:63) > at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:481) > at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:86) > at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:97) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1738) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1700) > ... 6 more > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-12143) Upgrade Jackson2 to 2.9.9

by Alessio Soldano (Jira)

Alessio Soldano created WFLY-12143: -------------------------------------- Summary: Upgrade Jackson2 to 2.9.9 Key: WFLY-12143 URL: https://issues.jboss.org/browse/WFLY-12143 Project: WildFly Issue Type: Component Upgrade Reporter: Alessio Soldano Assignee: Alessio Soldano Fix For: 17.0.0.Final -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1820) SecurityProviderServerMechanismFactory should support Provider instances

by Darran Lofthouse (Jira)

Darran Lofthouse created ELY-1820: ------------------------------------- Summary: SecurityProviderServerMechanismFactory should support Provider instances Key: ELY-1820 URL: https://issues.jboss.org/browse/ELY-1820 Project: WildFly Elytron Issue Type: Bug Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.9.2.CR1 In many cases we already have the Provider instance or instances, we should not require an intermediate Supplier instance which encourages the use of a lambda just to pass these in. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-766) Kiali - Create TP11 Polarion PQI reports

by Sunil Kondkar (Jira)

[ https://issues.jboss.org/browse/SWSQE-766?page=com.atlassian.jira.plugin.... ] Sunil Kondkar edited comment on SWSQE-766 at 5/30/19 7:45 AM: -------------------------------------------------------------- 1) No Missing data in test case quality audit reports now for kiali TP11: https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... 2) Added TP11 iteration plan and linked to kiali test runs https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... 3) Test execution status report: https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... was (Author: skondkar): 1) No Missing data in test case qulaity audit reports now for kiali TP11: https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... 2) Added TP11 iteration plan and linked to kiali test runs https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... 3) Test execution status report: https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... > Kiali - Create TP11 Polarion PQI reports > ---------------------------------------- > > Key: SWSQE-766 > URL: https://issues.jboss.org/browse/SWSQE-766 > Project: Kiali QE > Issue Type: QE Task > Reporter: Sunil Kondkar > Assignee: Sunil Kondkar > Priority: Major > Labels: pqi > > Get PQI reports: > 1) Test case Quality Audit report(There are some automated test cases without automation script) > 2) PQI reports - Create TP11 test iteration, link this iteration to Kiali TP11 test runs > 3) Test case execution reports -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SWSQE-766) Kiali - Create TP11 Polarion PQI reports

by Sunil Kondkar (Jira)

[ https://issues.jboss.org/browse/SWSQE-766?page=com.atlassian.jira.plugin.... ] Sunil Kondkar commented on SWSQE-766: ------------------------------------- 1) No Missing data in test case qulaity audit reports now for kiali TP11: https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... 2) Added TP11 iteration plan and linked to kiali test runs https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... 3) Test execution status report: https://polarion.engineering.redhat.com/polarion/#/project/SwiftSunshine/... > Kiali - Create TP11 Polarion PQI reports > ---------------------------------------- > > Key: SWSQE-766 > URL: https://issues.jboss.org/browse/SWSQE-766 > Project: Kiali QE > Issue Type: QE Task > Reporter: Sunil Kondkar > Assignee: Sunil Kondkar > Priority: Major > Labels: pqi > > Get PQI reports: > 1) Test case Quality Audit report(There are some automated test cases without automation script) > 2) PQI reports - Create TP11 test iteration, link this iteration to Kiali TP11 test runs > 3) Test case execution reports -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

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 2019