February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ] Eric Wittmann commented on WFLY-4304: ------------------------------------- I haven't specifically tested this, but the assumption is that this same problem would occur without Keycloak in the loop (just using standard BASIC authentication with JAAS). The response from the KC mailing list: "Its really a problem with wildfly, not keycloak. Keycloak just implements the auth SPI of wildfly." Which seems reasonable. :) > Servlet authentication kicked off when *not* a part of any security-constraint > ------------------------------------------------------------------------------ > > Key: WFLY-4304 > URL: https://issues.jboss.org/browse/WFLY-4304 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Reporter: Brett Meyer > Assignee: Jason Greene > Priority: Critical > > Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself. > A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom: > If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ] Eric Wittmann commented on WFLY-4304: ------------------------------------- I ran into this issue in apiman a couple months ago, and worked around it by splitting my app into two separate WARs. It would have been much better to not have to do that, though. :) Here is my original post to the KC mailing list: ---- In apiman I have a bit of an edge case that currently isn't working as I was hoping (running in wildfly 8.2 - not tested on any other platform). The issue is that I have a WAR with two sub-contexts: /api - JAX-RS endpoints to configure the API Gateway /gateway - the API Gateway (reverse proxy) I wanted /api to be protected by keycloak, but for /gateway to be unprotected. My web.xml looks like this: {code} <security-constraint> <web-resource-collection> <web-resource-name>apiman-gateway</web-resource-name> <url-pattern>/api/*</url-pattern> </web-resource-collection> <auth-constraint> <role-name>apiadmin</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> <realm-name>apiman</realm-name> </login-config> <security-role> <role-name>apiadmin</role-name> </security-role> {code} It all works great until I send a request to /gateway/* that includes an "Authorization" http header. If I do that, the adapter tries to authenticate with those credentials and fails with a 401 if they don't match (which they don't). I realize this is an odd case, but I did expect that if the web.xml specified that only /api/* were protected then other paths would simply pass through any Authorization headers. That may be an incorrect expectation - not sure what the servlet spec requires in this case. The use-case here is that the Gateway servlet itself supports all sorts of authentication policies (BASIC auth, certificates, OAuth, SAML, etc etc). It all depends on the configuration of the API being called (the gateway proxies requests to back-end API implementations). > Servlet authentication kicked off when *not* a part of any security-constraint > ------------------------------------------------------------------------------ > > Key: WFLY-4304 > URL: https://issues.jboss.org/browse/WFLY-4304 > Project: WildFly > Issue Type: Bug > Affects Versions: 8.2.0.Final > Reporter: Brett Meyer > Assignee: Jason Greene > Priority: Critical > > Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself. > A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom: > If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint

by Brett Meyer (JIRA)

Brett Meyer created WFLY-4304: --------------------------------- Summary: Servlet authentication kicked off when *not* a part of any security-constraint Key: WFLY-4304 URL: https://issues.jboss.org/browse/WFLY-4304 Project: WildFly Issue Type: Bug Affects Versions: 8.2.0.Final Reporter: Brett Meyer Assignee: Jason Greene Priority: Critical Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself. A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom: If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4303) Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-4303?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-4303: ----------------------------------- Component/s: EJB > Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-4303 > URL: https://issues.jboss.org/browse/WFLY-4303 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > > Applications need to have a jboss-ejb-client.xml configuration to use connections to other WildFly servers. > The remote-outbound-connection allow expressions, i.e. for user-name. > But if a cluster come into play the related <cluster> element inside the jboss-ejb-client.xml must have the same username and this can be only hardcoded. > So the jboss-ejb-client.xml parsing should allow expressions for > outbound-connection-ref, username, security-realm etc. > See https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-ma... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4303) Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-4303: -------------------------------------- Summary: Allow expressions in jboss-ejb-client.xml if configuration jboss-descriptor-property-replacement=true Key: WFLY-4303 URL: https://issues.jboss.org/browse/WFLY-4303 Project: WildFly Issue Type: Feature Request Reporter: Wolf-Dieter Fink Assignee: Jason Greene Applications need to have a jboss-ejb-client.xml configuration to use connections to other WildFly servers. The remote-outbound-connection allow expressions, i.e. for user-name. But if a cluster come into play the related <cluster> element inside the jboss-ejb-client.xml must have the same username and this can be only hardcoded. So the jboss-ejb-client.xml parsing should allow expressions for outbound-connection-ref, username, security-realm etc. See https://github.com/wildfly/quickstart/blob/master/ejb-multi-server/app-ma... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4295) warn about _ds.xml deplyments are deprecated

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4295?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4295: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1187026|https://bugzilla.redhat.com/show_bug.cgi?id=1187026] from POST to MODIFIED > warn about _ds.xml deplyments are deprecated > -------------------------------------------- > > Key: WFLY-4295 > URL: https://issues.jboss.org/browse/WFLY-4295 > Project: WildFly > Issue Type: Feature Request > Components: JCA > Reporter: Stefano Maestri > Assignee: Stefano Maestri > > _ds.xml deployement will no more supported in next vesions of WF. log a warning during deployment to warn users about that. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4302) Missing dependency on org.wildfly.clustering.infinispan.spi in org.jboss.as.security module

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-4302: ---------------------------------- Summary: Missing dependency on org.wildfly.clustering.infinispan.spi in org.jboss.as.security module Key: WFLY-4302 URL: https://issues.jboss.org/browse/WFLY-4302 Project: WildFly Issue Type: Bug Components: Clustering, Security Affects Versions: 9.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 9.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4299) transaction subsystem node-identifier can not resolve expression

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4299?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-4299: ----------------------------------- i think this is related to WFCORE-499 > transaction subsystem node-identifier can not resolve expression > ---------------------------------------------------------------- > > Key: WFLY-4299 > URL: https://issues.jboss.org/browse/WFLY-4299 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 9.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Brian Stansberry > Priority: Critical > Labels: configuration, configuration_management, domain > > If the transaction subsystem should use an expression as node-identifier this will not work in domain mode: > ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 36) WFLYCTL0013: Operation ("add") failed - address: ([("subsystem" => "transactions")]) - failure description: "WFLYCTL0211: Cannot resolve expression '${txNodeIdentifier}'" > This was possible in former builds with the same configuration. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-694) accumulate with sliding window and other LHS condition

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-694?page=com.atlassian.jira.plugin... ] Matteo Mortari commented on DROOLS-694: --------------------------------------- Ciao Mario, thank you very much for the feedback; I'm glad to see this reproducer, although not fully "reduced", was helpful to locate a bug. ps: thanks also for the hint but in this case within the application I discovered this issue, it's very common to need (or prefer) no-loop, so I guess I just "generalized" the case where I spotted this rule failing when using phreak. > accumulate with sliding window and other LHS condition > ------------------------------------------------------ > > Key: DROOLS-694 > URL: https://issues.jboss.org/browse/DROOLS-694 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR4 > Environment: fail with PHREAK, work correctly as expected with RETEOO > Reporter: Matteo Mortari > Assignee: Mario Fusco > Fix For: 6.2.0.Final > > Attachments: 20150121.accumulate-window-counter.zip > > > With reference to attached reproducer. > Assuming the following KB, where to goal is to keep a {{Counter}} fact for the amount of {{Measurement}} events received in the last hour. > {code:java} > declare Measurement > @role(event) > end > rule "Init Counter last 1h" > agenda-group "USERSPACE" > salience 1 > no-loop > when > not Counter( name == "Counter last 1h" ) > then > Counter c = new Counter("Counter last 1h", 0); > insert(c); > System.out.println("RHS Init Counter last 1h " + c); > end > rule "Update Counter last 1h" > agenda-group "USERSPACE" > no-loop > when > accumulate( $token : Measurement() over window:time( 1h ) ; > $val : count($token) > ) > $cv1 : Counter( name == "Counter last 1h", value != $val.doubleValue() ) > then > int count = $val.intValue(); > $cv1.setValue(count); > update($cv1); > System.out.println("RHS Update Counter last 1h : "+$cv1); > end > {code} > The following Unit test shall have the effect in the end to obtain value 2.0 in the {{Counter}} object, as I've inserted 2 {{MEasurement}} within the last hour and within two minutes > {code:java} > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "220")); > fire(session); > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "221")); > fire(session); > LOG.info("Final checks"); > Counter counter = (Counter) session.getObjects(counterFilter).iterator().next(); // I'm taking a shortcut as for this reproducer I know there is only 1 Counter in WM > assertEquals("I've inserted 2 Measurement within the hour ", 2, counter.getValue(), 0); > {code} > However this works only with ReteOO and the test FAILS with Phreak. > Can you kindly advise, please? > Thank you > MM -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-694) accumulate with sliding window and other LHS condition

by Matteo Mortari (JIRA)

[ https://issues.jboss.org/browse/DROOLS-694?page=com.atlassian.jira.plugin... ] Matteo Mortari edited comment on DROOLS-694 at 2/2/15 8:32 AM: --------------------------------------------------------------- Ciao Mario, thank you very much for the feedback; I'm glad to see this reproducer, although not fully "reduced", was helpful to locate a bug. ps: thanks also for the hint but in this case within the application I discovered this issue, it's very common to need (or prefer) no-loop, so I just "generalized" the case where I spotted this rule failing when using phreak. was (Author: tari_manga): Ciao Mario, thank you very much for the feedback; I'm glad to see this reproducer, although not fully "reduced", was helpful to locate a bug. ps: thanks also for the hint but in this case within the application I discovered this issue, it's very common to need (or prefer) no-loop, so I guess I just "generalized" the case where I spotted this rule failing when using phreak. > accumulate with sliding window and other LHS condition > ------------------------------------------------------ > > Key: DROOLS-694 > URL: https://issues.jboss.org/browse/DROOLS-694 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final, 6.2.0.CR4 > Environment: fail with PHREAK, work correctly as expected with RETEOO > Reporter: Matteo Mortari > Assignee: Mario Fusco > Fix For: 6.2.0.Final > > Attachments: 20150121.accumulate-window-counter.zip > > > With reference to attached reproducer. > Assuming the following KB, where to goal is to keep a {{Counter}} fact for the amount of {{Measurement}} events received in the last hour. > {code:java} > declare Measurement > @role(event) > end > rule "Init Counter last 1h" > agenda-group "USERSPACE" > salience 1 > no-loop > when > not Counter( name == "Counter last 1h" ) > then > Counter c = new Counter("Counter last 1h", 0); > insert(c); > System.out.println("RHS Init Counter last 1h " + c); > end > rule "Update Counter last 1h" > agenda-group "USERSPACE" > no-loop > when > accumulate( $token : Measurement() over window:time( 1h ) ; > $val : count($token) > ) > $cv1 : Counter( name == "Counter last 1h", value != $val.doubleValue() ) > then > int count = $val.intValue(); > $cv1.setValue(count); > update($cv1); > System.out.println("RHS Update Counter last 1h : "+$cv1); > end > {code} > The following Unit test shall have the effect in the end to obtain value 2.0 in the {{Counter}} object, as I've inserted 2 {{MEasurement}} within the last hour and within two minutes > {code:java} > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "220")); > fire(session); > advance(clock, 1, TimeUnit.MINUTES); > insert(session, new Measurement("voltage", "221")); > fire(session); > LOG.info("Final checks"); > Counter counter = (Counter) session.getObjects(counterFilter).iterator().next(); // I'm taking a shortcut as for this reproducer I know there is only 1 Counter in WM > assertEquals("I've inserted 2 Measurement within the hour ", 2, counter.getValue(), 0); > {code} > However this works only with ReteOO and the test FAILS with Phreak. > Can you kindly advise, please? > Thank you > MM -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 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 February 2015