[jira] [Created] (CXF-7948) Upgrade to asm 7
Grzegorz Grzybek created CXF-7948:
-
Summary: Upgrade to asm 7
Key: CXF-7948
URL: https://issues.apache.org/jira/browse/CXF-7948
Project: CXF
Issue Type: Wish
Reporter: Grzegorz Grzybek
I just run all tests in 3.2.x-fixes branch with this patch:
{noformat}
diff --git a/parent/pom.xml b/parent/pom.xml
index 234bcbaa0f..47a3885db0 100644
--- a/parent/pom.xml
+++ b/parent/pom.xml
@@ -47,8 +47,8 @@
org.ow2.asm
asm
-5.2
-[3.0,6.3)
+7.0
+[3.0,8)
{noformat}
all tests pass.
background: I've prepared _simultaneous_ release of pax-web, pax-transx,
pax-jms, pax-jdbc, pax-cdi, preparing for aligned release of karaf 4.2.3.
In pax-web I've upgraded to ASM7, so now, pax-web ship/install ASM7 bundles.
Karaf itself switched to ASM7 some time ago, but the reason why (so far) CXF
tests worked was that pax-web used in Karaf was installing ASM6 libraries.
CXF contains (very) wide range for ASM import: {{[3, 6.3)}} and knowing the
good history of backward compatibility of ASM, I think it's worth increasing
the range for ASM in CXF.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7948) Upgrade to asm 7
[
https://issues.apache.org/jira/browse/CXF-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745886#comment-16745886
]
Freeman Fang commented on CXF-7948:
---
yup, let's do it, to align with other stuff in Karaf container
> Upgrade to asm 7
>
>
> Key: CXF-7948
> URL: https://issues.apache.org/jira/browse/CXF-7948
> Project: CXF
> Issue Type: Wish
>Reporter: Grzegorz Grzybek
>Assignee: Freeman Fang
>Priority: Major
>
> I just run all tests in 3.2.x-fixes branch with this patch:
> {noformat}
> diff --git a/parent/pom.xml b/parent/pom.xml
> index 234bcbaa0f..47a3885db0 100644
> --- a/parent/pom.xml
> +++ b/parent/pom.xml
> @@ -47,8 +47,8 @@
>
> org.ow2.asm
> asm
> -5.2
> -[3.0,6.3)
> +7.0
> +[3.0,8)
>
>
>
> {noformat}
> all tests pass.
> background: I've prepared _simultaneous_ release of pax-web, pax-transx,
> pax-jms, pax-jdbc, pax-cdi, preparing for aligned release of karaf 4.2.3.
> In pax-web I've upgraded to ASM7, so now, pax-web ship/install ASM7 bundles.
> Karaf itself switched to ASM7 some time ago, but the reason why (so far) CXF
> tests worked was that pax-web used in Karaf was installing ASM6 libraries.
> CXF contains (very) wide range for ASM import: {{[3, 6.3)}} and knowing the
> good history of backward compatibility of ASM, I think it's worth increasing
> the range for ASM in CXF.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CXF-7948) Upgrade to asm 7
[
https://issues.apache.org/jira/browse/CXF-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-7948:
-
Assignee: Freeman Fang
> Upgrade to asm 7
>
>
> Key: CXF-7948
> URL: https://issues.apache.org/jira/browse/CXF-7948
> Project: CXF
> Issue Type: Wish
>Reporter: Grzegorz Grzybek
>Assignee: Freeman Fang
>Priority: Major
>
> I just run all tests in 3.2.x-fixes branch with this patch:
> {noformat}
> diff --git a/parent/pom.xml b/parent/pom.xml
> index 234bcbaa0f..47a3885db0 100644
> --- a/parent/pom.xml
> +++ b/parent/pom.xml
> @@ -47,8 +47,8 @@
>
> org.ow2.asm
> asm
> -5.2
> -[3.0,6.3)
> +7.0
> +[3.0,8)
>
>
>
> {noformat}
> all tests pass.
> background: I've prepared _simultaneous_ release of pax-web, pax-transx,
> pax-jms, pax-jdbc, pax-cdi, preparing for aligned release of karaf 4.2.3.
> In pax-web I've upgraded to ASM7, so now, pax-web ship/install ASM7 bundles.
> Karaf itself switched to ASM7 some time ago, but the reason why (so far) CXF
> tests worked was that pax-web used in Karaf was installing ASM6 libraries.
> CXF contains (very) wide range for ASM import: {{[3, 6.3)}} and knowing the
> good history of backward compatibility of ASM, I think it's worth increasing
> the range for ASM in CXF.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7948) Upgrade to asm 7
[
https://issues.apache.org/jira/browse/CXF-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745907#comment-16745907
]
Freeman Fang commented on CXF-7948:
---
Patch applied on behalf of Grzegorz Grzybek with thanks
> Upgrade to asm 7
>
>
> Key: CXF-7948
> URL: https://issues.apache.org/jira/browse/CXF-7948
> Project: CXF
> Issue Type: Wish
>Reporter: Grzegorz Grzybek
>Assignee: Freeman Fang
>Priority: Major
>
> I just run all tests in 3.2.x-fixes branch with this patch:
> {noformat}
> diff --git a/parent/pom.xml b/parent/pom.xml
> index 234bcbaa0f..47a3885db0 100644
> --- a/parent/pom.xml
> +++ b/parent/pom.xml
> @@ -47,8 +47,8 @@
>
> org.ow2.asm
> asm
> -5.2
> -[3.0,6.3)
> +7.0
> +[3.0,8)
>
>
>
> {noformat}
> all tests pass.
> background: I've prepared _simultaneous_ release of pax-web, pax-transx,
> pax-jms, pax-jdbc, pax-cdi, preparing for aligned release of karaf 4.2.3.
> In pax-web I've upgraded to ASM7, so now, pax-web ship/install ASM7 bundles.
> Karaf itself switched to ASM7 some time ago, but the reason why (so far) CXF
> tests worked was that pax-web used in Karaf was installing ASM6 libraries.
> CXF contains (very) wide range for ASM import: {{[3, 6.3)}} and knowing the
> good history of backward compatibility of ASM, I think it's worth increasing
> the range for ASM in CXF.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7946) OperationResourceInfoComparator should consider methods parameters
[
https://issues.apache.org/jira/browse/CXF-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang updated CXF-7946:
--
Fix Version/s: 3.2.8
> OperationResourceInfoComparator should consider methods parameters
> --
>
> Key: CXF-7946
> URL: https://issues.apache.org/jira/browse/CXF-7946
> Project: CXF
> Issue Type: Bug
>Reporter: Freeman Fang
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.3.0, 3.2.8
>
>
> In samples/jax_rs/spring_boot shipped with CXF kit, we can see warning
> message like
> {code}
> WARNING: Both
> org.apache.cxf.jaxrs.openapi.OpenApiCustomizedResource#getOpenApi and
> org.apache.cxf.jaxrs.openapi.OpenApiCustomizedResource#getOpenApi are equal
> candidates for handling the current request which can lead to unpredictable
> results
> {code}
> when using swagger-ui.
> This is caused by that class OpenApiCustomizedResource has getOpenApi method,
> but its parent class OpenApiResource also has getOpenApi method, two methods
> are using different signatures. OperationResourceInfoComparator shouldn't
> see two methods as same because they are different
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7948) Upgrade to asm 7
[
https://issues.apache.org/jira/browse/CXF-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved CXF-7948.
---
Resolution: Fixed
Fix Version/s: 3.2.8
3.3.0
> Upgrade to asm 7
>
>
> Key: CXF-7948
> URL: https://issues.apache.org/jira/browse/CXF-7948
> Project: CXF
> Issue Type: Wish
>Reporter: Grzegorz Grzybek
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 3.3.0, 3.2.8
>
>
> I just run all tests in 3.2.x-fixes branch with this patch:
> {noformat}
> diff --git a/parent/pom.xml b/parent/pom.xml
> index 234bcbaa0f..47a3885db0 100644
> --- a/parent/pom.xml
> +++ b/parent/pom.xml
> @@ -47,8 +47,8 @@
>
> org.ow2.asm
> asm
> -5.2
> -[3.0,6.3)
> +7.0
> +[3.0,8)
>
>
>
> {noformat}
> all tests pass.
> background: I've prepared _simultaneous_ release of pax-web, pax-transx,
> pax-jms, pax-jdbc, pax-cdi, preparing for aligned release of karaf 4.2.3.
> In pax-web I've upgraded to ASM7, so now, pax-web ship/install ASM7 bundles.
> Karaf itself switched to ASM7 some time ago, but the reason why (so far) CXF
> tests worked was that pax-web used in Karaf was installing ASM6 libraries.
> CXF contains (very) wide range for ASM import: {{[3, 6.3)}} and knowing the
> good history of backward compatibility of ASM, I think it's worth increasing
> the range for ASM in CXF.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7949) Update Servlet dependency to 4.x and Tomcat to 9.x
Dennis Kieselhorst created CXF-7949: --- Summary: Update Servlet dependency to 4.x and Tomcat to 9.x Key: CXF-7949 URL: https://issues.apache.org/jira/browse/CXF-7949 Project: CXF Issue Type: Task Reporter: Dennis Kieselhorst Fix For: 3.4.0 Use Jakarta Servlet release https://github.com/eclipse-ee4j/servlet-api -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7914) Exception in upgrading cxf-tools-wsdlto-frontend-jaxws jar version from 3.1.* to 3.2.*
[
https://issues.apache.org/jira/browse/CXF-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16745919#comment-16745919
]
Dennis Kieselhorst commented on CXF-7914:
-
No further information received, feel free to reopen with a reproducable sample.
> Exception in upgrading cxf-tools-wsdlto-frontend-jaxws jar version from 3.1.*
> to 3.2.*
> --
>
> Key: CXF-7914
> URL: https://issues.apache.org/jira/browse/CXF-7914
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 3.2.0
>Reporter: Ragul
>Priority: Major
>
> Upgrading cxf from 3.1.16 to 3.2.7 is causing the below expection.
> but Upgarding to minor version 3.1.17 is successfull
> Tried adding common-lang3 depenedency but still the exception persists
> INFO: JDK 8 Platform: Linux
> *StackTrace:*
> ** soap_server_generate:
> [echo] Using Apache CXF to generate the WSDL client.
> [java] Nov 16, 2018 12:48:19 PM org.apache.cxf.staxutils.StaxUtils
> createXMLInputFactory
> [java] WARNING: Could not create a secure Stax XMLInputFactory. Found
> class com.sun.xml.internal.stream.XMLInputFactoryImpl. Suggest Woodstox
> 4.2.0 or newer.
> [java] Nov 16, 2018 12:48:19 PM org.apache.cxf.staxutils.StaxUtils
> createXMLInputFactory
> [java] WARNING: Could not create a secure Stax XMLInputFactory. Found
> class com.sun.xml.internal.stream.XMLInputFactoryImpl. Suggest Woodstox
> 4.2.0 or newer.
> [java] Loading FrontEnd jaxws ...
> [java] Loading DataBinding jaxb ...
> [java] wsdl2java -xjc-Xfluent-api-ext -xjc-Xfluent-api -d
> */components/snapshotcollector/target/generated-sources/src/main/java -p
> com.alcatel.ni.snapshotcollector.commands -wsdlLocation
> classpath:${wsdl.location} -verbose
> */components/snapshotcollector/target/generated-sources/src/main/wsee/META-INF/wsdl/snapshotcollector.wsdl
> [java] wsdl2java - Apache CXF 3.2.7
> [java]
> [java] Nov 16, 2018 12:48:20 PM
> org.apache.cxf.catalog.OASISCatalogManager loadCatalogs
> [java] WARNING: Catalog found at
> jar:[file:*/maven/local/repository/org/apache/cxf/cxf-tools-wsdlto-frontend-jaxws/3.2.7/cxf-tools-wsdlto-frontend-jaxws-3.2.7.jar!/META-INF/jax-ws-catalog.xml|file://udir/ragul/maven/local/repository/org/apache/cxf/cxf-tools-wsdlto-frontend-jaxws/3.2.7/cxf-tools-wsdlto-frontend-jaxws-3.2.7.jar!/META-INF/jax-ws-catalog.xml]
> but no org.apache.xml.resolver.CatalogManager was found. Check the
> classpatch for an xmlresolver jar.
> [java] Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/commons/lang3/StringUtils
> [java] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.ServiceProcessor.processService(ServiceProcessor.java:253)
> [java] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.ServiceProcessor.process(ServiceProcessor.java:101)
> [java] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.WSDLToJavaProcessor.wsdlDefinitionToJavaModel(WSDLToJavaProcessor.java:86)
> [java] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.WSDLToJavaProcessor.process(WSDLToJavaProcessor.java:60)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:282)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:412)
> [java] at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:185)
> [java] Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.lang3.StringUtils
> [java] at
> java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> [java] at
> java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> [java] at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> [java] at
> java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> [java] ... 11 more
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CXF-7914) Exception in upgrading cxf-tools-wsdlto-frontend-jaxws jar version from 3.1.* to 3.2.*
[
https://issues.apache.org/jira/browse/CXF-7914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Kieselhorst resolved CXF-7914.
-
Resolution: Cannot Reproduce
> Exception in upgrading cxf-tools-wsdlto-frontend-jaxws jar version from 3.1.*
> to 3.2.*
> --
>
> Key: CXF-7914
> URL: https://issues.apache.org/jira/browse/CXF-7914
> Project: CXF
> Issue Type: Bug
> Components: Tooling
>Affects Versions: 3.2.0
>Reporter: Ragul
>Priority: Major
>
> Upgrading cxf from 3.1.16 to 3.2.7 is causing the below expection.
> but Upgarding to minor version 3.1.17 is successfull
> Tried adding common-lang3 depenedency but still the exception persists
> INFO: JDK 8 Platform: Linux
> *StackTrace:*
> ** soap_server_generate:
> [echo] Using Apache CXF to generate the WSDL client.
> [java] Nov 16, 2018 12:48:19 PM org.apache.cxf.staxutils.StaxUtils
> createXMLInputFactory
> [java] WARNING: Could not create a secure Stax XMLInputFactory. Found
> class com.sun.xml.internal.stream.XMLInputFactoryImpl. Suggest Woodstox
> 4.2.0 or newer.
> [java] Nov 16, 2018 12:48:19 PM org.apache.cxf.staxutils.StaxUtils
> createXMLInputFactory
> [java] WARNING: Could not create a secure Stax XMLInputFactory. Found
> class com.sun.xml.internal.stream.XMLInputFactoryImpl. Suggest Woodstox
> 4.2.0 or newer.
> [java] Loading FrontEnd jaxws ...
> [java] Loading DataBinding jaxb ...
> [java] wsdl2java -xjc-Xfluent-api-ext -xjc-Xfluent-api -d
> */components/snapshotcollector/target/generated-sources/src/main/java -p
> com.alcatel.ni.snapshotcollector.commands -wsdlLocation
> classpath:${wsdl.location} -verbose
> */components/snapshotcollector/target/generated-sources/src/main/wsee/META-INF/wsdl/snapshotcollector.wsdl
> [java] wsdl2java - Apache CXF 3.2.7
> [java]
> [java] Nov 16, 2018 12:48:20 PM
> org.apache.cxf.catalog.OASISCatalogManager loadCatalogs
> [java] WARNING: Catalog found at
> jar:[file:*/maven/local/repository/org/apache/cxf/cxf-tools-wsdlto-frontend-jaxws/3.2.7/cxf-tools-wsdlto-frontend-jaxws-3.2.7.jar!/META-INF/jax-ws-catalog.xml|file://udir/ragul/maven/local/repository/org/apache/cxf/cxf-tools-wsdlto-frontend-jaxws/3.2.7/cxf-tools-wsdlto-frontend-jaxws-3.2.7.jar!/META-INF/jax-ws-catalog.xml]
> but no org.apache.xml.resolver.CatalogManager was found. Check the
> classpatch for an xmlresolver jar.
> [java] Exception in thread "main" java.lang.NoClassDefFoundError:
> org/apache/commons/lang3/StringUtils
> [java] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.ServiceProcessor.processService(ServiceProcessor.java:253)
> [java] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.internal.ServiceProcessor.process(ServiceProcessor.java:101)
> [java] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.WSDLToJavaProcessor.wsdlDefinitionToJavaModel(WSDLToJavaProcessor.java:86)
> [java] at
> org.apache.cxf.tools.wsdlto.frontend.jaxws.processor.WSDLToJavaProcessor.process(WSDLToJavaProcessor.java:60)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:282)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:412)
> [java] at
> org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86)
> [java] at
> org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:185)
> [java] Caused by: java.lang.ClassNotFoundException:
> org.apache.commons.lang3.StringUtils
> [java] at
> java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> [java] at
> java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> [java] at
> sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
> [java] at
> java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> [java] ... 11 more
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CXF-7950) Update Johnzon to 1.1.11
Dennis Kieselhorst created CXF-7950: --- Summary: Update Johnzon to 1.1.11 Key: CXF-7950 URL: https://issues.apache.org/jira/browse/CXF-7950 Project: CXF Issue Type: Task Reporter: Dennis Kieselhorst -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7950) Update Johnzon to 1.1.11
[
https://issues.apache.org/jira/browse/CXF-7950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746255#comment-16746255
]
Dennis Kieselhorst commented on CXF-7950:
-
Setting {color:#80}cxf.johnzon.version {color}to 1.1.11 currently fails
with:
{noformat}
Message: Unable to resolve root: missing requirement [root] osgi.identity;
osgi.identity=cxf-jsr-json; type=karaf.feature; version=3.3.0.SNAPSHOT;
filter:="(&(osgi.identity=cxf-jsr-json)(type=karaf.feature)(version>=3.3.0.SNAPSHOT))"
[caused by: Unable to resolve cxf-jsr-json/3.3.0.SNAPSHOT: missing requirement
[cxf-jsr-json/3.3.0.SNAPSHOT] osgi.identity;
osgi.identity=org.apache.johnzon.core; type=osgi.bundle;
version="[1.1.11,1.1.11]"; resolution:=mandatory [caused by: Unable to resolve
org.apache.johnzon.core/1.1.11: missing requirement
[org.apache.johnzon.core/1.1.11] osgi.extender;
filter:="(osgi.extender=osgi.serviceloader.registrar)"]]{noformat}
> Update Johnzon to 1.1.11
>
>
> Key: CXF-7950
> URL: https://issues.apache.org/jira/browse/CXF-7950
> Project: CXF
> Issue Type: Task
>Reporter: Dennis Kieselhorst
>Priority: Minor
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7941) SamlValidator does not work with chain trust
[
https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746271#comment-16746271
]
Tomas Vanhala commented on CXF-7941:
Thank you very much for confirming that chain trust should work. This prompted
us to look closer at how we are creating the SOAP request messages in our
internal testing.
We discovered that by changing the SAML request slightly, we were able to get
WSS4J chain trust to work.
I am including three sample requests:
* request-real-sanitised.xml
* request-test-broken-sanitised.xml
* request-test-working-sanitised.xml
All requests have the X.509 certificate as the value of
wsse:BinarySecurityToken.
All requests sign the SAML Assertion.
The crucial difference between request-test-broken-sanitised.xml and
request-test-working-sanitised.xml seems to be in the signature that is used to
sign the SAML Assertion:
* in request-test-broken-sanitised.xml, inside ds:KeyInfo there is the RSA
public key
* in request-test-working-sanitised.xml, inside ds:KeyInfo there is the the
certificate
For the processing of request-test-broken-sanitised.xml, I have attached a
stack trace leading to verifyTrust.
Does this confirm that there is not a problem in CXF/WSS4J ?
However, we are still not fully comfortable with our situation.
*The real request* (request-real-sanitised.xml) is produced by a partner
organisation. It does not contain the certificate multiple times. The
certificate appears once, as the value of wsse:BinarySecurityToken. In
dsig:KeyInfo, the certificate is referenced by wsse:SecurityTokenReference.
There is only one signature, which signs the elements: wsu:Timestamp,
saml:Assertion, wsse:BinarySecurityToken.
*The test requests* are created by ourselves, using CXF. Our implementation
generates two signatures:
* the first signature signs the element saml2:Assertion
* the second signature signs the elements wsu:Timestamp,
wsse:SecurityTokenReference, wsse:BinarySecurityToken
The code that does this is as follows:
{code:java}
static class SAMLCBHandler implements CallbackHandler {
private final String issuer;
private final String subjectName;
private final String alias;
private final String role;
private Properties cryptoProps;
public SAMLCBHandler(Properties cryptoProps, String issuer, String
subjectName, String alias, String role) {
this.cryptoProps = cryptoProps;
this.issuer = issuer;
this.subjectName = subjectName;
this.alias = alias;
this.role = role;
}
@Override
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
for (Callback cb: callbacks) {
SAMLCallback scb = (SAMLCallback) cb;
scb.setSamlVersion(Version.SAML_20);
scb.setIssuer(issuer);
SubjectBean subj = new SubjectBean();
subj.setSubjectName(subjectName);
subj.setSubjectConfirmationMethod(SAML2Constants.CONF_SENDER_VOUCHES);
scb.setSubject(subj);
List asd = new ArrayList<>();
AttributeBean roleBean = new AttributeBean("role", "role",
Collections.singletonList((Object) role));
ArrayList x = new ArrayList();
x.add(roleBean);
asd.add(new AttributeStatementBean(subj, x));
scb.setAttributeStatementData(asd);
scb.setSignAssertion(true);
}
}
{code}
Is it possible to modify the callback handler to build a request that bears
more resemblance to the real requests?
> SamlValidator does not work with chain trust
>
>
> Key: CXF-7941
> URL: https://issues.apache.org/jira/browse/CXF-7941
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
>Affects Versions: 3.2.7
>Reporter: Tomas Vanhala
>Priority: Major
> Attachments: cxf7941.zip
>
>
> As explained here
> [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,]
> WSS4J supports specifying constraints on the subject DN of the certificate
> used for signature validation.
> We have successfully applied "direct trust" when receiving SOAP requests
> containing a signed SAML token.
> We attempted to migrate to "chain trust" by removing the certificate used to
> sign the requests from the Merlin trust store, and setting an appropriate
> Subject DN Cert Constraint.
> It did not work. Our analysis is that WSS4J's SamlValidator is not able to
> handle a scenario where the certificate used to sign the requests is not in
> the trust store. The problem seems to be in the method
> findPublicKeyInKeyStore() of Merlin.java.
> We were able
[jira] [Updated] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Vanhala updated CXF-7941: --- Attachment: request-test-broken-sanitised.xml > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip, request-real-sanitised.xml, > request-test-broken-sanitised.xml, request-test-working-sanitised.xml, > stacktrace-request-test-broken.txt > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Vanhala updated CXF-7941: --- Attachment: request-test-working-sanitised.xml > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip, request-real-sanitised.xml, > request-test-broken-sanitised.xml, request-test-working-sanitised.xml, > stacktrace-request-test-broken.txt > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Vanhala updated CXF-7941: --- Attachment: stacktrace-request-test-broken.txt > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip, request-real-sanitised.xml, > request-test-broken-sanitised.xml, request-test-working-sanitised.xml, > stacktrace-request-test-broken.txt > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CXF-7941) SamlValidator does not work with chain trust
[
https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746271#comment-16746271
]
Tomas Vanhala edited comment on CXF-7941 at 1/18/19 1:21 PM:
-
Thank you very much for confirming that chain trust should work. This prompted
us to look closer at how we are creating the SOAP request messages in our
internal testing.
We discovered that by changing the SAML request slightly, we were able to get
WSS4J chain trust to work.
I am including three sample requests:
* request-real-sanitised.xml
* request-test-broken-sanitised.xml
* request-test-working-sanitised.xml
All requests have the X.509 certificate as the value of
wsse:BinarySecurityToken.
All requests sign the SAML Assertion.
The crucial difference between request-test-broken-sanitised.xml and
request-test-working-sanitised.xml seems to be in the signature that is used to
sign the SAML Assertion:
* in request-test-broken-sanitised.xml, inside ds:KeyInfo there is the RSA
public key
* in request-test-working-sanitised.xml, inside ds:KeyInfo there is the the
certificate
For the processing of request-test-broken-sanitised.xml, I have attached a
stack trace leading to verifyTrust.
Does this confirm that there is not a problem in CXF/WSS4J ?
However, we are still not fully comfortable with our situation.
*The real request* (request-real-sanitised.xml) is produced by a partner
organisation. It does not contain the certificate multiple times. The
certificate appears once, as the value of wsse:BinarySecurityToken. In
dsig:KeyInfo, the certificate is referenced by wsse:SecurityTokenReference.
There is only one signature, which signs the elements: wsu:Timestamp,
saml:Assertion, wsse:BinarySecurityToken.
*The test requests* are created by ourselves, using CXF. Our implementation
generates two signatures:
* The first signature signs the element saml2:Assertion. The signature
contains a 2nd copy of the X.509 certificate.
* The second signature signs the elements wsu:Timestamp,
wsse:SecurityTokenReference, wsse:BinarySecurityToken. The signature contains a
reference to the certificate in wsse:BinarySecurityToken.
The code that does this is as follows:
{code:java}
static class SAMLCBHandler implements CallbackHandler {
private final String issuer;
private final String subjectName;
private final String alias;
private final String role;
private Properties cryptoProps;
public SAMLCBHandler(Properties cryptoProps, String issuer, String
subjectName, String alias, String role) {
this.cryptoProps = cryptoProps;
this.issuer = issuer;
this.subjectName = subjectName;
this.alias = alias;
this.role = role;
}
@Override
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
for (Callback cb: callbacks) {
SAMLCallback scb = (SAMLCallback) cb;
scb.setSamlVersion(Version.SAML_20);
scb.setIssuer(issuer);
SubjectBean subj = new SubjectBean();
subj.setSubjectName(subjectName);
subj.setSubjectConfirmationMethod(SAML2Constants.CONF_SENDER_VOUCHES);
scb.setSubject(subj);
List asd = new ArrayList<>();
AttributeBean roleBean = new AttributeBean("role", "role",
Collections.singletonList((Object) role));
ArrayList x = new ArrayList();
x.add(roleBean);
asd.add(new AttributeStatementBean(subj, x));
scb.setAttributeStatementData(asd);
scb.setSignAssertion(true);
}
}
{code}
Is it possible to modify the callback handler to build a request that bears
more resemblance to the real requests?
was (Author: tomasv):
Thank you very much for confirming that chain trust should work. This prompted
us to look closer at how we are creating the SOAP request messages in our
internal testing.
We discovered that by changing the SAML request slightly, we were able to get
WSS4J chain trust to work.
I am including three sample requests:
* request-real-sanitised.xml
* request-test-broken-sanitised.xml
* request-test-working-sanitised.xml
All requests have the X.509 certificate as the value of
wsse:BinarySecurityToken.
All requests sign the SAML Assertion.
The crucial difference between request-test-broken-sanitised.xml and
request-test-working-sanitised.xml seems to be in the signature that is used to
sign the SAML Assertion:
* in request-test-broken-sanitised.xml, inside ds:KeyInfo there is the RSA
public key
* in request-test-working-sanitised.xml, inside ds:KeyInfo there is the the
certificate
For the processing of request-test-broken-sanitised.xml, I have attached a
stack trace
[jira] [Updated] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Vanhala updated CXF-7941: --- Attachment: request-real-sanitised.xml > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip, request-real-sanitised.xml, > request-test-broken-sanitised.xml, request-test-working-sanitised.xml, > stacktrace-request-test-broken.txt > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CXF-7941) SamlValidator does not work with chain trust
[
https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746271#comment-16746271
]
Tomas Vanhala edited comment on CXF-7941 at 1/18/19 1:37 PM:
-
Thank you very much for confirming that chain trust should work. This prompted
us to look closer at how we are creating the SOAP request messages in our
internal testing.
We discovered that by changing the SAML request slightly, we were able to get
WSS4J chain trust to work.
I am including three sample requests:
* request-real-sanitised.xml
* request-test-broken-sanitised.xml
* request-test-working-sanitised.xml
All requests have the X.509 certificate as the value of
wsse:BinarySecurityToken.
All requests sign the SAML Assertion.
The crucial difference between request-test-broken-sanitised.xml and
request-test-working-sanitised.xml seems to be in the signature that is used to
sign the SAML Assertion:
* in request-test-broken-sanitised.xml, inside ds:KeyInfo there is the RSA
public key
* in request-test-working-sanitised.xml, inside ds:KeyInfo there is the the
certificate
For the processing of request-test-broken-sanitised.xml, I have attached a
stack trace leading to verifyTrust.
Originally, we had added some X.509 related code on the server side in order to
make the processing of request-test-broken-sanitised.xml work. The code is
included in the attachment obsolete-code.txt
Do these findings confirm that there is not a problem in CXF/WSS4J ?
However, we are still not fully comfortable with our situation.
*The real request* (request-real-sanitised.xml) is produced by a partner
organisation. It does not contain the certificate multiple times. The
certificate appears once, as the value of wsse:BinarySecurityToken. In
dsig:KeyInfo, the certificate is referenced by wsse:SecurityTokenReference.
There is only one signature, which signs the elements: wsu:Timestamp,
saml:Assertion, wsse:BinarySecurityToken.
*The test requests* are created by ourselves, using CXF. Our implementation
generates two signatures:
* The first signature signs the element saml2:Assertion. The signature
contains a 2nd copy of the X.509 certificate.
* The second signature signs the elements wsu:Timestamp,
wsse:SecurityTokenReference, wsse:BinarySecurityToken. The signature contains a
reference to the certificate in wsse:BinarySecurityToken.
The code that does this is as follows:
{code:java}
static class SAMLCBHandler implements CallbackHandler {
private final String issuer;
private final String subjectName;
private final String alias;
private final String role;
private Properties cryptoProps;
public SAMLCBHandler(Properties cryptoProps, String issuer, String
subjectName, String alias, String role) {
this.cryptoProps = cryptoProps;
this.issuer = issuer;
this.subjectName = subjectName;
this.alias = alias;
this.role = role;
}
@Override
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
for (Callback cb: callbacks) {
SAMLCallback scb = (SAMLCallback) cb;
scb.setSamlVersion(Version.SAML_20);
scb.setIssuer(issuer);
SubjectBean subj = new SubjectBean();
subj.setSubjectName(subjectName);
subj.setSubjectConfirmationMethod(SAML2Constants.CONF_SENDER_VOUCHES);
scb.setSubject(subj);
List asd = new ArrayList<>();
AttributeBean roleBean = new AttributeBean("role", "role",
Collections.singletonList((Object) role));
ArrayList x = new ArrayList();
x.add(roleBean);
asd.add(new AttributeStatementBean(subj, x));
scb.setAttributeStatementData(asd);
scb.setSignAssertion(true);
}
}
{code}
Is it possible to modify the callback handler to build a request that bears
more resemblance to the real requests?
was (Author: tomasv):
Thank you very much for confirming that chain trust should work. This prompted
us to look closer at how we are creating the SOAP request messages in our
internal testing.
We discovered that by changing the SAML request slightly, we were able to get
WSS4J chain trust to work.
I am including three sample requests:
* request-real-sanitised.xml
* request-test-broken-sanitised.xml
* request-test-working-sanitised.xml
All requests have the X.509 certificate as the value of
wsse:BinarySecurityToken.
All requests sign the SAML Assertion.
The crucial difference between request-test-broken-sanitised.xml and
request-test-working-sanitised.xml seems to be in the signature that is used to
sign the SAML Assertion:
* in request-test-broken-sanitised.xml, inside ds:KeyIn
[jira] [Updated] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Vanhala updated CXF-7941: --- Attachment: obsolete-code.txt > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip, obsolete-code.txt, > request-real-sanitised.xml, request-test-broken-sanitised.xml, > request-test-working-sanitised.xml, stacktrace-request-test-broken.txt > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CXF-7951) Async binding not JAX-WS compliant
Aritz Bastida created CXF-7951:
--
Summary: Async binding not JAX-WS compliant
Key: CXF-7951
URL: https://issues.apache.org/jira/browse/CXF-7951
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Affects Versions: 3.2.6
Reporter: Aritz Bastida
According to JAX-WS 2.3 spec, section 2.3.4.3, the async binding differs from
the sync binding in the handling of in-out and out parameters, namely:
* No Holder class is used
* Out parts or wrapper childs are gathered as properties in an ebtity called
RespobseBean.
Personally, I don't understand this requirement because this results in a
different method signature. But for some reason that' what the spec days...
In our project we are deploying our our services in Weblogic, which includes
Metro (JAX-WS RI) as JAX-WS implementation. And that requires the above
signature for the async binding to work.
However, CXF does not behave the same way: it expects the exact same same
signature in both cases, just differring in the response type and name ("Async"
suffix).
To put you in context, we are using Document/Literal Bare style in our clients,
with four parts:
* "request": IN
* "response": OUT
* "cabecera": IN-OUT header=true
* "metadatos": IN-OUT header=true
So, for the sync binding we have three method parameters, the last two wrapped
by Holders. That same signature works in tthe async style, but Weblogic/JAX-WS
RI doesn't like it...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CXF-7951) Async binding not JAX-WS compliant
[
https://issues.apache.org/jira/browse/CXF-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aritz Bastida updated CXF-7951:
---
Description:
According to JAX-WS 2.3 spec, section 2.3.4.3, the async binding differs from
the sync binding in the handling of in-out and out parameters, namely:
* No Holder class is used
* Out parts or wrapper childs are gathered as properties in an entity called
ResponseBean.
Personally, I don't understand the reason for this requirement because it
produces a different method signature, not very convenient. But that' what the
spec days...
In our project we are deploying our services in Weblogic, which includes Metro
(JAX-WS RI) as JAX-WS implementation. And that requires the above signature for
the async binding to work.
However, CXF does not behave the same way: it expects the exact same same
signature in both cases, just differring in the response type and name ("Async"
suffix).
To put you in context, we are using Document/Literal BARE style in our clients,
with four parts in each @WebMethod:
* "request": IN
* "response": OUT
* "cabecera": IN-OUT header=true
* "metadatos": IN-OUT header=true
So, for the sync binding we have three method parameters, the last two wrapped
by Holders. That same signature works in tthe async style, but Weblogic/JAX-WS
RI doesn't like it...
was:
According to JAX-WS 2.3 spec, section 2.3.4.3, the async binding differs from
the sync binding in the handling of in-out and out parameters, namely:
* No Holder class is used
* Out parts or wrapper childs are gathered as properties in an ebtity called
RespobseBean.
Personally, I don't understand this requirement because this results in a
different method signature. But for some reason that' what the spec days...
In our project we are deploying our our services in Weblogic, which includes
Metro (JAX-WS RI) as JAX-WS implementation. And that requires the above
signature for the async binding to work.
However, CXF does not behave the same way: it expects the exact same same
signature in both cases, just differring in the response type and name ("Async"
suffix).
To put you in context, we are using Document/Literal Bare style in our clients,
with four parts:
* "request": IN
* "response": OUT
* "cabecera": IN-OUT header=true
* "metadatos": IN-OUT header=true
So, for the sync binding we have three method parameters, the last two wrapped
by Holders. That same signature works in tthe async style, but Weblogic/JAX-WS
RI doesn't like it...
> Async binding not JAX-WS compliant
> --
>
> Key: CXF-7951
> URL: https://issues.apache.org/jira/browse/CXF-7951
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Affects Versions: 3.2.6
>Reporter: Aritz Bastida
>Priority: Major
>
> According to JAX-WS 2.3 spec, section 2.3.4.3, the async binding differs from
> the sync binding in the handling of in-out and out parameters, namely:
> * No Holder class is used
> * Out parts or wrapper childs are gathered as properties in an entity called
> ResponseBean.
> Personally, I don't understand the reason for this requirement because it
> produces a different method signature, not very convenient. But that' what
> the spec days...
> In our project we are deploying our services in Weblogic, which includes
> Metro (JAX-WS RI) as JAX-WS implementation. And that requires the above
> signature for the async binding to work.
> However, CXF does not behave the same way: it expects the exact same same
> signature in both cases, just differring in the response type and name
> ("Async" suffix).
> To put you in context, we are using Document/Literal BARE style in our
> clients, with four parts in each @WebMethod:
> * "request": IN
> * "response": OUT
> * "cabecera": IN-OUT header=true
> * "metadatos": IN-OUT header=true
> So, for the sync binding we have three method parameters, the last two
> wrapped by Holders. That same signature works in tthe async style, but
> Weblogic/JAX-WS RI doesn't like it...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7941) SamlValidator does not work with chain trust
[ https://issues.apache.org/jira/browse/CXF-7941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746491#comment-16746491 ] Colm O hEigeartaigh commented on CXF-7941: -- Hi, The problem in "request-test-broken-sanitised.xml" is that the PublicKey stored in the Assertion Signature KeyInfo is not in the truststore. As I said above, chain trust only works for the case of a certificate. So I think WSS4J is handling this appropriately. However, what we could do for the case of a PublicKey Signature in general is to check to see if the public key matches that of a certificate carried in BinarySecurityToken, and then to trust verification on the Signature. I'm a bit reluctant though to implement this. If someone is including a PublicKey as the signing credentials of the KeyInfo, then they obviously expect that the recipieint of the assertion has direct access to that public key. Colm. > SamlValidator does not work with chain trust > > > Key: CXF-7941 > URL: https://issues.apache.org/jira/browse/CXF-7941 > Project: CXF > Issue Type: Bug > Components: WS-* Components >Affects Versions: 3.2.7 >Reporter: Tomas Vanhala >Priority: Major > Attachments: cxf7941.zip, obsolete-code.txt, > request-real-sanitised.xml, request-test-broken-sanitised.xml, > request-test-working-sanitised.xml, stacktrace-request-test-broken.txt > > > As explained here > [http://coheigea.blogspot.com/2012/08/subject-dn-certificate-constraint.html,] > WSS4J supports specifying constraints on the subject DN of the certificate > used for signature validation. > We have successfully applied "direct trust" when receiving SOAP requests > containing a signed SAML token. > We attempted to migrate to "chain trust" by removing the certificate used to > sign the requests from the Merlin trust store, and setting an appropriate > Subject DN Cert Constraint. > It did not work. Our analysis is that WSS4J's SamlValidator is not able to > handle a scenario where the certificate used to sign the requests is not in > the trust store. The problem seems to be in the method > findPublicKeyInKeyStore() of Merlin.java. > We were able to make chain trust (and the Subject DN Cert Constraint) work by > including the needed PKI code in a customised SamlValidator, but we would > rather not go this route. > Please fix chain trust in WSS4J SAML validation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7929) org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException is changing actual error cause and error http status
[ https://issues.apache.org/jira/browse/CXF-7929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh resolved CXF-7929. -- Resolution: Cannot Reproduce We need a test-case of some sort to take this further. > org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException > is changing actual error cause and error http status > - > > Key: CXF-7929 > URL: https://issues.apache.org/jira/browse/CXF-7929 > Project: CXF > Issue Type: Bug > Components: JAX-RS >Affects Versions: 3.1.12 >Reporter: Vijay Kumar >Priority: Major > Attachments: image-2018-12-20-10-35-19-884.png, > image-2018-12-26-16-16-02-352.png, image-2018-12-26-16-21-15-698.png > > > I would like to understand details of changing error / exception details > org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException(AbstractClient.java:511) > at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:901) > at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:862) > at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:427) > at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:607) > > +*Scenario:*+ ** We are facing a scenario where my program throws an > exception with needful details as > cause: document with name not available in the repository > errorCode: 404 > as > java.lang.RuntimeException: Document with name not available in the > repository > but from > org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException > method it is converted to > code: 500 > cause: Internal Server Error > Due to this conversion we are not able to understand / catch actual cause of > the error / exception. > > Fare Scenario: > # I have file in repo > 2. i have rest client api to download (etc) > # My rest client api uses org.apache.cxf.jaxrs.client > # When there is no file to download, my api throwing an runtime exception > with a cause of details. > # however the exception is handled by > org.apache.cxf.jaxrs.client.WebClient.get() is modifying the exception > details as internal server error, 500. > org.apache.cxf.jaxrs.client.AbstractClient.convertToWebApplicationException(AbstractClient.java:511) > at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:901) > at org.apache.cxf.jaxrs.client.WebClient.doInvoke(WebClient.java:862) > at org.apache.cxf.jaxrs.client.WebClient.invoke(WebClient.java:427) > at org.apache.cxf.jaxrs.client.WebClient.get(WebClient.java:607) > > Please be informed that i have gone through the class details of WebClient > and AbstractWebClient > > Please let me know in case of any info needed. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7926) MicroProfile Rest Client 1.2
[ https://issues.apache.org/jira/browse/CXF-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746573#comment-16746573 ] Colm O hEigeartaigh commented on CXF-7926: -- Can this issue be resolved? Any remaining work could go into a new Jira for 3.3.1 > MicroProfile Rest Client 1.2 > > > Key: CXF-7926 > URL: https://issues.apache.org/jira/browse/CXF-7926 > Project: CXF > Issue Type: New Feature > Components: JAX-RS >Reporter: Andy McCright >Assignee: Andy McCright >Priority: Major > Fix For: 3.3.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > MicroProfile Rest Client 1.2 adds a lot of new function that should improve > developer experience and third-party product integration. > > The complete list of issues in the new spec are available here: > [https://github.com/eclipse/microprofile-rest-client/milestone/4?closed=1] > > Some of the highlights are: > * the ability to specify the base URI in the `@RegisterRestClient` > annotation. > * `removeContext` method in `AsyncInvocationInterceptor` interface allowing > cleanup of contexts transferred from the calling thread. > * new `RestClientListener` SPI interface for intercepting Rest Client > instances. > * portable timeout properties. > > The official release of MP Rest Client 1.2 will be some time in late January > or early February 2019. There is a 1.2-m2 (milestone 2) early access release > of the API and TCK that we can build on for the CXF 3.3.0 release. Once the > official release of the API/TCK occurs in early 2019, we can update the maven > dependencies to use the official release as part of 3.3.1 or 3.3.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7944) OAuthClientUtils hides error message if it contains a comma
[
https://issues.apache.org/jira/browse/CXF-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh resolved CXF-7944.
--
Resolution: Fixed
> OAuthClientUtils hides error message if it contains a comma
> ---
>
> Key: CXF-7944
> URL: https://issues.apache.org/jira/browse/CXF-7944
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.2.7
>Reporter: Levi Miller
>Assignee: Colm O hEigeartaigh
>Priority: Major
> Fix For: 3.3.0, 3.2.8
>
>
> OAuthClientUtils.getAccessToken hides the response error if the error message
> contains a comma.
> The root cause of this is that OAuthJSONProvider.readJSONResponse uses
> String.split(",") to parse the json string, which throws
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1{code}
> if there are unexpected commas.
>
> Stack trace:
> {code:java}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(Unknown Source)
> at
> org.apache.cxf.rs.security.oauth2.provider.OAuthJSONProvider.readJSONResponse(OAuthJSONProvider.java:310)
> at
> org.apache.cxf.rs.security.oauth2.client.OAuthClientUtils.getAccessToken(OAuthClientUtils.java:312)
> at
> org.apache.cxf.rs.security.oauth2.client.OAuthClientUtils.getAccessToken(OAuthClientUtils.java:231)
> at
> org.apache.cxf.rs.security.oauth2.client.OAuthClientUtils.getAccessToken(OAuthClientUtils.java:179){code}
> response.getEntity() json string:
> {code:java}
> {"error":"invalid_client","error_description":"Client authentication failed
> due to unknown client, no client authentication included, or unsupported
> authentication method."}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7898) Cxf returns 'null' on MessagePartInfo typeClass in services with multiple portTypes
[
https://issues.apache.org/jira/browse/CXF-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16746586#comment-16746586
]
Colm O hEigeartaigh commented on CXF-7898:
--
Do you have a test-case to help reproduce the problem?
> Cxf returns 'null' on MessagePartInfo typeClass in services with multiple
> portTypes
> ---
>
> Key: CXF-7898
> URL: https://issues.apache.org/jira/browse/CXF-7898
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
>Reporter: Mathaus Erich Ramos
>Priority: Major
>
> Recently I started using the Apache Cxf lib with the intention of performing
> the extraction of operation attributes in a WSDL files for SOAP Web Services.
> That's because before the company where I worked had many problems with the
> old lib, the Predic8.
> However, recently I tried to extract the attributes of a WSDL operation and I
> was not able to get the expected result. From what I have analyzed with some
> tests, it is not able to identify the type of the Class of the attributes
> that have more than one binding. However with some tests I performed,
> changing the portType of all bindings to the same I was able to get it to
> interpret correctly.
> I believe the problem is occurring when there is more and a binding and each
> uses a different PortType, since it can only extract the type of classes from
> the attributes in one of the portTypes.
> Please give me a light.
> *Code used to extract:*
> {code:java}
> public class DynClient {
>
>
> public static void main(String[] args) {
> JaxWsDynamicClientFactory factory =
> JaxWsDynamicClientFactory.newInstance();
> Client client =
> factory.createClient("http://intsaprm.hptransportes.com.br:8051/wsConsultaSQL/MEX?wsdl";);
>
> for (ServiceInfo service :
> client.getEndpoint().getService().getServiceInfos()) {
> for (BindingInfo binding : service.getBindings()) {
> System.out.println("Binding: " +
> binding.getName().getLocalPart());
> binding.getOperations().forEach(operation -> {
>
> if (operation.getInput() != null) {
>
> operation.getInput().getMessageParts().forEach(part
> -> {
> System.out.println(part.getName().getLocalPart()
> + "=>" + part.getTypeClass());
> });
> }
> if (operation.getOutput() != null) {
> operation.getOutput().getMessageParts().forEach(part
> -> {
> System.out.println(part.getName().getLocalPart()
> + "=>" + part.getTypeClass());
> });
> }
> });
> }
> }
>
> }
> }{code}
>
> *When executed:*
> {panel:title=Output}
> Binding: RM_IwsBase
> parameters=>class com.totvs.CheckServiceActivity
> parameters=>class com.totvs.CheckServiceActivityResponse
> parameters=>class com.totvs.AutenticaAcesso
> parameters=>class com.totvs.AutenticaAcessoResponse
> parameters=>class com.totvs.Implements
> parameters=>class com.totvs.ImplementsResponse
> Binding: RM_IwsConsultaSQL
> parameters=>null
> parameters=>null
> parameters=>null
> parameters=>null
> parameters=>null
> parameters=>null
> Binding: RM_IRMSServer
> parameters=>null
> parameters=>null
> parameters=>null
> parameters=>null
> {panel}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
