[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-sx] Issue PR012: Need policy example for encrypted username token
(WSS 1.0) Encrypted UsernameToken with X.509v3
This scenario is based on the first WS-Security Interop Scenarios
Document [WSS10-INTEROP-01 Scenario 2 – section 4.4.4] (http://www.oasis-open.org/committees/download.php/11374/wss-interop1-draft-06-merged-changes.pdf). This policy says that Requestor/Initiator must send a password in an
encrypted UsernameToken in a WS-Security header to the Recipient (who as the
Authority will validate the password). The password is required because that is
the default requirement for the Web Services Security Username Token Profile
1.x [WSS10-USERNAME, WSS11-USERNAME]. This setup is only recommended when the sender cannot provide the
“message signature” and it is RECOMMENDED that the receiver employs
some security mechanisms external to the message to prevent the spoofing
attacks. <wsp:Policy wsu:Id="wss10_encrypted_unt_policy" > <sp:AsymmetricBinding> <wsp:Policy> <sp:InitiatorEncryptionToken> <wsp:Policy> <sp:X509Token
sp:IncludeToken="Never"> <wsp:Policy> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:InitiatorEncryptionToken> <sp:RecipientSignatureToken> <wsp:Policy> <sp:X509Token
sp:IncludeToken="Never"> <wsp:Policy> <sp:WssX509V3Token10/> </wsp:Policy> </sp:X509Token> </wsp:Policy> </sp:RecipientSignatureToken> <sp:AlgorithmSuite> <wsp:Policy> <sp:Basic256/> </wsp:Policy> </sp:AlgorithmSuite> <sp:Layout> <wsp:Policy> <sp:Lax/> </wsp:Policy> </sp:Layout> <sp:IncludeTimestamp/> <sp:OnlySignEntireHeadersAndBody/> </wsp:Policy> </sp:AsymmetricBinding> <sp:Wss10> <wsp:Policy> <sp:MustSupportRefKeyIdentifier/> <sp:MustSupportRefIssuerSerial/> </wsp:Policy> </sp:Wss10> <sp:EncryptedSupportingTokens> <wsp:Policy> <sp:UsernameToken
sp:IncludeToken="AlwaysToRecipient"> <wsp:Policy> <sp:WssUsernameToken10/> </wsp:Policy> </sp:UsernameToken> </wsp:Policy> </sp:EncryptedSupportingTokens> </wsp:Policy> An example of a message that conforms to the above stated policy can be
found on [WSS10-INTEROP-01 Scenario 2 – section 4.4.4]. Best regards, From: Ashok Malhotra
[mailto:ashok.malhotra@oracle.com] OK. If you write the policy for this
usecase, we will add it to the usecases document. All the best, Ashok From: Use case 2.1.2.1 the plain text password
is protected by SSL. Use case 2.1.3 is good, but it required the client to have
certificate for signature. If SSL is the recommended way to protect
plain text password, then we don’t need to have WSS. If the client has
the private key, it can use X509 Token Profile for authentication instead.
Therefore, both use case does not apply to the scenario that I requested. The
use case I want is plain text password, and the client does not have the key to
sign. This should be a very common use case for Web Services, isn’t it? Also, I think the security is a far more
important issue than interoperability. Why we cannot show a best security
practice in the Example Document, and only shown an insecure example in section
2.1.1.1 for interoperability? Best Regards, From: Ashok Malhotra
[mailto:ashok.malhotra@oracle.com] I’m not sure what is meant by
“the example document” but the usecases document that we have
submitted contains usecase 2.1.2.1 and 2.1.3 which feature encrypted username
tokens. All the best, Ashok From: Anthony Nadalin
[mailto:drsecure@us.ibm.com] Why is this a must to have example ? as there are lots
of things that the we have done in the interop that are not shown as examples.
I would have expected this to have shown up as a interop issue if it was
important
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]