[jira] [Updated] (CXF-9003) Name clash when two SEIs have a same name method in the same Java package
[
https://issues.apache.org/jira/browse/CXF-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Palaga updated CXF-9003:
--
Description:
Originally reported for Quarkus CXF:
https://github.com/quarkiverse/quarkus-cxf/issues/1326
If there are two SEIs in one Java package, both having a {{@WebMethod}} with
the same name but different signature, then the default name for the
ASM-generated request, response and possibly other classes is the same for both
methods of both classes.
No exception is thrown when this happens during the class generation.
At runtime, only one set of those classes is present and calls to one of the
clients will inevitably fail.
Here is a reproducer for Quarkus CXF
https://github.com/akil-rails/spike-quarkus-cxf which will IMO mutatis mutandis
work also for plain CXF:
https://github.com/akil-rails/spike-quarkus-cxf/tree/main
I guess this piece of code around here
https://github.com/apache/cxf/blob/80c92d57ab7c34f59d51c3b30d0db9ab074e8c6b/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spi/WrapperClassLoader.java#L92-L97
should take the SEI class name into account.
was:
Originally reported for Quarkus CXF:
https://github.com/quarkiverse/quarkus-cxf/issues/1326
If there are two SEIs in one Java packages, both having a {{@WebMethod}} with
the same name but different signature, then the default name for the
ASM-generated request, response and possibly other classes is the same for both
methods of both classes.
No exception is thrown when this happens during the class generation.
At runtime, only one set of those classes is present and calls to one of the
clients will inevitably fail.
Here is a reproducer for Quarkus CXF
https://github.com/akil-rails/spike-quarkus-cxf which will IMO mutatis mutandis
work also for plain CXF:
https://github.com/akil-rails/spike-quarkus-cxf/tree/main
I guess this piece of code around here
https://github.com/apache/cxf/blob/80c92d57ab7c34f59d51c3b30d0db9ab074e8c6b/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spi/WrapperClassLoader.java#L92-L97
should take the SEI class name into account.
> Name clash when two SEIs have a same name method in the same Java package
> -
>
> Key: CXF-9003
> URL: https://issues.apache.org/jira/browse/CXF-9003
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
>Reporter: Peter Palaga
>Priority: Major
>
> Originally reported for Quarkus CXF:
> https://github.com/quarkiverse/quarkus-cxf/issues/1326
> If there are two SEIs in one Java package, both having a {{@WebMethod}} with
> the same name but different signature, then the default name for the
> ASM-generated request, response and possibly other classes is the same for
> both methods of both classes.
> No exception is thrown when this happens during the class generation.
> At runtime, only one set of those classes is present and calls to one of the
> clients will inevitably fail.
> Here is a reproducer for Quarkus CXF
> https://github.com/akil-rails/spike-quarkus-cxf which will IMO mutatis
> mutandis work also for plain CXF:
> https://github.com/akil-rails/spike-quarkus-cxf/tree/main
> I guess this piece of code around here
> https://github.com/apache/cxf/blob/80c92d57ab7c34f59d51c3b30d0db9ab074e8c6b/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spi/WrapperClassLoader.java#L92-L97
> should take the SEI class name into account.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-9003) Name clash when two SEIs have a same name method in the same Java package
Peter Palaga created CXF-9003:
-
Summary: Name clash when two SEIs have a same name method in the
same Java package
Key: CXF-9003
URL: https://issues.apache.org/jira/browse/CXF-9003
Project: CXF
Issue Type: Bug
Components: JAX-WS Runtime
Reporter: Peter Palaga
Originally reported for Quarkus CXF:
https://github.com/quarkiverse/quarkus-cxf/issues/1326
If there are two SEIs in one Java packages, both having a {{@WebMethod}} with
the same name but different signature, then the default name for the
ASM-generated request, response and possibly other classes is the same for both
methods of both classes.
No exception is thrown when this happens during the class generation.
At runtime, only one set of those classes is present and calls to one of the
clients will inevitably fail.
Here is a reproducer for Quarkus CXF
https://github.com/akil-rails/spike-quarkus-cxf which will IMO mutatis mutandis
work also for plain CXF:
https://github.com/akil-rails/spike-quarkus-cxf/tree/main
I guess this piece of code around here
https://github.com/apache/cxf/blob/80c92d57ab7c34f59d51c3b30d0db9ab074e8c6b/rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/spi/WrapperClassLoader.java#L92-L97
should take the SEI class name into account.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-8983) cxf-services-sts-core should depend on cxf-rt-rs-security-jose instead of cxf-rt-rs-security-jose-jaxrs
Peter Palaga created CXF-8983: - Summary: cxf-services-sts-core should depend on cxf-rt-rs-security-jose instead of cxf-rt-rs-security-jose-jaxrs Key: CXF-8983 URL: https://issues.apache.org/jira/browse/CXF-8983 Project: CXF Issue Type: Bug Components: STS Affects Versions: 4.0.4 Reporter: Peter Palaga cxf-services-sts-core does not need to depend on cxf-rt-rs-security-jose-jaxrs; cxf-rt-rs-security-jose would be enough. My understanding is that STS has nothing to do with JAX-RS, so there is no need to pull any JAX-RS related code via cxf-rt-rs-security-jose-jaxrs. cxf-services-sts-systests seem to pass when cxf-rt-rs-security-jose-jaxrs is replaced by cxf-rt-rs-security-jose in cxf-services-sts-core. Let me send a PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814374#comment-17814374
]
Peter Palaga commented on CXF-8971:
---
[~ffang] thanks for bringing up the option to implement this via properties. It
would be a good start if others are fine with it.
On the other hand, I'd still see configuring this in the policy as superior,
mainly because it makes sharing the configuration between servers and clients
much easier.
I had the impression so far that the properties were meant to store the
information that must not be public, such as keys and passwords. Now that you
show that there already some algorithms config in the properties, I am not so
sure anymore :).
Anyway, it would be interesting to hear what others think.
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808775#comment-17808775
]
Peter Palaga commented on CXF-8971:
---
[~coheigea] do you perhaps see any alternative/easier way to run CXF in FIPS
enabled environments?
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808768#comment-17808768
]
Peter Palaga edited comment on CXF-8971 at 1/19/24 6:21 PM:
bq. It would be great that we can introduce a fully configurable
AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
which could have default values, but the parameters of AlgorithmSuiteType can
be configured via endpoint(client or server) properties. This flexibility can
offer us more convenience.
Yes, it would be very beneficial, that this new customized AlgorithmSuite would
allow for taking the algorithms and key lengths that are on par with the
current security standards. I'd like to note that the primary motivation of
myself, [~ffang] and [~jondruse] for this is to be able to run CXF in FIPS
enabled environments.
However, I wonder, how useful the configuration through endpoint (client or
server) properties would be? Currently it is the policy definition that is used
to exchange the information about the algorithms (through the predefined
algorithm suites).
If we really want to introduce another non-standard Suite, why don't we
introduce it along with the sub-elements for the algorithms and key lengths?
Something like
{code:xml}
http://www.w3.org/2001/04/xmlenc#sha256
http://www.w3.org/2009/xmlenc11#aes256-gcm
http://www.w3.org/2001/04/xmlenc#kw-aes256
http://www.w3.org/2001/04/xmlenc#rsa-1_5
http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1
http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1
256
192
256
256
1024
4096
{code}
In that way, the information would stay transparent for the clients and servers
and would also work flawlessly at least for CXF clients and servers.
was (Author: ppalaga):
bq. It would be great that we can introduce a fully configurable
AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
which could have default values, but the parameters of AlgorithmSuiteType can
be configured via endpoint(client or server) properties. This flexibility can
offer us more convenience.
Yes, it would be very beneficial, that this new customized AlgorithmSuite would
allow for taking the algorithms and key lengths that are on par with the
current security standards. I'd like to note that the primary motivation of
myself, [~ffang] and [~jondruse] for this is to be able to run CXF in FIPS
enabled environments.
However, I wonder, how useful the configuration through endpoint (client or
server) properties would be? Currently it is the policy definition that is used
to exchange the information about the algorithms (through the predefined
algorithm suites).
If we really want to introduce another non-standard Suite, why don't we
introduce it along with the sub-elements for the algorithms and key lengths?
Something like
{code}
http://www.w3.org/2001/04/xmlenc#sha256
http://www.w3.org/2009/xmlenc11#aes256-gcm
http://www.w3.org/2001/04/xmlenc#kw-aes256
http://www.w3.org/2001/04/xmlenc#rsa-1_5
http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1
http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1
256
192
256
256
1024
4096
{code}
In that way, the information would stay transparent for the clients and servers
and would also work flawlessly at least for CXF clients and servers.
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
>
[jira] [Commented] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808768#comment-17808768
]
Peter Palaga commented on CXF-8971:
---
bq. It would be great that we can introduce a fully configurable
AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
which could have default values, but the parameters of AlgorithmSuiteType can
be configured via endpoint(client or server) properties. This flexibility can
offer us more convenience.
Yes, it would be very beneficial, that this new customized AlgorithmSuite would
allow for taking the algorithms and key lengths that are on par with the
current security standards. I'd like to note that the primary motivation of
myself, [~ffang] and [~jondruse] for this is to be able to run CXF in FIPS
enabled environments.
However, I wonder, how useful the configuration through endpoint (client or
server) properties would be? Currently it is the policy definition that is used
to exchange the information about the algorithms (through the predefined
algorithm suites).
If we really want to introduce another non-standard Suite, why don't we
introduce it along with the sub-elements for the algorithms and key lengths?
Something like
{code}
http://www.w3.org/2001/04/xmlenc#sha256
http://www.w3.org/2009/xmlenc11#aes256-gcm
http://www.w3.org/2001/04/xmlenc#kw-aes256
http://www.w3.org/2001/04/xmlenc#rsa-1_5
http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1
http://schemas.xmlsoap.org/ws/2005/02/sc/dk/p_sha1
256
192
256
256
1024
4096
{code}
In that way, the information would stay transparent for the clients and servers
and would also work flawlessly at least for CXF clients and servers.
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8967) More informative message should be given if multiple security bindings co-exist in ws-securitypolicy
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803706#comment-17803706
]
Peter Palaga commented on CXF-8967:
---
Perfect, thanks1
> More informative message should be given if multiple security bindings
> co-exist in ws-securitypolicy
>
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns";>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/";>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:159)
> at
> io.quarkiverse.cxf.transport.CxfHandler.process(CxfHandler.java
[jira] [Comment Edited] (CXF-8967) More informative message should be given if multiple security bindings co-exist in ws-securitypolicy
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803706#comment-17803706
]
Peter Palaga edited comment on CXF-8967 at 1/5/24 9:05 PM:
---
Perfect, thanks!
was (Author: ppalaga):
Perfect, thanks1
> More informative message should be given if multiple security bindings
> co-exist in ws-securitypolicy
>
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns";>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/";>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.
[jira] [Commented] (CXF-8967) Body and elements not signed with security.enable.streaming = true
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803356#comment-17803356
]
Peter Palaga commented on CXF-8967:
---
Thanks [~ffang], should I create a new issue or we can just rename this one?
> Body and elements not signed with security.enable.streaming = true
> --
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns";>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/";>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
> at
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:159)
> at
> io.quarkiverse.cxf.transport.CxfHandler.process(CxfHandler.java:241)
>
[jira] [Commented] (CXF-8967) Body and elements not signed with security.enable.streaming = true
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803347#comment-17803347
]
Peter Palaga commented on CXF-8967:
---
Thanks a lot [~ffang] for the explanation and fix in
https://github.com/ppalaga/quarkus-cxf/pull/2 !
I rebased and reworded the PR here:
https://github.com/quarkiverse/quarkus-cxf/pull/1170
My original issue is thus solved.
I wonder whether we should not introduce some measures so that policies with
multiple security bindings (such as TransportBinding, AsymmetricBinding and
SymmetricBinding) would not be accepted at all given that CXF does not honor
them anyway?
> Body and elements not signed with security.enable.streaming = true
> --
>
> Key: CXF-8967
> URL: https://issues.apache.org/jira/browse/CXF-8967
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
>
> This might have a similar cause like CXF-8940.
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
> cd quarkus-cxf
> git checkout CXF-8967
> mvn clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
> ...
> 2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT]
> (executor-thread-1) REQ_OUT
> Address: https://localhost:8444/services/helloSaml1
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
> ServiceName: Saml1PolicyHelloService
> PortName: Saml1PolicyHelloServicePort
> PortTypeName: Saml1PolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
> 2023-12-25T11:46:31.087Z
> 2023-12-25T11:51:31.087Z
>
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
> IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
> MinorVersion="1" xsi:type="saml1:AssertionType">
> NotOnOrAfter="2023-12-25T11:51:31.070Z"/>
>
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"
> NameQualifier="www.mock-sts.com">uid=sts-client,o=mock-sts.com
>
>
> urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
>
>
>AttributeNamespace="http://custom-ns";>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xsi:type="xsd:string">system-user
>
>
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/";>
> random saml person
>
>
>
> 2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.timestamp.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache 'ws-security.saml.cache.instance-1259045699'
> created in EhcacheManager.
> 2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager]
> (executor-thread-2) Cache
> 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
> EhcacheManager.
> 2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
> (executor-thread-2) Interceptor for
> {http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl
> has thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault:
> Error reading XMLStreamReader:
> org.apache.wss4j.common.ext.WSSecurityException: SAML proof-of-possession of
> the private/secret key failed
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
> at
> org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
> at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
>
[jira] [Updated] (CXF-8968) OpenTelemetryClientFeature cannot be used as a CDI bean unless it has a no-args constructor
[
https://issues.apache.org/jira/browse/CXF-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Palaga updated CXF-8968:
--
Summary: OpenTelemetryClientFeature cannot be used as a CDI bean unless it
has a no-args constructor (was: OpenTelemetryClientFeature cannot be used a
CDI bean without the no-args constructor)
> OpenTelemetryClientFeature cannot be used as a CDI bean unless it has a
> no-args constructor
> ---
>
> Key: CXF-8968
> URL: https://issues.apache.org/jira/browse/CXF-8968
> Project: CXF
> Issue Type: Bug
>Affects Versions: 4.0.3
>Reporter: Peter Palaga
>Priority: Major
>
> I am playing with the new OpenTelemetryClientFeature on Quarkus, where we
> typically produce CXF features as CDI beans. Quarkus CDI implementation does
> not allow beans of type OpenTelemetryClientFeature, because the class does
> not have the no-args constructor.
> We just need to add the default constructor, much like we already have it in
> OpenTelemetryFeature.
> A PR follows.
> For the sake of completeness here is the stack trace:
> {code}
> java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure:
> Build failed due to errors
> [error]: Build step
> io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception:
> jakarta.enterprise.inject.spi.DeploymentException: It's not possible to
> automatically add a synthetic no-args constructor to an unproxyable bean
> class. You need to manually add a non-private no-args constructor to
> io.quarkiverse.cxf.opentelemetry.it.BeanProducers$QuarkusOpenTelemetryClientFeature
> in order to fulfill the requirements for normal scoped/intercepted/decorated
> beans.
> at
> io.quarkus.arc.processor.Beans.cannotAddSyntheticNoArgsConstructor(Beans.java:958)
> at io.quarkus.arc.processor.Beans.validateBean(Beans.java:857)
> at io.quarkus.arc.processor.BeanInfo.validate(BeanInfo.java:605)
> at
> io.quarkus.arc.processor.BeanDeployment.validateBeans(BeanDeployment.java:1565)
> at
> io.quarkus.arc.processor.BeanDeployment.validate(BeanDeployment.java:482)
> at
> io.quarkus.arc.processor.BeanProcessor.validate(BeanProcessor.java:169)
> at
> io.quarkus.arc.deployment.ArcProcessor.validate(ArcProcessor.java:474)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:849)
> at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
> at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
> at
> org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
> at
> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
> at java.base/java.lang.Thread.run(Thread.java:840)
> at org.jboss.threads.JBossThread.run(JBossThread.java:501)
> at
> io.quarkus.test.junit.QuarkusTestExtension.throwBootFailureException(QuarkusTestExtension.java:638)
> at
> io.quarkus.test.junit.QuarkusTestExtension.interceptTestClassConstructor(QuarkusTestExtension.java:722)
> at java.base/java.util.Optional.orElseGet(Optional.java:364)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
> Caused by: java.lang.RuntimeException: io.quarkus.builder.BuildException:
> Build failure: Build failed due to errors
> [error]: Build step
> io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception:
> jakarta.enterprise.inject.spi.DeploymentException: It's not possible to
> automatically add a synthetic no-args constructor to an unproxyable bean
> class. You need to manually add a non-private no-args constructor to
> io.quarkiverse.cxf.opentelemetry.it.BeanProducers$QuarkusOpenTelemetryClientFeature
> in order to fulfill the requirements for normal scoped/intercepted/decorated
> beans.
> at
> io.quarkus.arc.processor.Beans.cannotAddSyntheticNoArgsConstructor(Beans.java:958)
> at io.quarkus.arc.processor.Beans.validateBean(Beans.java:857)
> at io.quarkus.arc.processor.BeanInfo.validate(BeanInfo.java:605)
> at
> io.quarkus.arc.processor.BeanDeployment.validateBeans(BeanDeployment.java:1565)
> at
> io.quarkus.arc.processor.BeanDeployment.validate(BeanDeployment.
[jira] [Created] (CXF-8968) OpenTelemetryClientFeature cannot be used a CDI bean without the no-args constructor
Peter Palaga created CXF-8968:
-
Summary: OpenTelemetryClientFeature cannot be used a CDI bean
without the no-args constructor
Key: CXF-8968
URL: https://issues.apache.org/jira/browse/CXF-8968
Project: CXF
Issue Type: Bug
Affects Versions: 4.0.3
Reporter: Peter Palaga
I am playing with the new OpenTelemetryClientFeature on Quarkus, where we
typically produce CXF features as CDI beans. Quarkus CDI implementation does
not allow beans of type OpenTelemetryClientFeature, because the class does not
have the no-args constructor.
We just need to add the default constructor, much like we already have it in
OpenTelemetryFeature.
A PR follows.
For the sake of completeness here is the stack trace:
{code}
java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure:
Build failed due to errors
[error]: Build step
io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception:
jakarta.enterprise.inject.spi.DeploymentException: It's not possible to
automatically add a synthetic no-args constructor to an unproxyable bean class.
You need to manually add a non-private no-args constructor to
io.quarkiverse.cxf.opentelemetry.it.BeanProducers$QuarkusOpenTelemetryClientFeature
in order to fulfill the requirements for normal scoped/intercepted/decorated
beans.
at
io.quarkus.arc.processor.Beans.cannotAddSyntheticNoArgsConstructor(Beans.java:958)
at io.quarkus.arc.processor.Beans.validateBean(Beans.java:857)
at io.quarkus.arc.processor.BeanInfo.validate(BeanInfo.java:605)
at
io.quarkus.arc.processor.BeanDeployment.validateBeans(BeanDeployment.java:1565)
at
io.quarkus.arc.processor.BeanDeployment.validate(BeanDeployment.java:482)
at
io.quarkus.arc.processor.BeanProcessor.validate(BeanProcessor.java:169)
at
io.quarkus.arc.deployment.ArcProcessor.validate(ArcProcessor.java:474)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:849)
at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
at
org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
at
org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
at java.base/java.lang.Thread.run(Thread.java:840)
at org.jboss.threads.JBossThread.run(JBossThread.java:501)
at
io.quarkus.test.junit.QuarkusTestExtension.throwBootFailureException(QuarkusTestExtension.java:638)
at
io.quarkus.test.junit.QuarkusTestExtension.interceptTestClassConstructor(QuarkusTestExtension.java:722)
at java.base/java.util.Optional.orElseGet(Optional.java:364)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
Caused by: java.lang.RuntimeException: io.quarkus.builder.BuildException: Build
failure: Build failed due to errors
[error]: Build step
io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception:
jakarta.enterprise.inject.spi.DeploymentException: It's not possible to
automatically add a synthetic no-args constructor to an unproxyable bean class.
You need to manually add a non-private no-args constructor to
io.quarkiverse.cxf.opentelemetry.it.BeanProducers$QuarkusOpenTelemetryClientFeature
in order to fulfill the requirements for normal scoped/intercepted/decorated
beans.
at
io.quarkus.arc.processor.Beans.cannotAddSyntheticNoArgsConstructor(Beans.java:958)
at io.quarkus.arc.processor.Beans.validateBean(Beans.java:857)
at io.quarkus.arc.processor.BeanInfo.validate(BeanInfo.java:605)
at
io.quarkus.arc.processor.BeanDeployment.validateBeans(BeanDeployment.java:1565)
at
io.quarkus.arc.processor.BeanDeployment.validate(BeanDeployment.java:482)
at
io.quarkus.arc.processor.BeanProcessor.validate(BeanProcessor.java:169)
at
io.quarkus.arc.deployment.ArcProcessor.validate(ArcProcessor.java:474)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
io.quarku
[jira] [Updated] (CXF-8967) Body and elements not signed with security.enable.streaming = true
[
https://issues.apache.org/jira/browse/CXF-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Palaga updated CXF-8967:
--
Description:
This might have a similar cause like CXF-8940.
I am unfortunately not sure at all how to reproduce this with plain CXF. If a
test is required to demonstrate the issue, I'd be thankful for pointing me to
an existing test I could adapt.
I am able to reproduce this with quarkus-cxf - here are the steps to reproduce:
{code}
git clone g...@github.com:ppalaga/quarkus-cxf.git -o ppalaga
cd quarkus-cxf
git checkout CXF-8967
mvn clean install -DskipTests -Dquarkus.build.skip
cd integration-tests/ws-security-policy
mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
...
2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT] (executor-thread-1)
REQ_OUT
Address: https://localhost:8444/services/helloSaml1
HttpMethod: POST
Content-Type: text/xml
ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
ServiceName: Saml1PolicyHelloService
PortName: Saml1PolicyHelloServicePort
PortTypeName: Saml1PolicyHelloService
Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
Payload: http://schemas.xmlsoap.org/soap/envelope/";>
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
soap:mustUnderstand="1">
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
2023-12-25T11:46:31.087Z
2023-12-25T11:51:31.087Z
http://www.w3.org/2001/XMLSchema-instance";
AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
MinorVersion="1" xsi:type="saml1:AssertionType">
uid=sts-client,o=mock-sts.com
urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
http://custom-ns";>
http://www.w3.org/2001/XMLSchema";
xsi:type="xsd:string">system-user
http://policy.security.it.cxf.quarkiverse.io/";>
random saml person
2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager] (executor-thread-2)
Cache 'ws-security.timestamp.cache.instance-1259045699' created in
EhcacheManager.
2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager] (executor-thread-2)
Cache 'ws-security.saml.cache.instance-1259045699' created in EhcacheManager.
2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager] (executor-thread-2)
Cache 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
EhcacheManager.
2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
(executor-thread-2) Interceptor for
{http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl has
thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault: Error
reading XMLStreamReader: org.apache.wss4j.common.ext.WSSecurityException: SAML
proof-of-possession of the private/secret key failed
at
org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
at
org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:159)
at io.quarkiverse.cxf.transport.CxfHandler.process(CxfHandler.java:241)
at io.quarkiverse.cxf.transport.CxfHandler.handle(CxfHandler.java:178)
at io.quarkiverse.cxf.transport.CxfHandler.handle(CxfHandler.java:47)
at
io.vertx.ext.web.impl.BlockingHandlerDecorator.lambda$handle$0(BlockingHandlerDecorator.java:48)
at
io.vertx.core.impl.ContextBase.lambda$executeBlocking$1(ContextBase.java:180)
at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:277)
at
io.vertx.core.impl.ContextBase.lambda$internalExecuteBlocking$2(ContextBase.java:199)
at
io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:582)
at
org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
at
org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1512)
at org.jboss.threads.DelegatingRunnable.run(DelegatingRunnable.java:29)
at
org.jboss.threads.ThreadLocalResettingRunnable.r
[jira] [Created] (CXF-8967) Body and elements not signed with security.enable.streaming = true
Peter Palaga created CXF-8967:
-
Summary: Body and elements not signed with
security.enable.streaming = true
Key: CXF-8967
URL: https://issues.apache.org/jira/browse/CXF-8967
Project: CXF
Issue Type: Bug
Affects Versions: 4.0.3
Reporter: Peter Palaga
This might have a similar cause like CXF-8940.
I am unfortunately not sure at all how to reproduce this with plain CXF. If a
test is required to demonstrate the issue, I'd be thankful for pointing me to
an existing test I could adapt.
I am able to reproduce this with quarkus-cxf - here are the steps to reproduce:
{code}
git clone g...@github.com:ppalaga/quarkus-cxf.git
cd quarkus-cxf
git reset --hard 0f68c3d30aedc1688771636866f353a59be904d4
mvn clean install -DskipTests -Dquarkus.build.skip
cd integration-tests/ws-security-policy
mvn clean test -Dtest=UsernameTokenSecurityPolicyStaxTest#helloSaml1
...
2023-12-25 12:46:31,093 INFO [org.apa.cxf.ser.Sam.REQ_OUT] (executor-thread-1)
REQ_OUT
Address: https://localhost:8444/services/helloSaml1
HttpMethod: POST
Content-Type: text/xml
ExchangeId: 1e62cc69-2a90-413d-97a4-b88bbd61d7b8
ServiceName: Saml1PolicyHelloService
PortName: Saml1PolicyHelloServicePort
PortTypeName: Saml1PolicyHelloService
Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
Payload: http://schemas.xmlsoap.org/soap/envelope/";>
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
soap:mustUnderstand="1">
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";>
2023-12-25T11:46:31.087Z
2023-12-25T11:51:31.087Z
http://www.w3.org/2001/XMLSchema-instance";
AssertionID="_307cbcf8-4a7d-45a6-a4dc-b46929693b35"
IssueInstant="2023-12-25T11:46:31.068Z" Issuer="sts" MajorVersion="1"
MinorVersion="1" xsi:type="saml1:AssertionType">
uid=sts-client,o=mock-sts.com
urn:oasis:names:tc:SAML:1.0:cm:sender-vouches
http://custom-ns";>
http://www.w3.org/2001/XMLSchema";
xsi:type="xsd:string">system-user
http://policy.security.it.cxf.quarkiverse.io/";>
random saml person
2023-12-25 12:46:31,300 INFO [org.ehc.cor.EhcacheManager] (executor-thread-2)
Cache 'ws-security.timestamp.cache.instance-1259045699' created in
EhcacheManager.
2023-12-25 12:46:31,311 INFO [org.ehc.cor.EhcacheManager] (executor-thread-2)
Cache 'ws-security.saml.cache.instance-1259045699' created in EhcacheManager.
2023-12-25 12:46:31,393 INFO [org.ehc.cor.EhcacheManager] (executor-thread-2)
Cache 'org.apache.cxf.ws.security.tokenstore.TokenStore-1259045699' created in
EhcacheManager.
2023-12-25 12:46:31,414 WARN [org.apa.cxf.pha.PhaseInterceptorChain]
(executor-thread-2) Interceptor for
{http://policy.security.it.cxf.quarkiverse.io/}Saml1PolicyHelloServiceImpl has
thrown exception, unwinding now: org.apache.cxf.binding.soap.SoapFault: Error
reading XMLStreamReader: org.apache.wss4j.common.ext.WSSecurityException: SAML
proof-of-possession of the private/secret key failed
at
org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:67)
at
org.apache.cxf.binding.soap.interceptor.StartBodyInterceptor.handleMessage(StartBodyInterceptor.java:38)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:307)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:265)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:233)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:207)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:159)
at io.quarkiverse.cxf.transport.CxfHandler.process(CxfHandler.java:241)
at io.quarkiverse.cxf.transport.CxfHandler.handle(CxfHandler.java:178)
at io.quarkiverse.cxf.transport.CxfHandler.handle(CxfHandler.java:47)
at
io.vertx.ext.web.impl.BlockingHandlerDecorator.lambda$handle$0(BlockingHandlerDecorator.java:48)
at
io.vertx.core.impl.ContextBase.lambda$executeBlocking$1(ContextBase.java:180)
at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:277)
at
io.vertx.core.impl.ContextBase.lambda$internalExecuteBlocking$2(ContextBase.java:199)
at
io.quarkus.vertx.core.runtime.VertxCoreRecorder$14.runWith(VertxCoreRecorder.java:582)
at
org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
at
org.jboss.threads.EnhancedQueueExecut
[jira] [Commented] (CXF-8911) Allow creating a custom CXFHttpAsyncResponseConsumer
[
https://issues.apache.org/jira/browse/CXF-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782899#comment-17782899
]
Peter Palaga commented on CXF-8911:
---
Sorry for the late response and thanks for the ideas, [~reta] and [~dufoli]!
{quote}
{code}
public interface AsyncResponseListenerFactory {
AsyncResponseListener create();
}
public interface AsyncResponseListener {
void onBeforeReceived(HttpResponse response);
void onAfterReceived(HttpResponse response);
}
CXFResponseCallback responseCallback = new CXFResponseCallback() {
@Override
public void responseReceived(HttpResponse response) {
listener.onBeforeReceived(response);
setHttpResponse(response);
listener.onAfterReceived(response);
}
};
{code}
{quote}
I think this would not work, because I need to "be on the stack" of the code
called by {{setHttpResponse(response);}}.
But your earlier proposal with {{interface AsyncResponseCallbackFactory} }}
would work. I could do something like
{code}
class AsyncResponseCallbackFactory implements AsyncResponseCallbackFactory {
AsyncResponseCallback create() {
ThreadContext threadContext =
Arc.container().select(ThreadContext.class).get();
/*
* We need to call this threadContext.contextualConsumer() here in the
constructor to store the context
* because consumeResponse() is called from another thread where the
context is not available anymore
*/
BiConsumer contextualConsumer =
threadContext.contextualConsumer(
(HttpResponse response, CXFResponseCallback callback)
-> callback.responseReceived(response));
return new MyAsyncResponseCallback(contextualConsumer);
}
}
class MyAsyncResponseCallback implements AsyncResponseCallback {
final BiConsumer contextualConsumer;
MyAsyncResponseCallback(BiConsumer
contextualConsumer) {
this.contextualConsumer = contextualConsumer;
}
void responseReceived(HttpResponse response, CXFResponseCallback callback) {
contextualConsumer.accept(response, callback);
}
}
{code}
Could you perhaps draft a CXF pull request so that I can check that it really
works?
> Allow creating a custom CXFHttpAsyncResponseConsumer
>
>
> Key: CXF-8911
> URL: https://issues.apache.org/jira/browse/CXF-8911
> Project: CXF
> Issue Type: New Feature
>Reporter: Peter Palaga
>Priority: Major
>
> We recently got a [bug
> report|https://github.com/quarkiverse/quarkus-cxf/issues/947] in Quarkus CXF
> complaining about non-working context propagation with CXF HC5 client.
> The problem was that if the client is called in context of a Quarkus REST
> endpoint, whose vert.x thread has the request context setup properly, the
> request scoped beans are then not accessible e.g. from
> ContainerRequestFilters which run in in a different thread.
> To make it work, we would need wrap the creation of
> CXFHttpAsyncResponseConsumer in some code storing the context of the creation
> thread into a wrapping method that can then be executed by some other thread.
> I was able to do this by overriding some default classes. What I did can be
> seen around here:
> https://github.com/quarkiverse/quarkus-cxf/pull/950/files#diff-568a3d75d004f9f41c6130854755ebb2beae2f30308cc45aa98492d09bac2ecc
> This solution is by no means elegant and I wonder whether it would be
> feasible to implement some new API to allow creating custom
> CXFHttpAsyncResponseConsumers?
> Maybe we could introduce some kind of CXFHttpAsyncResponseConsumerFactory?
> I am quite new to CXF internals, so I'd be thankful for any hints how to
> proceed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CXF-8911) Allow creating a custom CXFHttpAsyncResponseConsumer
[
https://issues.apache.org/jira/browse/CXF-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782899#comment-17782899
]
Peter Palaga edited comment on CXF-8911 at 11/4/23 3:52 PM:
Sorry for the late response and thanks for the ideas, [~reta] and [~dufoli]!
{quote}
{code}
public interface AsyncResponseListenerFactory {
AsyncResponseListener create();
}
public interface AsyncResponseListener {
void onBeforeReceived(HttpResponse response);
void onAfterReceived(HttpResponse response);
}
CXFResponseCallback responseCallback = new CXFResponseCallback() {
@Override
public void responseReceived(HttpResponse response) {
listener.onBeforeReceived(response);
setHttpResponse(response);
listener.onAfterReceived(response);
}
};
{code}
{quote}
I think this would not work, because I need to "be on the stack" of the code
called by {{setHttpResponse(response);}}.
But your earlier proposal with {{interface AsyncResponseCallbackFactory}} would
work. I could do something like
{code}
class AsyncResponseCallbackFactory implements AsyncResponseCallbackFactory {
AsyncResponseCallback create() {
ThreadContext threadContext =
Arc.container().select(ThreadContext.class).get();
/*
* We need to call this threadContext.contextualConsumer() here in the
constructor to store the context
* because consumeResponse() is called from another thread where the
context is not available anymore
*/
BiConsumer contextualConsumer =
threadContext.contextualConsumer(
(HttpResponse response, CXFResponseCallback callback)
-> callback.responseReceived(response));
return new MyAsyncResponseCallback(contextualConsumer);
}
}
class MyAsyncResponseCallback implements AsyncResponseCallback {
final BiConsumer contextualConsumer;
MyAsyncResponseCallback(BiConsumer
contextualConsumer) {
this.contextualConsumer = contextualConsumer;
}
void responseReceived(HttpResponse response, CXFResponseCallback callback) {
contextualConsumer.accept(response, callback);
}
}
{code}
Could you perhaps draft a CXF pull request so that I can check that it really
works?
was (Author: ppalaga):
Sorry for the late response and thanks for the ideas, [~reta] and [~dufoli]!
{quote}
{code}
public interface AsyncResponseListenerFactory {
AsyncResponseListener create();
}
public interface AsyncResponseListener {
void onBeforeReceived(HttpResponse response);
void onAfterReceived(HttpResponse response);
}
CXFResponseCallback responseCallback = new CXFResponseCallback() {
@Override
public void responseReceived(HttpResponse response) {
listener.onBeforeReceived(response);
setHttpResponse(response);
listener.onAfterReceived(response);
}
};
{code}
{quote}
I think this would not work, because I need to "be on the stack" of the code
called by {{setHttpResponse(response);}}.
But your earlier proposal with {{interface AsyncResponseCallbackFactory} }}
would work. I could do something like
{code}
class AsyncResponseCallbackFactory implements AsyncResponseCallbackFactory {
AsyncResponseCallback create() {
ThreadContext threadContext =
Arc.container().select(ThreadContext.class).get();
/*
* We need to call this threadContext.contextualConsumer() here in the
constructor to store the context
* because consumeResponse() is called from another thread where the
context is not available anymore
*/
BiConsumer contextualConsumer =
threadContext.contextualConsumer(
(HttpResponse response, CXFResponseCallback callback)
-> callback.responseReceived(response));
return new MyAsyncResponseCallback(contextualConsumer);
}
}
class MyAsyncResponseCallback implements AsyncResponseCallback {
final BiConsumer contextualConsumer;
MyAsyncResponseCallback(BiConsumer
contextualConsumer) {
this.contextualConsumer = contextualConsumer;
}
void responseReceived(HttpResponse response, CXFResponseCallback callback) {
contextualConsumer.accept(response, callback);
}
}
{code}
Could you perhaps draft a CXF pull request so that I can check that it really
works?
> Allow creating a custom CXFHttpAsyncResponseConsumer
>
>
> Key: CXF-8911
> URL: https://
[jira] [Commented] (CXF-8940) ws-security.must-understand works only if security.enable.streaming is true
[
https://issues.apache.org/jira/browse/CXF-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17782895#comment-17782895
]
Peter Palaga commented on CXF-8940:
---
Thanks for fixing this [~ffang]! The
{{io.quarkiverse.cxf.it.security.policy.UsernameTokenSecurityPolicyTest.helloUsernameTokenNoMustUnderstand()}}
in Quarkus CXF is passing with your patch applied.
> ws-security.must-understand works only if security.enable.streaming is true
> ---
>
> Key: CXF-8940
> URL: https://issues.apache.org/jira/browse/CXF-8940
> Project: CXF
> Issue Type: Bug
>Reporter: Peter Palaga
>Assignee: Freeman Yue Fang
>Priority: Major
> Fix For: 3.5.8, 3.6.3, 4.0.4
>
>
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git
> cd quarkus-cxf
> git checkout CXF-8940
> mvnd clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
> ...
> [ERROR]
> UsernameTokenSecurityPolicyTest>AbstractUsernameTokenSecurityPolicyTest.helloUsernameTokenNoMustUnderstand:180
>
> Expecting actual:
> "REQ_OUT
> Address: https://localhost:8444/services/helloUsernameToken
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 03fe3642-ab5b-4b85-b712-b8ed107f5a71
> ServiceName: UsernameTokenPolicyHelloService
> PortName: UsernameTokenPolicyHelloServicePort
> PortTypeName: UsernameTokenPolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="UsernameToken-4e64841c-ad35-48fd-b7ee-70e5f978e098">
> cxf-user
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText";>secret
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary";>5rs0Ra3q0FPLXFguajlTwQ==
> 2023-10-05T22:40:54.436Z
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/";>
> helloUsernameTokenNoMustUnderstand
>
>
>
> "
> not to contain:
> "soap:mustUnderstand="1""
> {code}
> Running the same logic with
> {{quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.enable.streaming
> = true}} works as expected:
> {code}
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyStaxTest#helloUsernameTokenNoMustUnderstand
> ...
> BUILD SUCCESS
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CXF-8949) Move CxfMessageHeadersRelayTest to camel-cxf-soap
[ https://issues.apache.org/jira/browse/CXF-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Palaga closed CXF-8949. - Resolution: Invalid This is where I should have created it: https://issues.apache.org/jira/browse/CAMEL-20040 > Move CxfMessageHeadersRelayTest to camel-cxf-soap > - > > Key: CXF-8949 > URL: https://issues.apache.org/jira/browse/CXF-8949 > Project: CXF > Issue Type: Bug >Reporter: Peter Palaga >Priority: Major > > The named test currently lives under > [camel-cxf-spring-soap|https://github.com/apache/camel/blob/0e26ffa824b7529fb916a53c327d7daeb78205ed/components/camel-cxf/camel-cxf-spring-soap/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java#L731CxfMessageHeadersRelayTest] > but there does not seem to be anything Spring specific in the test. Moreover > it is cited on the CXF component page > https://camel.apache.org/components/4.0.x/cxf-component.html#_how_to_get_and_set_soap_headers_in_pojo_mode. > > We should attempt to move the test to > [camel-cxf-soap|https://github.com/apache/camel/tree/main/components/camel-cxf/camel-cxf-soap] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8949) Move CxfMessageHeadersRelayTest to camel-cxf-soap
[ https://issues.apache.org/jira/browse/CXF-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17779075#comment-17779075 ] Peter Palaga commented on CXF-8949: --- Oh, I am so sorry for the noise. Of course this belongs to Camel. > Move CxfMessageHeadersRelayTest to camel-cxf-soap > - > > Key: CXF-8949 > URL: https://issues.apache.org/jira/browse/CXF-8949 > Project: CXF > Issue Type: Bug >Reporter: Peter Palaga >Priority: Major > > The named test currently lives under > [camel-cxf-spring-soap|https://github.com/apache/camel/blob/0e26ffa824b7529fb916a53c327d7daeb78205ed/components/camel-cxf/camel-cxf-spring-soap/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java#L731CxfMessageHeadersRelayTest] > but there does not seem to be anything Spring specific in the test. Moreover > it is cited on the CXF component page > https://camel.apache.org/components/4.0.x/cxf-component.html#_how_to_get_and_set_soap_headers_in_pojo_mode. > > We should attempt to move the test to > [camel-cxf-soap|https://github.com/apache/camel/tree/main/components/camel-cxf/camel-cxf-soap] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8949) Move CxfMessageHeadersRelayTest to camel-cxf-soap
Peter Palaga created CXF-8949: - Summary: Move CxfMessageHeadersRelayTest to camel-cxf-soap Key: CXF-8949 URL: https://issues.apache.org/jira/browse/CXF-8949 Project: CXF Issue Type: Bug Reporter: Peter Palaga The named test currently lives under [camel-cxf-spring-soap|https://github.com/apache/camel/blob/0e26ffa824b7529fb916a53c327d7daeb78205ed/components/camel-cxf/camel-cxf-spring-soap/src/test/java/org/apache/camel/component/cxf/soap/headers/CxfMessageHeadersRelayTest.java#L731CxfMessageHeadersRelayTest] but there does not seem to be anything Spring specific in the test. Moreover it is cited on the CXF component page https://camel.apache.org/components/4.0.x/cxf-component.html#_how_to_get_and_set_soap_headers_in_pojo_mode. We should attempt to move the test to [camel-cxf-soap|https://github.com/apache/camel/tree/main/components/camel-cxf/camel-cxf-soap] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8940) ws-security.must-understand works only if security.enable.streaming is true
[
https://issues.apache.org/jira/browse/CXF-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17775302#comment-17775302
]
Peter Palaga commented on CXF-8940:
---
I can see WSSecurityInterceptorProvider being created and registered at
PolicyInterceptorProviderRegistryImpl, but
WSSecurityInterceptorProvider.getOutInterceptors() is never called. Is that
perhaps because mustUnderstand is actually not policy driven and there is no
qname through which it could be retrieved from the registry?
> ws-security.must-understand works only if security.enable.streaming is true
> ---
>
> Key: CXF-8940
> URL: https://issues.apache.org/jira/browse/CXF-8940
> Project: CXF
> Issue Type: Bug
>Reporter: Peter Palaga
>Priority: Major
>
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git
> cd quarkus-cxf
> git checkout CXF-8940
> mvnd clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
> ...
> [ERROR]
> UsernameTokenSecurityPolicyTest>AbstractUsernameTokenSecurityPolicyTest.helloUsernameTokenNoMustUnderstand:180
>
> Expecting actual:
> "REQ_OUT
> Address: https://localhost:8444/services/helloUsernameToken
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 03fe3642-ab5b-4b85-b712-b8ed107f5a71
> ServiceName: UsernameTokenPolicyHelloService
> PortName: UsernameTokenPolicyHelloServicePort
> PortTypeName: UsernameTokenPolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="UsernameToken-4e64841c-ad35-48fd-b7ee-70e5f978e098">
> cxf-user
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText";>secret
> EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary";>5rs0Ra3q0FPLXFguajlTwQ==
> 2023-10-05T22:40:54.436Z
>
>
>
>
> http://policy.security.it.cxf.quarkiverse.io/";>
> helloUsernameTokenNoMustUnderstand
>
>
>
> "
> not to contain:
> "soap:mustUnderstand="1""
> {code}
> Running the same logic with
> {{quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.enable.streaming
> = true}} works as expected:
> {code}
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyStaxTest#helloUsernameTokenNoMustUnderstand
> ...
> BUILD SUCCESS
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8940) ws-security.must-understand works only if security.enable.streaming is true
[
https://issues.apache.org/jira/browse/CXF-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Palaga updated CXF-8940:
--
Description:
I am unfortunately not sure at all how to reproduce this with plain CXF. If a
test is required to demonstrate the issue, I'd be thankful for pointing me to
an existing test I could adapt.
I am able to reproduce this with quarkus-cxf - here are the steps to reproduce:
{code}
git clone g...@github.com:ppalaga/quarkus-cxf.git
cd quarkus-cxf
git checkout CXF-8940
mvnd clean install -DskipTests -Dquarkus.build.skip
cd integration-tests/ws-security-policy
mvnd clean test
-Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
...
[ERROR]
UsernameTokenSecurityPolicyTest>AbstractUsernameTokenSecurityPolicyTest.helloUsernameTokenNoMustUnderstand:180
Expecting actual:
"REQ_OUT
Address: https://localhost:8444/services/helloUsernameToken
HttpMethod: POST
Content-Type: text/xml
ExchangeId: 03fe3642-ab5b-4b85-b712-b8ed107f5a71
ServiceName: UsernameTokenPolicyHelloService
PortName: UsernameTokenPolicyHelloServicePort
PortTypeName: UsernameTokenPolicyHelloService
Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
Payload: http://schemas.xmlsoap.org/soap/envelope/";>
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
soap:mustUnderstand="1">
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
wsu:Id="UsernameToken-4e64841c-ad35-48fd-b7ee-70e5f978e098">
cxf-user
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText";>secret
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary";>5rs0Ra3q0FPLXFguajlTwQ==
2023-10-05T22:40:54.436Z
http://policy.security.it.cxf.quarkiverse.io/";>
helloUsernameTokenNoMustUnderstand
"
not to contain:
"soap:mustUnderstand="1""
{code}
Running the same logic with
{{quarkus.cxf.client.helloUsernameTokenNoMustUnderstand.security.enable.streaming
= true}} works as expected:
{code}
mvnd clean test
-Dtest=UsernameTokenSecurityPolicyStaxTest#helloUsernameTokenNoMustUnderstand
...
BUILD SUCCESS
{code}
was:
I am unfortunately not sure at all how to reproduce this with plain CXF. If a
test is required to demonstrate the issue, I'd be thankful for pointing me to
an existing test I could adapt.
I am able to reproduce this with quarkus-cxf - here are the steps to reproduce:
{code}
git clone g...@github.com:ppalaga/quarkus-cxf.git
cd quarkus-cxf
mvnd clean install -DskipTests -Dquarkus.build.skip
cd integration-tests/ws-security-policy
mvnd clean test
-Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
{code}
> ws-security.must-understand works only if security.enable.streaming is true
> ---
>
> Key: CXF-8940
> URL: https://issues.apache.org/jira/browse/CXF-8940
> Project: CXF
> Issue Type: Bug
>Reporter: Peter Palaga
>Priority: Major
>
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git
> cd quarkus-cxf
> git checkout CXF-8940
> mvnd clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
> ...
> [ERROR]
> UsernameTokenSecurityPolicyTest>AbstractUsernameTokenSecurityPolicyTest.helloUsernameTokenNoMustUnderstand:180
>
> Expecting actual:
> "REQ_OUT
> Address: https://localhost:8444/services/helloUsernameToken
> HttpMethod: POST
> Content-Type: text/xml
> ExchangeId: 03fe3642-ab5b-4b85-b712-b8ed107f5a71
> ServiceName: UsernameTokenPolicyHelloService
> PortName: UsernameTokenPolicyHelloServicePort
> PortTypeName: UsernameTokenPolicyHelloService
> Headers: {SOAPAction="", Accept=*/*, Connection=Keep-Alive}
> Payload: xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";>
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
> soap:mustUnderstand="1">
>xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
> wsu:Id="UsernameToken-4e64841c-ad35-48fd-b7ee-70e5f978e098">
> cxf-user
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText";>secret
> EncodingType="http://docs.oasis-open.org/wss/2004/0
[jira] [Updated] (CXF-8940) ws-security.must-understand works only if security.enable.streaming is true
[
https://issues.apache.org/jira/browse/CXF-8940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Palaga updated CXF-8940:
--
Description:
I am unfortunately not sure at all how to reproduce this with plain CXF. If a
test is required to demonstrate the issue, I'd be thankful for pointing me to
an existing test I could adapt.
I am able to reproduce this with quarkus-cxf - here are the steps to reproduce:
{code}
git clone g...@github.com:ppalaga/quarkus-cxf.git
cd quarkus-cxf
mvnd clean install -DskipTests -Dquarkus.build.skip
cd integration-tests/ws-security-policy
mvnd clean test
-Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
{code}
was:
I am unfortunately not sure at all how to reproduce this with plain CXF. If a
test is required to demonstrate the issue, I'd be thankful for pointing me to
an existing test I could adapt.
I am able to reproduce this with quarkus-cxf - the steps will follow
> ws-security.must-understand works only if security.enable.streaming is true
> ---
>
> Key: CXF-8940
> URL: https://issues.apache.org/jira/browse/CXF-8940
> Project: CXF
> Issue Type: Bug
>Reporter: Peter Palaga
>Priority: Major
>
> I am unfortunately not sure at all how to reproduce this with plain CXF. If a
> test is required to demonstrate the issue, I'd be thankful for pointing me to
> an existing test I could adapt.
> I am able to reproduce this with quarkus-cxf - here are the steps to
> reproduce:
> {code}
> git clone g...@github.com:ppalaga/quarkus-cxf.git
> cd quarkus-cxf
> mvnd clean install -DskipTests -Dquarkus.build.skip
> cd integration-tests/ws-security-policy
> mvnd clean test
> -Dtest=UsernameTokenSecurityPolicyTest#helloUsernameTokenNoMustUnderstand
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CXF-8940) ws-security.must-understand works only if security.enable.streaming is true
Peter Palaga created CXF-8940: - Summary: ws-security.must-understand works only if security.enable.streaming is true Key: CXF-8940 URL: https://issues.apache.org/jira/browse/CXF-8940 Project: CXF Issue Type: Bug Reporter: Peter Palaga I am unfortunately not sure at all how to reproduce this with plain CXF. If a test is required to demonstrate the issue, I'd be thankful for pointing me to an existing test I could adapt. I am able to reproduce this with quarkus-cxf - the steps will follow -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (CXF-8885) HttpClient SelectorManager threads run indefinitely causing OOM
[ https://issues.apache.org/jira/browse/CXF-8885 ] Peter Palaga deleted comment on CXF-8885: --- was (Author: ppalaga): This is issue could by summed up as follows: if an application creates clients more frequently (e.g. per request) than once at startup, then the application will eventually crash due to an OOM. IMO, this fulfills the definition of DoS attack vector. I wonder whether the CXF team should not request a CVE number for this issue? > HttpClient SelectorManager threads run indefinitely causing OOM > --- > > Key: CXF-8885 > URL: https://issues.apache.org/jira/browse/CXF-8885 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 4.0.0, 3.6.0 >Reporter: Cardo Eggert >Priority: Major > Attachments: image (5).png > > > Probably caused by https://issues.apache.org/jira/browse/CXF-8840 . > Started to notice that when updating from 3.5.x to 3.6.0 that our servers > started getting OOM. Noticed from the resulting logs that a lot of threads > were active that were in the format > HttpClient--SelectorManager > when reverted to 3.5.6 then it did not occur anymore. > > Tried to use VirtualVM when debugging it and saw when the thread was started, > it never died, basically meaning that it ran indefinitely. OOM happened when > there were about over 1000 of these threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CXF-8885) HttpClient SelectorManager threads run indefinitely causing OOM
[ https://issues.apache.org/jira/browse/CXF-8885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17761791#comment-17761791 ] Peter Palaga commented on CXF-8885: --- This is issue could by summed up as follows: if an application creates clients more frequently (e.g. per request) than once at startup, then the application will eventually crash due to an OOM. IMO, this fulfills the definition of DoS attack vector. I wonder whether the CXF team should not request a CVE number for this issue? > HttpClient SelectorManager threads run indefinitely causing OOM > --- > > Key: CXF-8885 > URL: https://issues.apache.org/jira/browse/CXF-8885 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 4.0.0, 3.6.0 >Reporter: Cardo Eggert >Priority: Major > Attachments: image (5).png > > > Probably caused by https://issues.apache.org/jira/browse/CXF-8840 . > Started to notice that when updating from 3.5.x to 3.6.0 that our servers > started getting OOM. Noticed from the resulting logs that a lot of threads > were active that were in the format > HttpClient--SelectorManager > when reverted to 3.5.6 then it did not occur anymore. > > Tried to use VirtualVM when debugging it and saw when the thread was started, > it never died, basically meaning that it ran indefinitely. OOM happened when > there were about over 1000 of these threads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8911) Allow creating a custom CXFHttpAsyncResponseConsumer
Peter Palaga created CXF-8911: - Summary: Allow creating a custom CXFHttpAsyncResponseConsumer Key: CXF-8911 URL: https://issues.apache.org/jira/browse/CXF-8911 Project: CXF Issue Type: New Feature Reporter: Peter Palaga We recently got a [bug report|https://github.com/quarkiverse/quarkus-cxf/issues/947] in Quarkus CXF complaining about non-working context propagation with CXF HC5 client. The problem was that if the client is called in context of a Quarkus REST endpoint, whose vert.x thread has the request context setup properly, the request scoped beans are then not accessible e.g. from ContainerRequestFilters which run in in a different thread. To make it work, we would need wrap the creation of CXFHttpAsyncResponseConsumer in some code storing the context of the creation thread into a wrapping method that can then be executed by some other thread. I was able to do this by overriding some default classes. What I did can be seen around here: https://github.com/quarkiverse/quarkus-cxf/pull/950/files#diff-568a3d75d004f9f41c6130854755ebb2beae2f30308cc45aa98492d09bac2ecc This solution is by no means elegant and I wonder whether it would be feasible to implement some new API to allow creating custom CXFHttpAsyncResponseConsumers? Maybe we could introduce some kind of CXFHttpAsyncResponseConsumerFactory? I am quite new to CXF internals, so I'd be thankful for any hints how to proceed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CXF-8834) "Operation [{.../wsdl}Issue] already exists" when calling JaxWsServerFactoryBean.create() for SecurityTokenService
Peter Palaga created CXF-8834:
-
Summary: "Operation [{.../wsdl}Issue] already exists" when calling
JaxWsServerFactoryBean.create() for SecurityTokenService
Key: CXF-8834
URL: https://issues.apache.org/jira/browse/CXF-8834
Project: CXF
Issue Type: Bug
Components: STS
Affects Versions: 4.0.0
Reporter: Peter Palaga
In quarkus-cxf, we are executing the following snippet
{code}
JaxWsServerFactoryBean factoryBean = new JaxWsServerFactoryBean();
factoryBean.setServiceClass(Thread.currentThread().getContextClassLoader().loadClass(sei));
factoryBean.setAddress(path);
Server server = factoryBean.create();
{code}
for all service interfaces available in the class path of an application. We do
it at build time, for the sake of generating all necessary ancillary classes.
When doing this for
{{org.apache.cxf.ws.security.sts.provider.SecurityTokenService}}, the following
exception is thrown:
{code}
java.lang.IllegalArgumentException: An operation with name
[{http://docs.oasis-open.org/ws-sx/ws-trust/200512/wsdl}Issue] already exists
in this service
at
org.apache.cxf.service.model.InterfaceInfo.addOperation(InterfaceInfo.java:78)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createOperation(ReflectionServiceFactoryBean.java:1008)
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.createOperation(JaxWsServiceFactoryBean.java:631)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.createInterface(ReflectionServiceFactoryBean.java:1000)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromClass(ReflectionServiceFactoryBean.java:460)
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.buildServiceFromClass(JaxWsServiceFactoryBean.java:693)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:529)
at
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:262)
at
org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199)
at
org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103)
at
org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:168)
at
org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:210)
at
io.quarkiverse.cxf.deployment.CxfDeploymentUtils.createServer(CxfDeploymentUtils.java:42)
at
io.quarkiverse.cxf.deployment.QuarkusCxfProcessor.lambda$generateClasses$2(QuarkusCxfProcessor.java:213)
...
{code}
This is caused by the fact that there are two methods annotated with
{{@WebMethod(operationName = "Issue")}} in
{{org.apache.cxf.ws.security.sts.provider.SecurityTokenService}}:
{code}
@WebResult(name = "RequestSecurityTokenResponseCollection",
targetNamespace =
"http://docs.oasis-open.org/ws-sx/ws-trust/200512";,
partName = "responseCollection")
@Action(input =
"http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue";,
output =
"http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal";)
@WebMethod(operationName = "Issue")
RequestSecurityTokenResponseCollectionType issue(
@WebParam(partName = "request",
name = "RequestSecurityToken",
targetNamespace =
"http://docs.oasis-open.org/ws-sx/ws-trust/200512";)
RequestSecurityTokenType request
);
@WebResult(name = "RequestSecurityTokenResponse",
targetNamespace =
"http://docs.oasis-open.org/ws-sx/ws-trust/200512";,
partName = "response")
@Action(input =
"http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue";,
output =
"http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTRC/IssueFinal";)
@WebMethod(operationName = "Issue")
RequestSecurityTokenResponseType issueSingle(
@WebParam(partName = "request",
name = "RequestSecurityToken",
targetNamespace =
"http://docs.oasis-open.org/ws-sx/ws-trust/200512";)
RequestSecurityTokenType request
);
{code}
I wonder whether one of the operationNames in SecurityTokenService needs to be
changed?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
