[jira] Commented: (RAMPARTC-137) When SignSupportingToken (UserNameToken) is used with transport binding, server expects a signature.

["Russell Tempero (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RAMPARTC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770359#action_12770359 ] 

Russell Tempero commented on RAMPARTC-137:
------------------------------------------

We applied your fix, changed the security policy to have UsernameToken inside a SignedSupportingTokens assertion and everything seems to function properly. However, I looked through the SecurityPolicy specification found at http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/ws-securitypolicy.html and I am not sure that this is the correct fix. For SupportingTokens assertions the specification says that a signature is required unless used with a TransportBinding, in which case no signature is required. However, no such claim is made of SignedSupportingTokens. This leads me to believe that a signature is still required for SignedSupportingTokens when used with a TransportBinding.

Additionally, what about the use case where one wants a TransportBinding to enforce encryption, signing, etc at the transport layer, but also wants additional security on top of that? From my understanding, one would accomplish this by having a SignedSupportingTokens assertion on top of a TransportBinding. However, with the fix for this issue, Rampart does not support the additional signing and encryption. We are also concerned that clients will misinterpret our policy if we use SignedSupportingTokens and will send a signature for the UsernameToken.

I have attached a proposed patch that I feel is slightly better than the one that was committed for this issue, although my fix is still not entirely correct. The first part of the patch allows rampart_context_is_include_username_token() to fist check in any SignedSupportingTokens assertion for the UsernameToken, as it did before. However, if the binding type is transport, it will also move on to check in any SupportingTokens for the UsernameToken. I feel this part of the patch is correct and fairly complete (someone will want to verify this).

The second part of the patch alters rampart_context_get_nodes_to_sign() to *not* look for a signature on several token types (username, timestamp, etc) if the binding type is transport. This is not correct. The patch should look for a signature unless (binding_type == transport) and (username token came from non-signed supporting tokens). However, I did not know how to correctly check for the second condition. Someone will need to come up with a way to do this.

My above comments are made according to our current understanding of the SecurityPolicy specification. If I am in error, please let me know in what way and provide some supporting evidence.

Thank you for your time and efforts.
Russell

> When SignSupportingToken (UserNameToken) is used with transport binding, server expects a signature. 
> -----------------------------------------------------------------------------------------------------
>
>                 Key: RAMPARTC-137
>                 URL: https://issues.apache.org/jira/browse/RAMPARTC-137
>             Project: Rampart/C
>          Issue Type: Bug
>          Components: Rampart-core
>    Affects Versions: Current
>            Reporter: S.Uthaiyashankar
>            Assignee: S.Uthaiyashankar
>             Fix For: Next Version
>
>
> If it is transport binding, UserNameToken should be signed by underlying transport binding. Server should not expect a signature for user name token. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.