Monday, February 18, 2008

WSE 2.0 Vs WSE 3.0

This is probably one of the main concerns for people involved in the development of web services using WSE.
Unfortunately, WSE 3.0 was designed from the beginning to be compatible at wire level with Indigo and therefore it doesn't interoperate well with WSE 2.0.
To be clear, "Wire compatible" means equivalent messages.
I wrote this post to provide some necessary points to obtain interoperability between both versions.

WS-Security xx specs

At this moment, there are two available versions of this specification, 1.0 and 1.1 (Also called WS-Security extensions).
WSE 2.0 only implements the first version whereas WSE 3.0 uses features of both versions (such as signature confirmation and key derivation).
Both endpoints, the client and the server should use features provided only by WS-Security 1.0.

Secure conversation

Secure Conversation is a special feature provided by WSE, in which client and server negotiate a session token to protect the communication for a specific period of time. This feature decrease the response time because the token negotiation happens once compared to other turn-key scenarios where the negotiation is done for each message. (This feature is really important when the client and the server interchange many messages during a period of time).
The SecureContext token used in WSE 3.0 is not compatible with WSE 2.0 since it was modified to support new features like "Stateful secure context tokens".

WS-Addressing xx specs

WSE 3.0 uses a newer version of this specification (The same as Indigo) and therefore the messages produced by both versions are not compatible.
There is not a good way to fix this problem, but probably a SoapFilter to update the addressing headers can be a solution.

Algorithm suite

WSE 3.0 uses by default the same algorithm suite as Indigo, AES256 for symmetric encryption and RSA-OAEP for key wrap. On the other hand, WSE 2.0 uses AES128 and RSA-15.
You will have to update the configuration settings in both endpoints in order to use the same algorithm suite.

Using the same algorithm suitein WSE 2.0 and WSE 3.0

Default algorithms in WSE 3.0

WSE 2.0 and 3.0, both provide AES128 + RSA 1.5 as default algorithms for symmetric encryption and key-wrap.
However, AES256 + RSA-OAEP are always recommended for these purposes, and Indigo will ship with that combination as default.

In WSE 2.0, these algorithms could be changed adding some settings in the configuration file:

<microsoft.web.services2>
...
  <security>
  ....
    <binarySecurityTokenManager
      valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
      <sessionKeyAlgorithm name="TripleDES"/>   
      <keyAlgorithm name="RSAOAEP"/>  
    </binarySecurityTokenManager>
  </securityç>
...
<microsoft.web.services2>

These settings don't affect in the same way to WSE 3.0 because it implements some changes in the code used to secure messages. The security assertions
shipped within WSE 3.0 use different tokens to secure messages, they don't use an X509 security token anymore, instead they use derived tokens.

EncryptedToken: Usually, this token is used by the security assertions to sign and encrypt messages.

DerivedKeyToken: Only used when the flag "DeriveKeys" is on.

SecureContextToken: Only used in secure conversations. (When the flag "establishSecurityContext" is on)

The following configuration shows how to override the default algorithm used by these tokens:

<microsoft.web.services3>
  <security>
<binarySecurityTokenManager>
  <add
    type="Microsoft.Web.Services3.Security.Tokens.X509SecurityTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
   valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
    <keyAlgorithm name="RSAOAEP"/>
  </add>
</binarySecurityTokenManager>
<securityTokenManager>
  <add localName="EncryptedKey"
   type="Microsoft.Web.Services3.Security.Tokens.EncryptedKeyTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
    namespace="http://www.w3.org/2001/04/xmlenc#">
    <keyAlgorithm name="AES256"/>
  </add>
  <add localName="DerivedKeyToken">
    type="Microsoft.Web.Services3.Security.Tokens.DerivedKeyTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
    namespace="http://schemas.xmlsoap.org/ws/2005/02/sc">
    <keyAlgorithm name="AES256"/>
  </add>
  <add localName="SecurityContextToken"
    type="Microsoft.Web.Services3.Security.Tokens.SecurityContextTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
    namespace="http://schemas.xmlsoap.org/ws/2005/02/sc">
    <keyAlgorithm name="AES256"/>
  </add>
</securityTokenManager>
</security>
</microsoft.web.services3>

Securing Web Services using WSE 3.0

If you liked this episode check out these...

Securing Web Services with WSE 2.0

Requiring UsernameTokens
Authentication and Authorization
Implementing a UsernameTokenManager
Requiring Signatures
Using DerivedKeyTokens
Requiring Encryption
Signing and Encrypting with X.509 Tokens
Automating Security with Policy
Note on the UsernameTokenManager
Where Are We?

Read the article for complete view : http://msdn.microsoft.com/msdnmag/issues/04/10/ServiceStation/

DotNet First Side