[jira] [Created] (CXF-7605) RequireDerivedKeys policy is not respected
Lukas created CXF-7605:
--
Summary: RequireDerivedKeys policy is not respected
Key: CXF-7605
URL: https://issues.apache.org/jira/browse/CXF-7605
Project: CXF
Issue Type: Bug
Components: Soap Binding, WS-* Components
Affects Versions: 3.1.15, 3.2.2
Environment: * cxf-rt-frontend-jaxws
* cxf-rt-frontend-jaxrs
* cxf-rt-transports-http
* cxf-rt-rs-client
* cxf-rt-rs-service-description
* cxf-rt-ws-security
* cxf-tools-common
* cxf-rt-ws-policy
Reporter: Lukas
Attachments: code.java, full_wsdl.wsdl, policy_fragment.xml
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]
}}(=="SupportEndorsingTokens") contain a nested Policy setting
{{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
Code and wsdl worked with cxf 3.1.12.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is not respected
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Description:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1] }}
(=="SupportEndorsingTokens") contain a nested Policy setting
{{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
Code and wsdl worked with cxf 3.1.12.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
was:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]
}}(=="SupportEndorsingTokens") contain a nested Policy setting
{{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
Code and wsdl worked with cxf 3.1.12.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
> RequireDerivedKeys policy is not respected
> --
>
> Key: CXF-7605
> URL: https://issues.apache.org/jira/browse/CXF-7605
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding, WS-* Components
>Affects Versions: 3.1.15, 3.2.2
> Environment: * cxf-rt-frontend-jaxws
> * cxf-rt-frontend-jaxrs
> * cxf-rt-transports-http
> * cxf-rt-rs-client
> * cxf-rt-rs-service-description
> * cxf-rt-ws-security
> * cxf-tools-common
> * cxf-rt-ws-policy
>Reporter: Lukas
> Attachments: code.java, full_wsdl.wsdl, policy_fragment.xml
>
>
> CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
> signature, while ws-policy states that derived keys are required
> ({{}} in {{effective Policy}}).
> The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
> task.
> Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the
> contents of
> {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1] }}
> (=="SupportEndorsingTokens") contain a nested Policy setting
> {{RequireDerivedKeys}}.
> This reflects the structure and contents of the attached policy (see
> policy_fragment.xml).
> CXF correctly embeds a SAML Token as requested by the policy and signs using
> a symmetric key (got by WS-Secureconversation / WS-Trust previously) - both
> steps are defined in the attached policy.
> CXF should however, sign with a key *derived* from said symmetric key,
> specified by {{}}, this step is ignored, thus
> resulting an a request that does not adhere to the policy.
> Code and wsdl worked with cxf 3.1.12.
> Attached are:
> * full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
> of irrelevant endpoints and domain names)
> * code.java - code snippet demonstrating the use-case
> * policy_fragment.xml - the policy to save looking for it in the wsdl
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is not respected
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Description:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
Code and wsdl worked with cxf 3.1.12.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
was:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1] }}
(=="SupportEndorsingTokens") contain a nested Policy setting
{{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
Code and wsdl worked with cxf 3.1.12.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
> RequireDerivedKeys policy is not respected
> --
>
> Key: CXF-7605
> URL: https://issues.apache.org/jira/browse/CXF-7605
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding, WS-* Components
>Affects Versions: 3.1.15, 3.2.2
> Environment: * cxf-rt-frontend-jaxws
> * cxf-rt-frontend-jaxrs
> * cxf-rt-transports-http
> * cxf-rt-rs-client
> * cxf-rt-rs-service-description
> * cxf-rt-ws-security
> * cxf-tools-common
> * cxf-rt-ws-policy
>Reporter: Lukas
> Attachments: code.java, full_wsdl.wsdl, policy_fragment.xml
>
>
> CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
> signature, while ws-policy states that derived keys are required
> ({{}} in {{effective Policy}}).
> The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
> task.
> Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the
> contents of
> {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
> (SupportEndorsingTokens) contain a nested Policy setting
> {{RequireDerivedKeys}}.
> This reflects the structure and contents of the attached policy (see
> policy_fragment.xml).
> CXF correctly embeds a SAML Token as requested by the policy and signs using
> a symmetric key (got by WS-Secureconversation / WS-Trust previously) - both
> steps are defined in the attached policy.
> CXF should however, sign with a key *derived* from said symmetric key,
> specified by {{}}, this step is ignored, thus
> resulting an a request that does not adhere to the policy.
> Code and wsdl worked with cxf 3.1.12.
> Attached are:
> * full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
> of irrelevant endpoints and domain names)
> * code.java - code snippet demonstrating the use-case
> * policy_fragment.xml - the policy to save looking for it in the wsdl
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is not respected
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Description:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
Code and wsdl worked with cxf 3.1.12.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
was:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
Code and wsdl worked with cxf 3.1.12.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
> RequireDerivedKeys policy is not respected
> --
>
> Key: CXF-7605
> URL: https://issues.apache.org/jira/browse/CXF-7605
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding, WS-* Components
>Affects Versions: 3.1.15, 3.2.2
> Environment: * cxf-rt-frontend-jaxws
> * cxf-rt-frontend-jaxrs
> * cxf-rt-transports-http
> * cxf-rt-rs-client
> * cxf-rt-rs-service-description
> * cxf-rt-ws-security
> * cxf-tools-common
> * cxf-rt-ws-policy
>Reporter: Lukas
> Attachments: code.java, full_wsdl.wsdl, policy_fragment.xml
>
>
> CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
> signature, while ws-policy states that derived keys are required
> ({{}} in {{effective Policy}}).
> The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
> task.
> Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the
> contents of
> {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
> (SupportEndorsingTokens) contain a nested Policy setting
> {{RequireDerivedKeys}}.
> This reflects the structure and contents of the attached policy (see
> policy_fragment.xml).
> CXF correctly embeds a SAML Token as requested by the policy and signs using
> a symmetric key (got by WS-Secureconversation / WS-Trust previously) - both
> steps are defined in the attached policy.
> CXF should however, sign with a key *derived* from said symmetric key,
> specified by {{}}, this step is ignored, thus
> resulting an a request that does not adhere to the policy.
> The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
> with the RequestDerivedKeys Assertion set to asserted=true.
> Code and wsdl worked with cxf 3.1.12.
> Attached are:
> * full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
> of irrelevant endpoints and domain names)
> * code.java - code snippet demonstrating the use-case
> * policy_fragment.xml - the policy to save looking for it in the wsdl
-
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is not respected
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Description:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
Code and wsdl worked with cxf 3.1.12.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
was:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
Code and wsdl worked with cxf 3.1.12.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
> RequireDerivedKeys policy is not respected
> --
>
> Key: CXF-7605
> URL: https://issues.apache.org/jira/browse/CXF-7605
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding, WS-* Components
>Affects Versions: 3.1.15, 3.2.2
> Environment: * cxf-rt-frontend-jaxws
> * cxf-rt-frontend-jaxrs
> * cxf-rt-transports-http
> * cxf-rt-rs-client
> * cxf-rt-rs-service-description
> * cxf-rt-ws-security
> * cxf-tools-common
> * cxf-rt-ws-policy
>Reporter: Lukas
> Attachments: code.java, full_wsdl.wsdl, policy_fragment.xml
>
>
> CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
> signature, while ws-policy states that derived keys are required
> ({{}} in {{effective Policy}}).
> The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
> task.
> Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the
> contents of
> {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
> (SupportEndorsingTokens) contain a nested Policy setting
> {{RequireDerivedKeys}}.
> This reflects the structure and contents of the attached policy (see
> policy_fragment.xml).
> CXF correctly embeds a SAML Token as requested by the policy and signs using
> a symmetric key (got by WS-Secureconversation / WS-Trust previously) - both
> steps are defined in the attached policy.
> CXF should however, sign with a key *derived* from said symmetric key,
> specified by {{}},
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is not respected
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Description:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
*Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
classpath simulataneously - so i assume key derivation worked for the version
packed in the bundle.*
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
was:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
Code and wsdl worked with cxf 3.1.12.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
> RequireDerivedKeys policy is not respected
> --
>
> Key: CXF-7605
> URL: https://issues.apache.org/jira/browse/CXF-7605
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding, WS-* Components
>Affects Versions: 3.1.15, 3.2.2
> Environment: * cxf-rt-frontend-jaxws
> * cxf-rt-frontend-jaxrs
> * cxf-rt-transports-http
> * cxf-rt-rs-client
> * cxf-rt-rs-service-description
> * cxf-rt-ws-security
> * cxf-tools-common
> * cxf-rt-ws-policy
>Reporter: Lukas
> Attachments: code.java, full_wsdl.wsdl, policy_fragment.xml
>
>
> CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
> signature, while ws-policy states that derived keys are required
> ({{}} in {{effective Policy}}).
> The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
> task.
> Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the
> contents of
> {{org
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is not respected
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Description:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
*Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
classpath simulataneously - so i assume key derivation happened in the version
packed in the bundle.*
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
was:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
*Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
classpath simulataneously - so i assume key derivation worked for the version
packed in the bundle.*
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
> RequireDerivedKeys policy is not respected
> --
>
> Key: CXF-7605
> URL: https://issues.apache.org/jira/browse/CXF-7605
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding, WS-* Components
>Affects Versions: 3.1.15, 3.2.2
> Environment: * cxf-rt-frontend-jaxws
> * cxf-rt-frontend-jaxrs
> * cxf-rt-transports-http
> * cxf-rt-rs-client
> * cxf-rt-rs-service-description
> * cxf-rt-ws-security
> * cxf-tools-common
> * cxf-rt-ws-policy
>Reporter: Lukas
> Attachments: code.java, full_wsdl.wsdl, policy_fragment.xml
>
>
> CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
> signature, while ws-policy states that derived keys are required
> ({{}} in {{effective Policy}}).
> The Policy is embedded in the wsdl that i
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is not respected
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Attachment: build.gradle.working
build.gralde.failing
working and failing gralde files added
> RequireDerivedKeys policy is not respected
> --
>
> Key: CXF-7605
> URL: https://issues.apache.org/jira/browse/CXF-7605
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding, WS-* Components
>Affects Versions: 3.1.15, 3.2.2
> Environment: * cxf-rt-frontend-jaxws
> * cxf-rt-frontend-jaxrs
> * cxf-rt-transports-http
> * cxf-rt-rs-client
> * cxf-rt-rs-service-description
> * cxf-rt-ws-security
> * cxf-tools-common
> * cxf-rt-ws-policy
>Reporter: Lukas
> Attachments: build.gradle.working, build.gralde.failing, code.java,
> full_wsdl.wsdl, policy_fragment.xml
>
>
> CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
> signature, while ws-policy states that derived keys are required
> ({{}} in {{effective Policy}}).
> The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
> task.
> Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the
> contents of
> {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
> (SupportEndorsingTokens) contain a nested Policy setting
> {{RequireDerivedKeys}}.
> This reflects the structure and contents of the attached policy (see
> policy_fragment.xml).
> CXF correctly embeds a SAML Token as requested by the policy and signs using
> a symmetric key (got by WS-Secureconversation / WS-Trust previously) - both
> steps are defined in the attached policy.
> CXF should however, sign with a key *derived* from said symmetric key,
> specified by {{}}, this step is ignored, thus
> resulting an a request that does not adhere to the policy.
> The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
> with the RequestDerivedKeys Assertion set to asserted=true.
> {{WSS4JStaxOutInterceptor, line 159}}
> {{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
>
> {{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces
> {{true}} (which is default)
> {{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
> {{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
> all other properties related to derived keys are null / 0 / their defaults.
> *Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
> classpath simulataneously - so i assume key derivation happened in the
> version packed in the bundle.*
> *build.gradle.working *results in a soap envelope with an hmac signature on
> the timestamp, produced by derivating a key from the
> ws-secureconversationkey, containing this element:
> {{ xmlns:wsc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512";
> wsu:Id="DK-3A4FD7F484F29F6BF215154251877012"> xmlns:ns4="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd";
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
>
> ns4:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0";>
> ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID";>nstsaa9fb8cc-ccb4-4dba-b7db-aa335d216bb3024QktGO31p79qn7dhom83QNQ==}}
> *build.gradle.failing *results in a soap envelope with an hmac signature
> produced with the ws-secureconversation key. The Derived key element is
> missing, as no key is derived.
> Attached are:
> * full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
> of irrelevant endpoints and domain names)
> * code.java - code snippet demonstrating the use-case
> * policy_fragment.xml - the policy to save looking for it in the wsdl
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is not respected
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Description:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
*Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
classpath simulataneously - so i assume key derivation happened in the version
packed in the bundle.*
*build.gradle.working *results in a soap envelope with an hmac signature on the
timestamp, produced by derivating a key from the ws-secureconversationkey,
containing this element:
{{http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512";
wsu:Id="DK-3A4FD7F484F29F6BF215154251877012">http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd";
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
ns4:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0";>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID";>nstsaa9fb8cc-ccb4-4dba-b7db-aa335d216bb3024QktGO31p79qn7dhom83QNQ==}}
*build.gradle.failing *results in a soap envelope with an hmac signature
produced with the ws-secureconversation key. The Derived key element is
missing, as no key is derived.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
was:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
*Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
classpath simulataneously - so i assume key derivation happened in the version
packed in the bundle.*
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
> Requ
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is read, but not executed
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Description:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
*Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
classpath simulataneously - so i assume key derivation happened in the version
packed in the bundle.*
*build.gradle.working* results in a soap envelope with an hmac signature on the
timestamp, produced by derivating a key from the ws-secureconversationkey,
containing this element:
{{http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512";
wsu:Id="DK-3A4FD7F484F29F6BF215154251877012">http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd";
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
ns4:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0";>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID";>nstsaa9fb8cc-ccb4-4dba-b7db-aa335d216bb3024QktGO31p79qn7dhom83QNQ==}}
*build.gradle.failing* results in a soap envelope with an hmac signature
produced with the ws-secureconversation key. The Derived key element is
missing, as no key is derived.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
was:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
*Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
classpath simulataneously - so i assume key derivation happened in the version
packed in the bundle.*
*build.gradle.working *results in a soap envelope with an hmac signature on the
timestamp, produced by derivating a key from the ws-secureconversationkey,
containing this element:
{{http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512";
wsu:Id="DK-3A4FD7F48
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is read, but not executed
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Summary: RequireDerivedKeys policy is read, but not executed (was:
RequireDerivedKeys policy is not respected)
> RequireDerivedKeys policy is read, but not executed
> ---
>
> Key: CXF-7605
> URL: https://issues.apache.org/jira/browse/CXF-7605
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding, WS-* Components
>Affects Versions: 3.1.15, 3.2.2
> Environment: * cxf-rt-frontend-jaxws
> * cxf-rt-frontend-jaxrs
> * cxf-rt-transports-http
> * cxf-rt-rs-client
> * cxf-rt-rs-service-description
> * cxf-rt-ws-security
> * cxf-tools-common
> * cxf-rt-ws-policy
>Reporter: Lukas
> Attachments: build.gradle.working, build.gralde.failing, code.java,
> full_wsdl.wsdl, policy_fragment.xml
>
>
> CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
> signature, while ws-policy states that derived keys are required
> ({{}} in {{effective Policy}}).
> The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
> task.
> Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the
> contents of
> {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
> (SupportEndorsingTokens) contain a nested Policy setting
> {{RequireDerivedKeys}}.
> This reflects the structure and contents of the attached policy (see
> policy_fragment.xml).
> CXF correctly embeds a SAML Token as requested by the policy and signs using
> a symmetric key (got by WS-Secureconversation / WS-Trust previously) - both
> steps are defined in the attached policy.
> CXF should however, sign with a key *derived* from said symmetric key,
> specified by {{}}, this step is ignored, thus
> resulting an a request that does not adhere to the policy.
> The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
> with the RequestDerivedKeys Assertion set to asserted=true.
> {{WSS4JStaxOutInterceptor, line 159}}
> {{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
>
> {{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces
> {{true}} (which is default)
> {{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
> {{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
> all other properties related to derived keys are null / 0 / their defaults.
> *Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
> classpath simulataneously - so i assume key derivation happened in the
> version packed in the bundle.*
> *build.gradle.working *results in a soap envelope with an hmac signature on
> the timestamp, produced by derivating a key from the
> ws-secureconversationkey, containing this element:
> {{ xmlns:wsc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512";
> wsu:Id="DK-3A4FD7F484F29F6BF215154251877012"> xmlns:ns4="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd";
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
>
> ns4:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0";>
> ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID";>nstsaa9fb8cc-ccb4-4dba-b7db-aa335d216bb3024QktGO31p79qn7dhom83QNQ==}}
> *build.gradle.failing *results in a soap envelope with an hmac signature
> produced with the ws-secureconversation key. The Derived key element is
> missing, as no key is derived.
> Attached are:
> * full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
> of irrelevant endpoints and domain names)
> * code.java - code snippet demonstrating the use-case
> * policy_fragment.xml - the policy to save looking for it in the wsdl
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is read, but not executed
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Affects Version/s: 3.1.14
> RequireDerivedKeys policy is read, but not executed
> ---
>
> Key: CXF-7605
> URL: https://issues.apache.org/jira/browse/CXF-7605
> Project: CXF
> Issue Type: Bug
> Components: Soap Binding, WS-* Components
>Affects Versions: 3.1.14, 3.1.15, 3.2.2
> Environment: * cxf-rt-frontend-jaxws
> * cxf-rt-frontend-jaxrs
> * cxf-rt-transports-http
> * cxf-rt-rs-client
> * cxf-rt-rs-service-description
> * cxf-rt-ws-security
> * cxf-tools-common
> * cxf-rt-ws-policy
>Reporter: Lukas
> Attachments: build.gradle.working, build.gralde.failing, code.java,
> full_wsdl.wsdl, policy_fragment.xml
>
>
> CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
> signature, while ws-policy states that derived keys are required
> ({{}} in {{effective Policy}}).
> The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
> task.
> Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the
> contents of
> {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
> (SupportEndorsingTokens) contain a nested Policy setting
> {{RequireDerivedKeys}}.
> This reflects the structure and contents of the attached policy (see
> policy_fragment.xml).
> CXF correctly embeds a SAML Token as requested by the policy and signs using
> a symmetric key (got by WS-Secureconversation / WS-Trust previously) - both
> steps are defined in the attached policy.
> CXF should however, sign with a key *derived* from said symmetric key,
> specified by {{}}, this step is ignored, thus
> resulting an a request that does not adhere to the policy.
> The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
> with the RequestDerivedKeys Assertion set to asserted=true.
> {{WSS4JStaxOutInterceptor, line 159}}
> {{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
>
> {{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces
> {{true}} (which is default)
> {{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
> {{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
> all other properties related to derived keys are null / 0 / their defaults.
> *Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
> classpath simulataneously - so i assume key derivation happened in the
> version packed in the bundle.*
> *build.gradle.working* results in a soap envelope with an hmac signature on
> the timestamp, produced by derivating a key from the
> ws-secureconversationkey, containing this element:
> {{ xmlns:wsc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512";
> wsu:Id="DK-3A4FD7F484F29F6BF215154251877012"> xmlns:ns4="http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd";
>
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
>
> ns4:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0";>
> ValueType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID";>nstsaa9fb8cc-ccb4-4dba-b7db-aa335d216bb3024QktGO31p79qn7dhom83QNQ==}}
> *build.gradle.failing* results in a soap envelope with an hmac signature
> produced with the ws-secureconversation key. The Derived key element is
> missing, as no key is derived.
> Attached are:
> * full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
> of irrelevant endpoints and domain names)
> * code.java - code snippet demonstrating the use-case
> * policy_fragment.xml - the policy to save looking for it in the wsdl
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (CXF-7605) RequireDerivedKeys policy is read, but not executed
[
https://issues.apache.org/jira/browse/CXF-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas updated CXF-7605:
---
Description:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Actions cxf determines are also "TIMESTAMP" and "SAMLTOKENSIGNED", which is
not stated in the policy - it calls for TIMESTAMP and SIGNATURE (with a derived
symetric key)
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
*Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
classpath simulataneously - so i assume key derivation happened in the version
packed in the bundle.*
*build.gradle.working* results in a soap envelope with an hmac signature on the
timestamp, produced by derivating a key from the ws-secureconversationkey,
containing this element:
{{http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512";
wsu:Id="DK-3A4FD7F484F29F6BF215154251877012">http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd";
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";
ns4:TokenType="http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV2.0";>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLID";>nstsaa9fb8cc-ccb4-4dba-b7db-aa335d216bb3024QktGO31p79qn7dhom83QNQ==}}
*build.gradle.failing* results in a soap envelope with an hmac signature
produced with the ws-secureconversation key. The Derived key element is
missing, as no key is derived.
Attached are:
* full_wsdl.wsdl - the wsdl parsed by cxfs' "wsdl2java" gradle task (stripped
of irrelevant endpoints and domain names)
* code.java - code snippet demonstrating the use-case
* policy_fragment.xml - the policy to save looking for it in the wsdl
was:
CXF 3.2.2-SNAPSHOT, as well as 3.1.15-SNAPSHOT do not derive keys for hmac
signature, while ws-policy states that derived keys are required
({{}} in {{effective Policy}}).
The Policy is embedded in the wsdl that is passed to the {{wsdl2java}} gradle
task.
Inspecting the SoapMessage passed to the {{WSStaxOutInterceptor}} the contents
of {{org.apache.cxf.ws.policy.EffectivePolicy}}.{{choosenAlternative[1]}}
(SupportEndorsingTokens) contain a nested Policy setting {{RequireDerivedKeys}}.
This reflects the structure and contents of the attached policy (see
policy_fragment.xml).
CXF correctly embeds a SAML Token as requested by the policy and signs using a
symmetric key (got by WS-Secureconversation / WS-Trust previously) - both steps
are defined in the attached policy.
CXF should however, sign with a key *derived* from said symmetric key,
specified by {{}}, this step is ignored, thus
resulting an a request that does not adhere to the policy.
The {{PolicyVerificationOutInterceptor}} also recieves a Soapmessage Object
with the RequestDerivedKeys Assertion set to asserted=true.
{{WSS4JStaxOutInterceptor, line 159}}
{{OutboundWSSec outboundWSSec = WSSec.getOutboundWSSec(secProps);}}
{{outboundWSSec.securityProperties.isUseDerivedKeyForMAC()}} produces {{true}}
(which is default)
{{outboundWSSec.securityProperties.getSignatureAlgorithm()}} produces
{{http://www.w3.org/2000/09/xmldsig#hmac-sha1}}
all other properties related to derived keys are null / 0 / their defaults.
*Code works if cxf version 3.2.2-SNAPSHOT AND cxf Bundle 2.7.18 are on the
classpath simulataneously - so i assume key derivation happened in the version
packed in the bundle.*
*build.gradle.working* results in a soap envelope with an hmac signature on the
timestamp,
[jira] [Commented] (CXF-7604) Change to "Error occurred during error handling, give up!" message
[
https://issues.apache.org/jira/browse/CXF-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317008#comment-16317008
]
ASF GitHub Bot commented on CXF-7604:
-
andymc12 closed pull request #364: CXF-7604 Refine error message during error
handling
URL: https://github.com/apache/cxf/pull/364
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/core/src/main/java/org/apache/cxf/interceptor/AbstractFaultChainInitiatorObserver.java
b/core/src/main/java/org/apache/cxf/interceptor/AbstractFaultChainInitiatorObserver.java
index 629de73325e..670b73e156b 100644
---
a/core/src/main/java/org/apache/cxf/interceptor/AbstractFaultChainInitiatorObserver.java
+++
b/core/src/main/java/org/apache/cxf/interceptor/AbstractFaultChainInitiatorObserver.java
@@ -111,10 +111,10 @@ public void onMessage(Message message) {
try {
chain.doIntercept(faultMessage);
} catch (RuntimeException exc) {
-LOG.log(Level.SEVERE, "Error occurred during error handling,
give up!", exc);
+LOG.log(Level.SEVERE, "ERROR_DURING_ERROR_PROCESSING", exc);
throw exc;
} catch (Exception exc) {
-LOG.log(Level.SEVERE, "Error occurred during error handling,
give up!", exc);
+LOG.log(Level.SEVERE, "ERROR_DURING_ERROR_PROCESSING", exc);
throw new RuntimeException(exc);
}
} finally {
diff --git a/core/src/main/java/org/apache/cxf/interceptor/Messages.properties
b/core/src/main/java/org/apache/cxf/interceptor/Messages.properties
index a0f7b15212a..487243982f2 100644
--- a/core/src/main/java/org/apache/cxf/interceptor/Messages.properties
+++ b/core/src/main/java/org/apache/cxf/interceptor/Messages.properties
@@ -42,4 +42,5 @@ EXCEPTION_WHILE_WRITING_FAULT = Exception occurred while
writing fault.
EXCEPTION_WHILE_CREATING_EXCEPTION = Exception occurred while creating
exception: {0}
UNEXPECTED_WRAPPER_ELEMENT = Unexpected wrapper element {0} found. Expected
{1}.
UNEXPECTED_ELEMENT = Unexpected element {0} found. Expected {1}.
+ERROR_DURING_ERROR_PROCESSING=An unexpected error occurred during error
handling. No further error processing will occur.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Change to "Error occurred during error handling, give up!" message
> --
>
> Key: CXF-7604
> URL: https://issues.apache.org/jira/browse/CXF-7604
> Project: CXF
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.1.14, 3.2.1
>Reporter: Andy McCright
>Assignee: Andy McCright
>Priority: Minor
>
> One of our users complained about the message "Error occurred during error
> handling, give up!" that is output from AbstractFaultChainInitiatorObserver.
> The complaint is that it sounds like the message is telling the user to give
> up, rather than alerting them that error handling process is aborting due to
> an unexpected failure.
> It looks like that message is hardcoded into the Java source instead of
> loaded from the Messages.properties file, so this should probably change to.
> I'd like to suggest that we change the message to something like this:
> _An unexpected error occurred during error handling. No further error
> processing will occur._
> Please comment if you have strong opinions on the proposed wording or have
> other suggestions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (CXF-7604) Change to "Error occurred during error handling, give up!" message
[ https://issues.apache.org/jira/browse/CXF-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy McCright reassigned CXF-7604: -- Assignee: Andy McCright > Change to "Error occurred during error handling, give up!" message > -- > > Key: CXF-7604 > URL: https://issues.apache.org/jira/browse/CXF-7604 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.14, 3.2.1 >Reporter: Andy McCright >Assignee: Andy McCright >Priority: Minor > > One of our users complained about the message "Error occurred during error > handling, give up!" that is output from AbstractFaultChainInitiatorObserver. > The complaint is that it sounds like the message is telling the user to give > up, rather than alerting them that error handling process is aborting due to > an unexpected failure. > It looks like that message is hardcoded into the Java source instead of > loaded from the Messages.properties file, so this should probably change to. > I'd like to suggest that we change the message to something like this: > _An unexpected error occurred during error handling. No further error > processing will occur._ > Please comment if you have strong opinions on the proposed wording or have > other suggestions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CXF-7604) Change to "Error occurred during error handling, give up!" message
[ https://issues.apache.org/jira/browse/CXF-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy McCright resolved CXF-7604. Resolution: Fixed Fix Version/s: 3.2.2 3.1.15 > Change to "Error occurred during error handling, give up!" message > -- > > Key: CXF-7604 > URL: https://issues.apache.org/jira/browse/CXF-7604 > Project: CXF > Issue Type: Bug > Components: Core >Affects Versions: 3.1.14, 3.2.1 >Reporter: Andy McCright >Assignee: Andy McCright >Priority: Minor > Fix For: 3.1.15, 3.2.2 > > > One of our users complained about the message "Error occurred during error > handling, give up!" that is output from AbstractFaultChainInitiatorObserver. > The complaint is that it sounds like the message is telling the user to give > up, rather than alerting them that error handling process is aborting due to > an unexpected failure. > It looks like that message is hardcoded into the Java source instead of > loaded from the Messages.properties file, so this should probably change to. > I'd like to suggest that we change the message to something like this: > _An unexpected error occurred during error handling. No further error > processing will occur._ > Please comment if you have strong opinions on the proposed wording or have > other suggestions. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
