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
<keyAlgorithm> Element for <securityTokenManager>
<renewalWindowInSeconds> 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>
Note
The <securityTokenManager> Element is also affected by the multiple occurring configuration element change.
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