February 2013 - esb-issues - Jboss List Archives

[JBoss JIRA] (JBESB-3903) Provide multiple security configurations for HTTPProvider

by Carvel Baus (JIRA)

Carvel Baus created JBESB-3903: ---------------------------------- Summary: Provide multiple security configurations for HTTPProvider Key: JBESB-3903 URL: https://issues.jboss.org/browse/JBESB-3903 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Deployment, Security, Web Services Affects Versions: 4.11 Environment: SOA-P 5.3 Reporter: Carvel Baus When an http-provider is used with a SOAPProxy action, a web service can be proxied into multiple endpoints with different URLs using multiple http-bus tags. One advantage to doing this is having endpoints contain different security contracts (i.e. one is PKI, another uses Username token, etc.) In the current configuration, this is not possible because the security configuration is shared by all endpoints - there is no way to configure per endpoint security. The work around to this is to use multiple esb deployments, one per security configuration needed. It would be nice and convenient to have security configured on a per-bus basis, instead of per war, so the multiple endpoints can feed a single action chain configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3902) Restore esbToBpmVars as a command line option

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3902?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3902: ------------------------------------------------ Jiri Pechanec <jpechane(a)redhat.com> changed the Status of [bug 902888|https://bugzilla.redhat.com/show_bug.cgi?id=902888] from ON_QA to VERIFIED > Restore esbToBpmVars as a command line option > --------------------------------------------- > > Key: JBESB-3902 > URL: https://issues.jboss.org/browse/JBESB-3902 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Process flow > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.11 CP2 > > > Customer noticed we no longer allow 'default' values in esbToBpmVars. They are moving from SOA-P 4.x to 5.x and require this functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3902) Restore esbToBpmVars as a command line option

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3902?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3902: ------------------------------------------------ Jiri Pechanec <jpechane(a)redhat.com> made a comment on [bug 902888|https://bugzilla.redhat.com/show_bug.cgi?id=902888] Verified in CR1 - jbossesb-propertis switch works as advertised and the variable in question is stored in ReplyTo EPR > Restore esbToBpmVars as a command line option > --------------------------------------------- > > Key: JBESB-3902 > URL: https://issues.jboss.org/browse/JBESB-3902 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Process flow > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.11 CP2 > > > Customer noticed we no longer allow 'default' values in esbToBpmVars. They are moving from SOA-P 4.x to 5.x and require this functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3902) Restore esbToBpmVars as a command line option

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3902?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3902: ------------------------------------------------ tcunning(a)redhat.com made a comment on [bug 902888|https://bugzilla.redhat.com/show_bug.cgi?id=902888] Talked to Jiri about this on Friday - the WARN is related to another issue which came out of the same case. getLegacyEsbToBpmParams() is called within Configuration itself, and then stored in a KeyValuePair - which is checked. I see the defaults added in the debugger when I set the property. > Restore esbToBpmVars as a command line option > --------------------------------------------- > > Key: JBESB-3902 > URL: https://issues.jboss.org/browse/JBESB-3902 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Process flow > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.11 CP2 > > > Customer noticed we no longer allow 'default' values in esbToBpmVars. They are moving from SOA-P 4.x to 5.x and require this functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3902) Restore esbToBpmVars as a command line option

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3902?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3902: ------------------------------------------------ tcunning(a)redhat.com changed the Status of [bug 902888|https://bugzilla.redhat.com/show_bug.cgi?id=902888] from ASSIGNED to ON_QA > Restore esbToBpmVars as a command line option > --------------------------------------------- > > Key: JBESB-3902 > URL: https://issues.jboss.org/browse/JBESB-3902 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Process flow > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.11 CP2 > > > Customer noticed we no longer allow 'default' values in esbToBpmVars. They are moving from SOA-P 4.x to 5.x and require this functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3902) Restore esbToBpmVars as a command line option

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3902?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3902: ------------------------------------------------ Jiri Pechanec <jpechane(a)redhat.com> changed the Status of [bug 902888|https://bugzilla.redhat.com/show_bug.cgi?id=902888] from ON_QA to ASSIGNED > Restore esbToBpmVars as a command line option > --------------------------------------------- > > Key: JBESB-3902 > URL: https://issues.jboss.org/browse/JBESB-3902 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Process flow > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.11 CP2 > > > Customer noticed we no longer allow 'default' values in esbToBpmVars. They are moving from SOA-P 4.x to 5.x and require this functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3902) Restore esbToBpmVars as a command line option

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3902?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3902: ------------------------------------------------ Jiri Pechanec <jpechane(a)redhat.com> made a comment on [bug 902888|https://bugzilla.redhat.com/show_bug.cgi?id=902888] SOA-P now log WARN for unitialized variable as mentioned in support case. Unfortuantely the behaviours is same regardless of <properties name="bpm"> <property name="org.jboss.soa.esb.legacy.bpmvars" value="true"/> </properties> setting. It means that it deviates from 5.3 behaviour and breaks backward compatibility. I grepped the code for a call of Configuration.getLegacyEsbToBpmParams and there is none. > Restore esbToBpmVars as a command line option > --------------------------------------------- > > Key: JBESB-3902 > URL: https://issues.jboss.org/browse/JBESB-3902 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Process flow > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.11 CP2 > > > Customer noticed we no longer allow 'default' values in esbToBpmVars. They are moving from SOA-P 4.x to 5.x and require this functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3902) Restore esbToBpmVars as a command line option

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3902?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3902: ------------------------------------------------ Julian Coleman <jcoleman(a)redhat.com> changed the Status of [bug 902888|https://bugzilla.redhat.com/show_bug.cgi?id=902888] from MODIFIED to ON_QA > Restore esbToBpmVars as a command line option > --------------------------------------------- > > Key: JBESB-3902 > URL: https://issues.jboss.org/browse/JBESB-3902 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Process flow > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.11 CP2 > > > Customer noticed we no longer allow 'default' values in esbToBpmVars. They are moving from SOA-P 4.x to 5.x and require this functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3898) EBWS on CXF fails to handle WS-Security header with soap:mustUnderstand="1"

by Magesh Bojan (JIRA)

[ https://issues.jboss.org/browse/JBESB-3898?page=com.atlassian.jira.plugin... ] Magesh Bojan resolved JBESB-3898. --------------------------------- Fix Version/s: 4.12 Resolution: Done Trunk At revision: 38280 > EBWS on CXF fails to handle WS-Security header with soap:mustUnderstand="1" > --------------------------------------------------------------------------- > > Key: JBESB-3898 > URL: https://issues.jboss.org/browse/JBESB-3898 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 4.11 > Environment: SOA-P installed with JBoss WS CXF stack > Reporter: Tadayoshi Sato > Assignee: Magesh Bojan > Fix For: 4.12 > > > On JBoss WS CXF, EBWS (ESB-based web service) throws SOAP Faults when handling SOAP requests with the WS-Security UsernameToken header which is declared with {{soap:mustUnderstand="1"}}, even though {{<security moduleName="..."/>}} (I believe this enables WS-Security for EBWS) is set up for the EBWS in {{jboss-esb.xml}}. > Note that I confirmed JBoss WS CXF itself can handle WS-Security with {{soap:mustUnderstand="1"}} if {{jbossws-cxf.xml}} is properly set up. So, I suspect the problem would be in EBWS. > I used the following SOAP request: > {code} > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:say="http://www.jboss.org/sayHi" xmlns:cust="http://www.jboss.org/custom-request" xmlns:sub="http://www.jboss.org/custom-subtype" xmlns:t="http://www.jboss.org/type2"> > <soap:Header> > <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"> > <wsse:UsernameToken> > <wsse:Username>kermit</wsse:Username> > <wsse:Password>thefrog</wsse:Password> > </wsse:UsernameToken> > </wsse:Security> > </soap:Header> > <soap:Body> > ... > </soap:Body> > </soap:Envelope> > {code} > And got the following SOAP Fault: > {code} > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Header> > <wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd"/> > </soap:Header> > <soap:Body> > <soap:Fault> > <faultcode>soap:MustUnderstand</faultcode> > <faultstring>MustUnderstand headers: [{http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd}Security] are not understood.</faultstring> > </soap:Fault> > </soap:Body> > </soap:Envelope> > {code} > I also got the following error stacktrace: > {code} > 17:04:09,572 WARNING [PhaseInterceptorChain] Interceptor for {http://soa.jboss.org/ESBServiceSample}HelloWorldPubServiceService#{http://soa.jboss.org/ESBServiceSample}HelloWorldPubServiceOp has thrown exception, unwinding now > org.apache.cxf.binding.soap.SoapFault: MustUnderstand headers: [{http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd}Security] are not understood. > at org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:225) > at org.apache.cxf.binding.soap.interceptor.MustUnderstandInterceptor$UltimateReceiverMustUnderstandInterceptor.handleMessage(MustUnderstandInterceptor.java:199) > at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:243) > at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:111) > at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:99) > at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:431) > at org.jboss.wsf.stack.cxf.ServletControllerExt.invoke(ServletControllerExt.java:173) > at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:61) > at org.jboss.wsf.stack.cxf.CXFServletExt.invoke(CXFServletExt.java:185) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) > at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183) > at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95) > at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) > at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74) > at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829) > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:599) > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451) > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3902) Restore esbToBpmVars as a command line option

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3902?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3902: ------------------------------------------------ tcunning(a)redhat.com changed the Status of [bug 902888|https://bugzilla.redhat.com/show_bug.cgi?id=902888] from ASSIGNED to MODIFIED > Restore esbToBpmVars as a command line option > --------------------------------------------- > > Key: JBESB-3902 > URL: https://issues.jboss.org/browse/JBESB-3902 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Process flow > Affects Versions: 4.11 CP2 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.11 CP2 > > > Customer noticed we no longer allow 'default' values in esbToBpmVars. They are moving from SOA-P 4.x to 5.x and require this functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 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

esb-issues February 2013