[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=16748582#comment-16748582 ] Colm O hEigeartaigh commented on CXF-7941: -- I fixed the constraint separator issue for the next WSS4J release: https://issues.apache.org/jira/browse/WSS-641 > 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] [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.
In our project we are deploying our services on 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 same input parameters
in both cases: that means we still have the Holder class and no ResponseBean.
As a result, we cannot have a portable JAX-WS client that can be used either
with Metro or CXF.
Take for example, the following WSDL. Note that there are two in-out SOAP
headers, along with the body.
{code:xml|title=WSDL|borderStyle=solid}
http://schemas.xmlsoap.org/soap/http"/>
{code}
...and, as described above, the mapping to Java differs with Metro and CXF:
{code:title=Java interface|borderStyle=solid}
@WebMethod(action = "readFileRecord")
@WebResult(name = "ReadFileRecord_OUT", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"response")
public ReadFileRecord_OUT readFileRecord(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
Holder teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
Holder teMetadata)
throws TE_Excepcion
;
// CXF
@WebMethod(operationName = "readFileRecord", action = "readFileRecord")
public Response readFileRecordAsync(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
Holder teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
Holder teMetadata);
// METRO
@WebMethod(operationName = "readFileRecord", action = "readFileRecord")
public Response readFileRecordAsync(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
TE_Cabecera teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
TE_Metadatos teMetadata);
{code}
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 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...
> Async binding
[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:
* Out: The part or wrapper child is mapped to a property of the response bean.
* In/Out: The part or wrapper child is mapped to a method parameter (no holder
class) and to a property of the response bean.
In our project we are deploying our services on 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 same input parameters
in both bindings (sync and async); that means we still have the Holder class
and no ResponseBean.
As a result, we cannot have the same, portable JAX-WS client that can be used
either with Metro or CXF, which is what we are striving for...
Take for example, the following WSDL. Note that there are two In-Out SOAP
headers, along with the body.
{code:xml|title=WSDL|borderStyle=solid}
http://schemas.xmlsoap.org/soap/http"/>
{code}
...and, as described above, the mapping to Java differs for Metro and CXF:
{code:title=Java interface|borderStyle=solid}
@WebMethod(action = "readFileRecord")
@WebResult(name = "ReadFileRecord_OUT", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"response")
public ReadFileRecord_OUT readFileRecord(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
Holder teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
Holder teMetadata)
throws TE_Excepcion
;
// CXF
@WebMethod(operationName = "readFileRecord", action = "readFileRecord")
public Response readFileRecordAsync(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
Holder teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
Holder teMetadata);
// METRO
@WebMethod(operationName = "readFileRecord", action = "readFileRecord")
public Response readFileRecordAsync(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
TE_Cabecera teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
TE_Metadatos teMetadata);
{code}
Am I missing something here? Shouldn't CXF implement this part of the JAX-WS
spec?
Thank you in advance.
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 entity called
ResponseBean.
In our project we are deploying our services on 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 same input parameters
in both cases: that means we still have the Holder class and no ResponseBean.
As a result, we cannot have a portable JAX-WS client that can be used either
with Metro or CXF.
Take for example, the following WSDL. Note that there are two in-out SOAP
headers, along with the body.
{code:xml|title=WSDL|borderStyle=solid}
[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:
* *Out:* The part or wrapper child is mapped to a property of the response
bean.
* *In/Out:* The part or wrapper child is mapped to a method parameter (no
holder class) and to a property of the response bean.
In our project we are deploying our services on 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 same input parameters
in both bindings (sync and async); that means we still have the _Holder_ class
and no _ResponseBean_.
As a result, we cannot have the same, portable JAX-WS client that can be used
either with Metro or CXF, which is what we are striving for...
Take for example, the following WSDL. Note that there are two In-Out SOAP
headers, along with the body.
{code:xml|title=WSDL|borderStyle=solid}
http://schemas.xmlsoap.org/soap/http"/>
{code}
...and, as described above, the mapping to Java differs for Metro and CXF:
{code:java|title=Java interface|borderStyle=solid}
@WebMethod(action = "readFileRecord")
@WebResult(name = "ReadFileRecord_OUT", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"response")
public ReadFileRecord_OUT readFileRecord(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
Holder teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
Holder teMetadata)
throws TE_Excepcion
;
// CXF
@WebMethod(operationName = "readFileRecord", action = "readFileRecord")
public Response readFileRecordAsync(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
Holder teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
Holder teMetadata);
// METRO
@WebMethod(operationName = "readFileRecord", action = "readFileRecord")
public Response readFileRecordAsync(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
TE_Cabecera teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
TE_Metadatos teMetadata);
{code}
Am I missing something here? Shouldn't CXF implement this part of the JAX-WS
spec?
Thank you in advance.
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:
* Out: The part or wrapper child is mapped to a property of the response bean.
* In/Out: The part or wrapper child is mapped to a method parameter (no holder
class) and to a property of the response bean.
In our project we are deploying our services on 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 same input parameters
in both bindings (sync and async); that means we still have the Holder class
and no ResponseBean.
As a result, we cannot have the same, portable JAX-WS client that can be used
either with Metro or CXF, which is what we are striving for...
Take for example, the following WSDL. Note that there are two In-Out SOAP
head
[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:
* *Out:* The part or wrapper child is mapped to a property of the response
bean.
* *In/Out:* The part or wrapper child is mapped to a method parameter (no
holder class) and to a property of the response bean.
In our project we are deploying our services on 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 same input parameters in both bindings (sync and async); that means
we still have the _Holder_ class and no _ResponseBean_.
As a result, we cannot have the same, portable JAX-WS client that can be used
either with Metro or CXF, which is what we are striving for...
Take for example, the following WSDL. Note that there are two In-Out SOAP
headers, along with the body.
{code:xml|title=WSDL|borderStyle=solid}
http://schemas.xmlsoap.org/soap/http"/>
{code}
...and, as described above, the mapping to Java differs for Metro and CXF:
{code:java|title=Java interface|borderStyle=solid}
@WebMethod(action = "readFileRecord")
@WebResult(name = "ReadFileRecord_OUT", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"response")
public ReadFileRecord_OUT readFileRecord(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
Holder teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
Holder teMetadata)
throws TE_Excepcion
;
// CXF
@WebMethod(operationName = "readFileRecord", action = "readFileRecord")
public Response readFileRecordAsync(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
Holder teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
Holder teMetadata);
// METRO
@WebMethod(operationName = "readFileRecord", action = "readFileRecord")
public Response readFileRecordAsync(
@WebParam(name = "ReadFileRecord_IN", targetNamespace =
"http://telefonica.com/gstr/srv/Bank/msg/readFileRecord-v3";, partName =
"request")
ReadFileRecord_IN request,
@WebParam(name = "TE_Cabecera", targetNamespace =
"http://telefonica.com/tran/comarq/cc/cabecera";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_header")
TE_Cabecera teHeader,
@WebParam(name = "TE_Metadatos", targetNamespace =
"http://telefonica.com/tran/comarq/cc/metadatos-2.0";, header = true, mode =
WebParam.Mode.INOUT, partName = "te_metadata")
TE_Metadatos teMetadata);
{code}
Am I missing something here? Shouldn't CXF implement this part of the JAX-WS
spec?
Thank you in advance.
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:
* *Out:* The part or wrapper child is mapped to a property of the response
bean.
* *In/Out:* The part or wrapper child is mapped to a method parameter (no
holder class) and to a property of the response bean.
In our project we are deploying our services on 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 same input parameters
in both bindings (sync and async); that means we still have the _Holder_ class
and no _ResponseBean_.
As a result, we cannot have the same, portable JAX-WS client that can be used
either with Metro or CXF, which is what we are striving for...
Take for example, the following WSDL. Note that there are two In-Out SO
[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=16748890#comment-16748890 ] Colm O hEigeartaigh commented on CXF-7926: -- [~andymc] ping! > 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)
