November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12794) Elytron/JACC: Inconsistent EjbMethodPermissions

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/WFLY-12794?page=com.atlassian.jira.plugin... ] Farah Juma reassigned WFLY-12794: --------------------------------- Assignee: (was: Farah Juma) > Elytron/JACC: Inconsistent EjbMethodPermissions > ----------------------------------------------- > > Key: WFLY-12794 > URL: https://issues.jboss.org/browse/WFLY-12794 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 18.0.0.Final > Reporter: Ulf Brosziewski > Priority: Major > Attachments: quickstart-ejb-sec.diff > > > When JACC is enabled in an elytron application domain, calling a secured ejb method that has an array parameter causes an EjbAccessException. > The reason for the failure is that the EjbMethodPermissions created by the EjbJaccConfigurator and the JaccInterceptor do not agree in the format of the type names for method parameters. According to the JACC specification and API documentation, names for array types should have the "canonical" form: component-type + "[]". The permission objects built by the JaccInterceptor conform to that, but the EjbJaccConfigurator builds them with type names obtained from a "MethodIdentifier", and these names have the internal format as returned by Class.getName(). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3376) Modules may create loggers on a deployments log context

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFCORE-3376?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3376: ---------------------------------- Priority: Critical (was: Major) > Modules may create loggers on a deployments log context > ------------------------------------------------------- > > Key: WFCORE-3376 > URL: https://issues.jboss.org/browse/WFCORE-3376 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 11.0.0.Beta3 > > > Currently WildFly uses a {{ClassLoaderLogContextSelector}} to determine the log context to use when creating loggers. If a deployment has it's own log context, via logging-profile or per-deployment logging, and a dependency on a module, that module may create loggers on the deployments log context. This is due to the fact the the call stack is walked until it finds a log context associated with a class loader. > What is needed is a way to short-circuit once a non-logging API class loader is found and determine if there is an associated log context with the callers class loader. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3376) Modules may create loggers on a deployments log context

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFCORE-3376?page=com.atlassian.jira.plugi... ] James Perkins updated WFCORE-3376: ---------------------------------- Fix Version/s: 11.0.0.Beta3 > Modules may create loggers on a deployments log context > ------------------------------------------------------- > > Key: WFCORE-3376 > URL: https://issues.jboss.org/browse/WFCORE-3376 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 11.0.0.Beta3 > > > Currently WildFly uses a {{ClassLoaderLogContextSelector}} to determine the log context to use when creating loggers. If a deployment has it's own log context, via logging-profile or per-deployment logging, and a dependency on a module, that module may create loggers on the deployments log context. This is due to the fact the the call stack is walked until it finds a log context associated with a class loader. > What is needed is a way to short-circuit once a non-logging API class loader is found and determine if there is an associated log context with the callers class loader. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12794) Elytron/JACC: Inconsistent EjbMethodPermissions

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12794?page=com.atlassian.jira.plugin... ] Cheng Fang commented on WFLY-12794: ----------------------------------- [~u_bross1] thanks for reporting and creating the quickstart reproducer. [~fjuma] I'm re-assigning to you to evaluate since it seems more about security. Feel free to assign it back if ejb change is needed. > Elytron/JACC: Inconsistent EjbMethodPermissions > ----------------------------------------------- > > Key: WFLY-12794 > URL: https://issues.jboss.org/browse/WFLY-12794 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 18.0.0.Final > Reporter: Ulf Brosziewski > Assignee: Cheng Fang > Priority: Major > Attachments: quickstart-ejb-sec.diff > > > When JACC is enabled in an elytron application domain, calling a secured ejb method that has an array parameter causes an EjbAccessException. > The reason for the failure is that the EjbMethodPermissions created by the EjbJaccConfigurator and the JaccInterceptor do not agree in the format of the type names for method parameters. According to the JACC specification and API documentation, names for array types should have the "canonical" form: component-type + "[]". The permission objects built by the JaccInterceptor conform to that, but the EjbJaccConfigurator builds them with type names obtained from a "MethodIdentifier", and these names have the internal format as returned by Class.getName(). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12794) Elytron/JACC: Inconsistent EjbMethodPermissions

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12794?page=com.atlassian.jira.plugin... ] Cheng Fang reassigned WFLY-12794: --------------------------------- Assignee: Farah Juma (was: Cheng Fang) > Elytron/JACC: Inconsistent EjbMethodPermissions > ----------------------------------------------- > > Key: WFLY-12794 > URL: https://issues.jboss.org/browse/WFLY-12794 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 18.0.0.Final > Reporter: Ulf Brosziewski > Assignee: Farah Juma > Priority: Major > Attachments: quickstart-ejb-sec.diff > > > When JACC is enabled in an elytron application domain, calling a secured ejb method that has an array parameter causes an EjbAccessException. > The reason for the failure is that the EjbMethodPermissions created by the EjbJaccConfigurator and the JaccInterceptor do not agree in the format of the type names for method parameters. According to the JACC specification and API documentation, names for array types should have the "canonical" form: component-type + "[]". The permission objects built by the JaccInterceptor conform to that, but the EjbJaccConfigurator builds them with type names obtained from a "MethodIdentifier", and these names have the internal format as returned by Class.getName(). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4549) [DMN Designer] Data Types - Update release notes

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-4549?page=com.atlassian.jira.plugi... ] Guilherme Gomes updated DROOLS-4549: ------------------------------------ Sprint: 2019 Week 44-46 (from Okt 28) > [DMN Designer] Data Types - Update release notes > ------------------------------------------------ > > Key: DROOLS-4549 > URL: https://issues.jboss.org/browse/DROOLS-4549 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > Update release notes with changes related to the epic. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4762) [DMN Designer] Data Types - Tab index is not working on Data Type rows

by Guilherme Gomes (Jira)

Guilherme Gomes created DROOLS-4762: --------------------------------------- Summary: [DMN Designer] Data Types - Tab index is not working on Data Type rows Key: DROOLS-4762 URL: https://issues.jboss.org/browse/DROOLS-4762 Project: Drools Issue Type: Bug Components: DMN Editor Reporter: Guilherme Gomes Assignee: Guilherme Gomes There are a couple of keyboard problems related to tab index: - When adding or editing a row, you can't tab the focus onto the save/cancel buttons - After selecting from the dropdown, the focus jumps back to the text field for some reason - The focus ring is not shown on the list toggle -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4549) [DMN Designer] Data Types - Update release notes

by Guilherme Gomes (Jira)

[ https://issues.jboss.org/browse/DROOLS-4549?page=com.atlassian.jira.plugi... ] Guilherme Gomes reassigned DROOLS-4549: --------------------------------------- Assignee: Guilherme Gomes (was: Daniel José dos Santos) > [DMN Designer] Data Types - Update release notes > ------------------------------------------------ > > Key: DROOLS-4549 > URL: https://issues.jboss.org/browse/DROOLS-4549 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > > Update release notes with changes related to the epic. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-257) SSO layer cannot be properly used with SSO template

by Jean Francois Denise (Jira)

[ https://issues.jboss.org/browse/WFWIP-257?page=com.atlassian.jira.plugin.... ] Jean Francois Denise updated WFWIP-257: --------------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-cekit-modules/pull/132 > SSO layer cannot be properly used with SSO template > ---------------------------------------------------- > > Key: WFWIP-257 > URL: https://issues.jboss.org/browse/WFWIP-257 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Michal Jurc > Assignee: Jean Francois Denise > Priority: Blocker > > Currently available OpenShift templates for EAP CD are not able to properly configure EAP server with SSO client, resulting in the following errors: > {code}15:55:01,843 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 38) MSC000001: Failed to start service jboss.deployment.unit."app-profile-jsp.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."app-profile-jsp.war".undertow-deployment: java.lang.RuntimeException: java.lang.IllegalStateException: The required mechanism 'KEYCLOAK' is not available in mechanisms [BASIC, CLIENT_CERT, DIGEST, FORM] from the HttpAuthenticationFactory. > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81) > at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) > at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) > at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377) > at java.base/java.lang.Thread.run(Thread.java:834) > at org.jboss.threads@2.3.3.Final-redhat-00001//org.jboss.threads.JBossThread.run(JBossThread.java:485) > Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: The required mechanism 'KEYCLOAK' is not available in mechanisms [BASIC, CLIENT_CERT, DIGEST, FORM] from the HttpAuthenticationFactory. > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:254) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:96) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78) > ... 8 more > Caused by: java.lang.IllegalStateException: The required mechanism 'KEYCLOAK' is not available in mechanisms [BASIC, CLIENT_CERT, DIGEST, FORM] from the HttpAuthenticationFactory. > at org.wildfly.security.elytron-web.undertow-server-servlet@1.6.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.AuthenticationManager.initialSecurityHandler(AuthenticationManager.java:153) > at org.wildfly.security.elytron-web.undertow-server-servlet@1.6.0.Final-redhat-00001//org.wildfly.elytron.web.undertow.server.servlet.AuthenticationManager.lambda$configure$2(AuthenticationManager.java:98) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:442) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:121) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:224) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:186) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at org.wildfly.extension.undertow@7.3.0.CD18-redhat-00002//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504) > at io.undertow.servlet@2.0.26.SP3-redhat-00001//io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:252) > ... 10 more{code} > I am marking this issue as blocker since the template is currently the only documented way for EAP to use SSO client on OpenShift. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12794) Elytron/JACC: Inconsistent EjbMethodPermissions

by Ulf Brosziewski (Jira)

Ulf Brosziewski created WFLY-12794: -------------------------------------- Summary: Elytron/JACC: Inconsistent EjbMethodPermissions Key: WFLY-12794 URL: https://issues.jboss.org/browse/WFLY-12794 Project: WildFly Issue Type: Bug Components: EJB, Security Affects Versions: 18.0.0.Final Reporter: Ulf Brosziewski Assignee: Cheng Fang Attachments: quickstart-ejb-sec.diff When JACC is enabled in an elytron application domain, calling a secured ejb method that has an array parameter causes an EjbAccessException. The reason for the failure is that the EjbMethodPermissions created by the EjbJaccConfigurator and the JaccInterceptor do not agree in the format of the type names for method parameters. According to the JACC specification and API documentation, names for array types should have the "canonical" form: component-type + "[]". The permission objects built by the JaccInterceptor conform to that, but the EjbJaccConfigurator builds them with type names obtained from a "MethodIdentifier", and these names have the internal format as returned by Class.getName(). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 8 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 November 2019