[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NEW Issue: Need policy example for encrypted username token
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. The issues coordinators will notify the list when that has occurred.
Protocol: ws-sp
http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/21836/UseCases-Examples-6-06-draft-10-02-distr-tc.doc
Artifact: examples
Type: design
Title: Need policy example for encrypted username token
One the examples document, we have insecure example of Username Token policy, but no simple encrypt password policy on Username token. This is a must-to-have scenario to be shown in the example document.
Description:
On the Security Policy
Examples document, there is an example of unencrypted plain text Username Token
policy on 2.1.1.1, but there is no example for encrypted plain text Username
Token policy. Sending unencrypted password
text, as showed on 2.1.1.1, is not a secure way to handle the Username Token.
The example should not be advertised as the only way to handle plain text
password. We do have an encrypted
plain text password policy on section 2.1.3 -- “(WSS 1.0) UsernameToken
with Mutual X.509v3 Authentication, Sign, Encrypt”. However, this example
requires signature. It is more complicated. Encrypted support token
without signature is a very common use case. It is documented on the first
WS-Security Interop Scenarios Document [WSS10-INTEROP-01 Scenario 1 –
section 4.4.4] (http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf
). This is a real requirement
for this use case scenario in the field, too. If a client does not have its own
private key then the Username Token is the only way for authentication. If the
server cannot accept digested password, then encrypted password is the only way
to secure authentication. The client does not have key for signature,
SignedEncryptedSupportingTokens assertion is not an alternative in this
scenario.
Related issues:
EncryptedSupportingTokens assertion.
Proposed Resolution:
We should provide a simple
policy example for sending encrypted password over the SOAP message, and make a
comment on the example of section 2.1.1.1 is not a secure way. Just like the WSS 1.0
Interop scenario document, a more secure example of handle Username Token
should be followed after section 2.1.1.1. _______________________________________________________________________ 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]