September 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8568) Elytron outflow-security-domains doesn't work for Servlet-to-EJB calls

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-8568?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-8568: -------------------------------------- Assignee: Darran Lofthouse (was: David Lloyd) > Elytron outflow-security-domains doesn't work for Servlet-to-EJB calls > ---------------------------------------------------------------------- > > Key: WFLY-8568 > URL: https://issues.jboss.org/browse/WFLY-8568 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow) > Reporter: Josef Cacek > Assignee: Darran Lofthouse > > Security context propagation with using Elytron {{outflow-security-domains}} attribute in security domain doesn't work for Servlet-to-EJB calls. > This could also be a test configuration issue, but as there is not yet documentation covering this area, I can't guess what could be wrong in the scenario. > 1. I have 2 similar web applications with servlets and EJBs: > * the `secured-webapp` is mapped to `web-tests` security domain > * the `second` application is mapped to `second-domain` security domain > 2. Undertow and EJB subsystems maps the application domains `web-tests` and `second-domain` to Elytron domains with the same name. > 3. trust between the domains is defined in following way: > {code} > /subsystem=elytron/security-domain=second-domain:write-attribute(name=outflow-security-domains,value=[web-tests]) > /subsystem=elytron/security-domain=second-domain:write-attribute(name=trusted-security-domains, value=[web-tests]) > /subsystem=elytron/security-domain=web-tests:write-attribute(name=trusted-security-domains, value=[second-domain]) > {code} > 4. the test itself calls servlet from the `second` web application and it calls protected EJB from the `secured-webapp`. > The EJB call fails with EJBAccessException > {noformat} > 14:30:04,631 ERROR [org.jboss.as.ejb3.invocation] (default task-3) WFLYEJB0034: EJB Invocation failed on component HelloBean for method public abstract java.lang.String org.jboss.test.ejb.Hello.sayHello(): javax.ejb.EJBAccessException: WFLYEJB0364: Invocation on method: public abstract java.lang.String org.jboss.test.ejb.Hello.sayHello() of bean: HelloBean is not allowed > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1743) NPE in RuleNEtworkEvaluator after incremental compilation

by Anton Giertli (JIRA)

Anton Giertli created DROOLS-1743: ------------------------------------- Summary: NPE in RuleNEtworkEvaluator after incremental compilation Key: DROOLS-1743 URL: https://issues.jboss.org/browse/DROOLS-1743 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.3.0.Final Reporter: Anton Giertli Assignee: Mario Fusco Attachments: drools-path-memory-reproducer.zip Having the following drl files : {code:drl} package org.hightea.a import org.drools.compiler.Message import org.drools.compiler.FirstClass rule "RG_1" when $event : Message() FirstClass(item1 == $event.message1) then System.out.println("RG_1"); end {code} and {code:drl} package org.hightea.b import org.drools.compiler.Message import org.drools.compiler.SecondClass rule "RG_2" when $event: Message() SecondClass(item1 == $event.message1) then System.out.println("RG_2"); end {code} We create a module containing the two packages in two drl files and insert a `SecondClass` fact in the WM. Then we want to incrementally update to a new module containing only the second DRL. At first fireAllrules after update, we encounter a NPE in RuleNetwork evaluator (a Segment memory is not defined in the path memory) {code:java} java.lang.NullPointerException at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:114) at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87) at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34) at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067) at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014) at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006) at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295) at org.hightea.IncrementalRemoveRuleTest.testNpeInRuleNetworkEvaluator(IncrementalRemoveRuleTest.java:66) {code} Note that we don't encounter this issue when the packages names are the same, or if we exchange the order of drl file name in the first module. A reproducer is attached with its source code at [https://github.com/hightea/drools-reproducer/tree/path-memory-issue|https...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-262) The equivalent of wrap and unwrap for HTTP authentication mechanisms

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-262?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-262: --------------------------------- Parent: (was: ELY-174) Issue Type: Feature Request (was: Sub-task) > The equivalent of wrap and unwrap for HTTP authentication mechanisms > -------------------------------------------------------------------- > > Key: ELY-262 > URL: https://issues.jboss.org/browse/ELY-262 > Project: WildFly Elytron > Issue Type: Feature Request > Components: HTTP > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta5 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-155) Condense Message IDs

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-155?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-155. ---------------------------------- Fix Version/s: (was: 1.2.0.Beta5) Resolution: Rejected The .Final releases of WildFly Elytron have been created to messages IDs must now be preserved for compatibility. > Condense Message IDs > -------------------- > > Key: ELY-155 > URL: https://issues.jboss.org/browse/ELY-155 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Priority: Blocker > > This is a task to complete at the point of tagging, condense the message IDs to close any gaps in the numbering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2197) ability to upload content from secure web server

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2197?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFCORE-2197: ------------------------------------------ Hadn't seen this before but +1 to using the Elytron authentication context, the authentication context can match based on the URL to identify the security policy to use. > ability to upload content from secure web server > ------------------------------------------------ > > Key: WFCORE-2197 > URL: https://issues.jboss.org/browse/WFCORE-2197 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management, Security > Reporter: Ian Kent > > We use the upload-deployment-url operation of wildfly management API to add content to content repository (app war) from remote web server (nexus artifact repository manager). As the nexus web server is secure so the wildfly app server needs to pass credentials to nexus when downloading war to wildfly content repository for deployment. Is there a way to encode the nexus username and password in url parameter or add a additional parameters for username and password. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8872) Regression, kerberos + fallback ejb legacy security solution GSSAPI SASL mechanism not called

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-8872?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-8872. ------------------------------------ Fix Version/s: 11.0.0.Final Resolution: Done > Regression, kerberos + fallback ejb legacy security solution GSSAPI SASL mechanism not called > --------------------------------------------------------------------------------------------- > > Key: WFLY-8872 > URL: https://issues.jboss.org/browse/WFLY-8872 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Fix For: 11.0.0.Final > > > Given EJB secured with kerberos + fallback, using legacy security solution [1] > When I try to authenticate using correct Kerberos ticket and wrong username/password. > Then PLAIN SASL mechanism fails and GSSAPI is not performed. > Same scenario works correctly in > * 7.0 > * 7.1 Elytron way > I have attached server.log for: > * no username password provided > * wrong username password provided > [1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8506) Elytron SPNEGO authentication in deployment over HTTPS, EAP requests for HTTPS/hostname ticket.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-8506?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved WFLY-8506. ------------------------------------ Assignee: Darran Lofthouse Resolution: Rejected > Elytron SPNEGO authentication in deployment over HTTPS, EAP requests for HTTPS/hostname ticket. > ----------------------------------------------------------------------------------------------- > > Key: WFLY-8506 > URL: https://issues.jboss.org/browse/WFLY-8506 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Darran Lofthouse > Labels: eap71_beta_candidate, kerberos, spnego, tls > > Accessing deployment secured by Kerberos + TLS causes EAP requests from KDC ticket HTTPS/hostname. > See network dump krb_https_deployment.pcap in attachement, where TGS-REQ for HTTPS/localhost is captured. > If I configure HTTPS/hostname in KDC and kerberos credential factory to use principal HTTPS/hostname it works correctly. But I still believe it is bug: > * At least it is not consistent with legacy management interface behaviour (JBEAP-8572). > * found 2 sources describing protocol and service does not match 1:1 and for https protocol HTTP/hostname SPN should be used [1][2] > [1] https://sites.google.com/a/chromium.org/dev/developers/design-documents/h... > [2] https://support.microsoft.com/en-us/help/929650/how-to-use-spns-when-you-... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3317) Some deployment-scanner unit tests from wf-core fail on IBM JDK intermittently

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3317?page=com.atlassian.jira.plugi... ] Marek Kopecký updated WFCORE-3317: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2845, https://github.com/jbossas/wildfly-core-eap/pull/433, https://github.com/wildfly/wildfly-core/pull/2846 (was: https://github.com/wildfly/wildfly-core/pull/2845, https://github.com/jbossas/wildfly-core-eap/pull/433) > Some deployment-scanner unit tests from wf-core fail on IBM JDK intermittently > ------------------------------------------------------------------------------ > > Key: WFCORE-3317 > URL: https://issues.jboss.org/browse/WFCORE-3317 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Test Suite > Reporter: Marek Kopecký > Assignee: Marek Kopecký > > *Description of problem:* > Some deployment-scanner unit tests from wf-core fail on IBM JDK intermittently. > This is testsuite issue only. > Affected test cases: > * ShutdownFileSystemDeploymentServiceUnitTestCase > * FileSystemDeploymentServiceUnitTestCase > Executors.newSingleThreadExecutor() method returns ExecutorService with finalize method, that shutdown thread executor. Currently ExecutorService instance is not referenced, so IBM JDK calls finalize method. Finalize method calls shutdown method and size of thread-pool is decreased to 0 before lockDone.get(...) is called. > *How reproducible:* > 0.6% - intermittently on IBM JDK > *Actual results - ShutdownFileSystemDeploymentServiceUnitTestCase:* > StackTrace: > {noformat} > java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@67503391 rejected from java.util.concurrent.ThreadPoolExecutor@ae603d77[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2058) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:834) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1380) > at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145) > at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:692) > at org.jboss.as.server.deployment.scanner.ShutdownFileSystemDeploymentServiceUnitTestCase.testUncleanShutdown(ShutdownFileSystemDeploymentServiceUnitTestCase.java:156) > {noformat} > *Actual results - FileSystemDeploymentServiceUnitTestCase:* > StackTrace: > {noformat} > java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@9408464a rejected from java.util.concurrent.ThreadPoolExecutor@fa7bfba[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2058) > at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:834) > at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1380) > at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145) > at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:692) > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentServiceUnitTestCase.testUncleanShutdown(FileSystemDeploymentServiceUnitTestCase.java:1755) > {noformat} > *Expected results:* > No errors -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently

by Nuno Godinho de Matos (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ] Nuno Godinho de Matos commented on WFCORE-3210: ----------------------------------------------- Many thanks, the web console should be straight forward. The Jboss CLI should be inferable. I will take a look into the suggested alternatives and see what suits best. Kindest regards. > Wildfly module isolation not working consistently > ------------------------------------------------- > > Key: WFCORE-3210 > URL: https://issues.jboss.org/browse/WFCORE-3210 > Project: WildFly Core > Issue Type: Bug > Components: Logging, Modules > Affects Versions: 2.2.0.Final > Reporter: Nuno Godinho de Matos > > There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems. > An example of this phenomena is given on the wildfly forum thread: > https://developer.jboss.org/thread/275839 > In this example, we have the logging subsystem setup to use a custome handler. > The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module. > What we see in this example is that an application gets from wildfly mixed behavior. > Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly. > But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module. > And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same. > This is not an isolated issue. > There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away. > This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable. > It should not be that the application server some time starts successfully and others not. > Booting wildfly should always result in the same outcode. > Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper. > In the case of thread: > https://developer.jboss.org/thread/275839 > Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen. > Many thanks. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-176) Delay expression resolution in the configuration API

by James Perkins (JIRA)

James Perkins created LOGMGR-176: ------------------------------------ Summary: Delay expression resolution in the configuration API Key: LOGMGR-176 URL: https://issues.jboss.org/browse/LOGMGR-176 Project: JBoss Log Manager Issue Type: Enhancement Affects Versions: 2.0.7.Final Reporter: James Perkins Priority: Optional In some cases it may be desired to delay the expansion of expressions when setting the value through the configuration API. Currently the expressions is resolved when the property is set on the target object. This can be too soon for things like formatters which should probably be more dynamic and resolve the expression during the format. This might not make sense in all cases and will cause in decrease in performance. A good example of there this could be useful is a {{StructuredFormatter}} where the meta-data value contains an expression. This is not a requirement, but may be a nice to have. The other option would be to reconfigure the object if a property was changed. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2017