[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion
Right. parts, elements. I switched them by accident.
From: Jan Alexander [mailto:janalex@microsoft.com] Sent: Tuesday, February 13, 2007 3:57 PM To: Tony Gullotta; Symon Chang; ws-sx@lists.oasis-open.org Subject: RE: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion The
elements inside the security header are not considered to be SOAP message
headers so Symon is right, EncryptedParts cannot be used for this purpose.
However,
the spec provides EncryptedElements assertion in section 4.2.2 that can be used
for this purpose. When combined with my proposal to change the wording around
SupportingTokens assertion in another mail on this thread you will be able for
example to add UsernameToken to the security header as a supporting token and
then use EncryptedElements assertion to require the Username token to be
encrypted. Would that work for your scenario? Thanks, --Jan From: Tony Gullotta
[mailto:tony.gullotta@soa.com] I was
going by Tony Nadalin's suggestion that the spec doesn't prohibit this. I don't
see anything in 4.2.1 that says we can't use this assertion for wss headers.
Maybe I missed it. If that is truly the case, then I guess we would need another
assertion. I don't know if it would require a SupportingTokens assertion though,
would it? I should be able to use the recipient's token to encrypt the
initiator's token in an asymmetric binding. Tony
G. From: Symon Chang
[mailto:sychang@bea.com] Tony,
EncryptedParts is
used for the non-security element in the header. Per section 4.2.1 of the spec,
we can have the policy assertion like the following:
<wsp:Policy>
<sp:EncryptedParts>
<sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>
<sp:Body/>
</sp:EncryptedParts>
</wsp:Policy> But we cannot have the
policy assertion like this:
<wsp:Policy>
<sp:EncryptedParts>
<sp:Header Namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"/>
</sp:EncryptedParts>
</wsp:Policy> Or:
<wsp:Policy>
<sp:EncryptedParts>
<sp:Header Name="Security/UsernameToken" Namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"/>
</sp:EncryptedParts>
</wsp:Policy> In other words, EncryptedParts assertion is not for security
header. That is why we have SignedSupportingTokens, EndorsingSupportingTokens,
SignedEncrypptedSupportingTokens, EndorsingEncryptedSupportingTokens, …
assertions in the first place. The issue is: why EncryptedSupportingTokens is
missing in current WS-SP spec? We need the EncryptedSupportingTokens to support
a very basic WSS 1.0 function, i.e. to encrypt the plain text password.
Best regards, Symon Chang From: Tony Gullotta
[mailto:tony.gullotta@soa.com] In today's call
during the discussion of PR013 we were discussing encrypting a password of a
username token (or the whole token) without the need for a signature.
Couldn't the policy look something like this: AsymmetricBindingAssertion Initiator token:
UsernameToken Recipient token:
X509Token No
timestamp EncryptedParts UsernameToken Wouldn't this work?
It wouldn't require a signature would it? _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]