Configuration File Differences between WSE 2.0 and 3.0

The configuration file format for WSE 3.0 and the .NET Framework 2.0 has changed from WSE 2.0 and the .NET Framework 1.0 and 1.1. This topic details the changes between WSE 2.0 and 3.0 configuration files. Use the WSE Settings 3.0 Tool to migrate configuration files from WSE 2.0 to WSE 3.0. For more details, see How to: Migrate Configuration Files from WSE 2.0 to 3.0.

Configuration Element Changes

Enabling WSE to run with a Web service

To enable WSE for a Web service that is hosted in ASP.NET, a <soapServerProtocolFactory> Element must be added to the configuration file. In previous versions of WSE, a SOAP extension was required. For more details, see How to: Configure a Web Service to Use WSE.

Configuration elements with a value

The .NET Framework 2.0 does not allow configuration elements to have values associated with an XML element. For WSE 3.0, elements that used to have a value associated with them in WSE 2.0 now have a value attribute. The following example shows how specifying the maximum number of cached SecurityContextToken security tokens using the <cacheLimit> Element changes from WSE 2.0 to 3.0.

WSE 2.0

<cacheLimit>30</cacheLimit>

WSE 3.0

<cacheLimit value="30" />

Following is the list of configuration elements that are affected by this change:

• <allow> Element
• <cacheLimit> Element
• <defaultTtlInSeconds> Element
• <deny> Element
• <generationLimit> Element
• <KeyIdentifier> Element
• <label> Element
• <maxMessageLength> Element
• <offsetLimit> Element
• <renewalWindowInSeconds> Element
• <timeToleranceInSeconds> Element
• <tokenIssuer> Element
• <ttlInSeconds> Element

Multiple occurring configuration elements

The .NET Framework 2.0 requires that any configuration element that can occur multiple times in a configuration file be a list type element. A list type element has <add>, <delete>, and <clear> child elements associated with it.

The following example shows how adding a custom binary security token manager to an application using the <binarySecurityTokenManager> Element changes from WSE 2.0 to 3.0.

WSE 2.0

<binarySecurityTokenManager 
  valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
  type="CustomSecurityNamespace.CustomSecurityClass, AssemblyName" />

WSE 3.0

<binarySecurityTokenManager>
  <add 
    valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
    type="type reference"/>
</binarySecurityTokenManager>

Following is the list of configuration elements that have changed to be list type elements in WSE 3.0:

<binarySecurityTokenManager> Element

<securityTokenManager> Element

Following is the list of configuration elements that used to be child elements of the list type element, but are now child elements of the <add> element for the list type element.

<keyAlgorithm> Element for <binarySecurityTokenManager>

<renewalWindowInSeconds> Element

<sessionKeyAlgorithm> Element

<cacheLimit> Element

<generationLimit> Element

<keyAlgorithm> Element for <securityTokenManager>

<label> Element

<offsetLimit> Element

<renewalWindowInSeconds> Element

<replayDetection> Element

Configuration elements that require an XML namespace definition

All configuration elements that require an XML namespace declaration now define a namespace attribute that specifies the XML namespace. Additionally, when the configuration element defines a name that uses the namespace declaration, a localName attribute is used to define the name. The following example shows how adding a custom security token manager to an application using the <securityTokenManager> Element changes from WSE 2.0 to 3.0.

WSE 2.0

<securityTokenManager 
  qname="prefix:tokenName"
  xmlns:prefix="http://tempuri.org"
  type="Mynamespace.MyTokenManager, MyDll">

WSE 3.0

<securityTokenManager>
  <add 
    localName="tokenName"
    namespace="http://tempuri.org"
    type="Mynamespace.MyTokenManager, MyDll"/>
</securityTokenManager>

Following is the list of configuration elements that are affected by this change:

<securityTokenManager> Element

Configuration elements that have been removed

<serverToken>

<autoIssueSecurityContextToken>

The functionality for these elements is incorporated in the Turnkey Security Assertions.

See Also

Tasks

How to: Migrate Configuration Files from WSE 2.0 to 3.0
How to: Migrate Code that Secures a SOAP Message without Policy to Use Custom Policy Assertions

Other Resources

Migrating Applications from WSE 2.0 to 3.0