[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted
[ https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575740#comment-15575740 ] Colm O hEigeartaigh commented on CXF-7088: -- Ok I'm going to fix this by requiring that an EncryptedToken is encrypted at the message level unless a TransportBinding is explicitly used. Colm. > SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being > accepted > -- > > Key: CXF-7088 > URL: https://issues.apache.org/jira/browse/CXF-7088 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh > Fix For: 3.2.0, 3.1.8, 3.0.11 > > Attachments: messageNoEncryption.txt, message_anonymous.txt, > policy.txt > > > In WS-Policy that is used by service we have defined > > Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion > that is inside WS-Security section of the message SOAP Header should be > encrypted (not only signed). > Message with SAML that is NOT encrypted is currently accepted by CXF even > while policy defines > Question is: does SAML assertion fall into "SupportingTokens" category and > should be encrypted as well? > What is your view on that? Is that a bug in Neethi? > See > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566 > Signed, encrypted supporting tokens are Signed supporting tokens (See section > 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. > Element Encryption SHOULD be used for encrypting the supporting tokens. > The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax > of sp:SignedSupportingTokens only in the name of the assertion itself. All > nested policy is as per the sp:SignedSupportingTokens assertion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted
[ https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575527#comment-15575527 ] Colm O hEigeartaigh commented on CXF-7088: -- It looks like this is a bug in CXF. From the spec for EncryptedParts: The EncryptedParts assertion is used to specify the parts of the message that require confidentiality. This assertion can be satisfied with WSS: SOAP Message Security mechanisms or by mechanisms out of scope of SOAP message security, for example by sending the message over a secure transport protocol like HTTPS. This is the logic CXF follows. However, for the tokens it appears like the tokens themselves should be encrypted instead. > SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being > accepted > -- > > Key: CXF-7088 > URL: https://issues.apache.org/jira/browse/CXF-7088 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh > Attachments: messageNoEncryption.txt, message_anonymous.txt, > policy.txt > > > In WS-Policy that is used by service we have defined > > Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion > that is inside WS-Security section of the message SOAP Header should be > encrypted (not only signed). > Message with SAML that is NOT encrypted is currently accepted by CXF even > while policy defines > Question is: does SAML assertion fall into "SupportingTokens" category and > should be encrypted as well? > What is your view on that? Is that a bug in Neethi? > See > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566 > Signed, encrypted supporting tokens are Signed supporting tokens (See section > 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. > Element Encryption SHOULD be used for encrypting the supporting tokens. > The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax > of sp:SignedSupportingTokens only in the name of the assertion itself. All > nested policy is as per the sp:SignedSupportingTokens assertion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted
[ https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575504#comment-15575504 ] Grzegorz Maczuga commented on CXF-7088: --- Yes it is - 2-way TLS. Is that mentioned somewhere in WS-Policy or WS-SecurityPolicy standard's? > SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being > accepted > -- > > Key: CXF-7088 > URL: https://issues.apache.org/jira/browse/CXF-7088 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh > Attachments: messageNoEncryption.txt, message_anonymous.txt, > policy.txt > > > In WS-Policy that is used by service we have defined > > Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion > that is inside WS-Security section of the message SOAP Header should be > encrypted (not only signed). > Message with SAML that is NOT encrypted is currently accepted by CXF even > while policy defines > Question is: does SAML assertion fall into "SupportingTokens" category and > should be encrypted as well? > What is your view on that? Is that a bug in Neethi? > See > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566 > Signed, encrypted supporting tokens are Signed supporting tokens (See section > 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. > Element Encryption SHOULD be used for encrypting the supporting tokens. > The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax > of sp:SignedSupportingTokens only in the name of the assertion itself. All > nested policy is as per the sp:SignedSupportingTokens assertion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted
[ https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575483#comment-15575483 ] Colm O hEigeartaigh commented on CXF-7088: -- Is the message received over TLS by any chance? If so this counts as "encrypted". Colm. > SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being > accepted > -- > > Key: CXF-7088 > URL: https://issues.apache.org/jira/browse/CXF-7088 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh > Attachments: messageNoEncryption.txt, message_anonymous.txt, > policy.txt > > > In WS-Policy that is used by service we have defined > > Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion > that is inside WS-Security section of the message SOAP Header should be > encrypted (not only signed). > Message with SAML that is NOT encrypted is currently accepted by CXF even > while policy defines > Question is: does SAML assertion fall into "SupportingTokens" category and > should be encrypted as well? > What is your view on that? Is that a bug in Neethi? > See > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566 > Signed, encrypted supporting tokens are Signed supporting tokens (See section > 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. > Element Encryption SHOULD be used for encrypting the supporting tokens. > The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax > of sp:SignedSupportingTokens only in the name of the assertion itself. All > nested policy is as per the sp:SignedSupportingTokens assertion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted
[ https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575434#comment-15575434 ] Grzegorz Maczuga commented on CXF-7088: --- Message is generated on Oracle Api Gateway (so you can put in the message whatever you want) and received by CXF. It is just the proof that what was previously encrypted in message sample is not SAML Assertion (as you suspected) but Username Token. Thus still we have not-encrypted SAML Assertion that is processed by CXF with SignedEncryptedSupportingTokens wrapping SAML Assertion in binding policy. Moreover as you pointed out - there is Username Token which is not in policy and shouldn't be there (but it is and I expect to be just ignored)? We will remove Username Token and see what happen then. > SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being > accepted > -- > > Key: CXF-7088 > URL: https://issues.apache.org/jira/browse/CXF-7088 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh > Attachments: messageNoEncryption.txt, message_anonymous.txt, > policy.txt > > > In WS-Policy that is used by service we have defined > > Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion > that is inside WS-Security section of the message SOAP Header should be > encrypted (not only signed). > Message with SAML that is NOT encrypted is currently accepted by CXF even > while policy defines > Question is: does SAML assertion fall into "SupportingTokens" category and > should be encrypted as well? > What is your view on that? Is that a bug in Neethi? > See > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566 > Signed, encrypted supporting tokens are Signed supporting tokens (See section > 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. > Element Encryption SHOULD be used for encrypting the supporting tokens. > The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax > of sp:SignedSupportingTokens only in the name of the assertion itself. All > nested policy is as per the sp:SignedSupportingTokens assertion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted
[ https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15575404#comment-15575404 ] Colm O hEigeartaigh commented on CXF-7088: -- Where is the encrypted UsernameToken coming from? It's not in the policy and shouldn't be in the request. I tried to hack up a CXF test to send an encrypted UsernameToken with an unencrypted SAML token but it failed as expected. At this point I think you need to supply some kind of test that shows the failure. You could try adapting one of the ws-security systests in the git repo. Colm. > SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being > accepted > -- > > Key: CXF-7088 > URL: https://issues.apache.org/jira/browse/CXF-7088 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh > Attachments: messageNoEncryption.txt, message_anonymous.txt, > policy.txt > > > In WS-Policy that is used by service we have defined > > Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion > that is inside WS-Security section of the message SOAP Header should be > encrypted (not only signed). > Message with SAML that is NOT encrypted is currently accepted by CXF even > while policy defines > Question is: does SAML assertion fall into "SupportingTokens" category and > should be encrypted as well? > What is your view on that? Is that a bug in Neethi? > See > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566 > Signed, encrypted supporting tokens are Signed supporting tokens (See section > 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. > Element Encryption SHOULD be used for encrypting the supporting tokens. > The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax > of sp:SignedSupportingTokens only in the name of the assertion itself. All > nested policy is as per the sp:SignedSupportingTokens assertion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted
[ https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15572015#comment-15572015 ] Grzegorz Maczuga commented on CXF-7088: --- That is highly possible! Please close it. Thanks Colm. Greg > SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being > accepted > -- > > Key: CXF-7088 > URL: https://issues.apache.org/jira/browse/CXF-7088 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh > Attachments: message_anonymous.txt, policy.txt > > > In WS-Policy that is used by service we have defined > > Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion > that is inside WS-Security section of the message SOAP Header should be > encrypted (not only signed). > Message with SAML that is NOT encrypted is currently accepted by CXF even > while policy defines > Question is: does SAML assertion fall into "SupportingTokens" category and > should be encrypted as well? > What is your view on that? Is that a bug in Neethi? > See > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566 > Signed, encrypted supporting tokens are Signed supporting tokens (See section > 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. > Element Encryption SHOULD be used for encrypting the supporting tokens. > The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax > of sp:SignedSupportingTokens only in the name of the assertion itself. All > nested policy is as per the sp:SignedSupportingTokens assertion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted
[ https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571894#comment-15571894 ] Colm O hEigeartaigh commented on CXF-7088: -- What is the EncryptedData structure below the Assertion? Is it possible that your client is including both the SAML Assertion as well as an encrypted version of it? I tried using the exact same policy with CXF tests, where the client uses SignedSupportingToken only, and the service correctly rejects the request. My guess is that the Assertion is being encrypted in your request and hence there is no failure. Colm. > SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being > accepted > -- > > Key: CXF-7088 > URL: https://issues.apache.org/jira/browse/CXF-7088 > Project: CXF > Issue Type: Bug >Affects Versions: 3.0.6 >Reporter: Grzegorz Maczuga >Assignee: Colm O hEigeartaigh > Attachments: message_anonymous.txt, policy.txt > > > In WS-Policy that is used by service we have defined > > Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion > that is inside WS-Security section of the message SOAP Header should be > encrypted (not only signed). > Message with SAML that is NOT encrypted is currently accepted by CXF even > while policy defines > Question is: does SAML assertion fall into "SupportingTokens" category and > should be encrypted as well? > What is your view on that? Is that a bug in Neethi? > See > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566 > Signed, encrypted supporting tokens are Signed supporting tokens (See section > 8.2) that are also encrypted when they appear in the wsse:SecurityHeader. > Element Encryption SHOULD be used for encrypting the supporting tokens. > The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax > of sp:SignedSupportingTokens only in the name of the assertion itself. All > nested policy is as per the sp:SignedSupportingTokens assertion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7088) SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being accepted
[
https://issues.apache.org/jira/browse/CXF-7088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15571643#comment-15571643
]
Colm O hEigeartaigh commented on CXF-7088:
--
Could you supply the security policy that you are using as well as a sample of
the message that should be failing (but isn't)? I tried with CXF 3.0.6 with an
unencrypted SAML Assertion and it fails as expected with:
javax.xml.ws.soap.SOAPFaultException: These policy alternatives can not be
satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedEncryptedSupportingTokens:
The received token does not match the signed encrypted supporting token
requirement
> SignedEncryptedSupportingTokens in WS-Policy and SAML not encrypted being
> accepted
> --
>
> Key: CXF-7088
> URL: https://issues.apache.org/jira/browse/CXF-7088
> Project: CXF
> Issue Type: Bug
>Affects Versions: 3.0.6
>Reporter: Grzegorz Maczuga
>Assignee: Colm O hEigeartaigh
>
> In WS-Policy that is used by service we have defined
>
> Some people say that WS-SecurityPolicy 1.2 imply that also SAML assertion
> that is inside WS-Security section of the message SOAP Header should be
> encrypted (not only signed).
> Message with SAML that is NOT encrypted is currently accepted by CXF even
> while policy defines
> Question is: does SAML assertion fall into "SupportingTokens" category and
> should be encrypted as well?
> What is your view on that? Is that a bug in Neethi?
> See
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html#_Toc161826566
> Signed, encrypted supporting tokens are Signed supporting tokens (See section
> 8.2) that are also encrypted when they appear in the wsse:SecurityHeader.
> Element Encryption SHOULD be used for encrypting the supporting tokens.
> The syntax for the sp:SignedEncryptedSupportingTokens differs from the syntax
> of sp:SignedSupportingTokens only in the name of the assertion itself. All
> nested policy is as per the sp:SignedSupportingTokens assertion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
