Scenario: I am writing a WCF client to access a Java/Metro webservice which requires authentication through a token obtained from an STS (also Java/Metro). The relevant policy snippet from the service's WSDL is this:
<sp:IssuedToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
<sp:Issuer>
<wsa:Address>...</wsa:Address>
<Metadata xmlns="http://www.w3.org/2005/08/addressing">
<Metadata xmlns="http://schemas.xmlsoap.org/ws/2004/09/mex">
<MetadataSection>
<MetadataReference>
<Address xmlns="http://www.w3.org/2005/08/addressing">...</Address>
</MetadataReference>
</MetadataSection>
</Metadata>
</Metadata>
</sp:Issuer>
<t:Claims Dialect="http://schemas.xmlsoap.org/ws/2005/05/identity">
<ClaimType xmlns="http://schemas.xmlsoap.org/ws/2005/05/identity" Optional="false" Uri="..."/>
<ClaimType xmlns="http://schemas.xmlsoap.org/ws/2005/05/identity" Optional="false" Uri="..."/>
</t:Claims>
<sp:RequestSecurityTokenTemplate>
<t:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</t:KeyType>
<t:KeySize>256</t:KeySize>
</sp:RequestSecurityTokenTemplate>
<wsp:Policy>
<sp:RequireDerivedKeys/>
<sp:RequireInternalReference/>
</wsp:Policy>
</sp:IssuedToken>
Note the <Claims>
part outside the <RequestSecurityTokenTemplate>
, as defined in WS-SecurityPolicy 1.2 (this has changed from the previous version where the <Claims>
were placed within).
When placed like that, svcutil
ignores the <Claims>
entirely. When placed within the RST template though, they are copied into the generated config:
<binding ...>
<security ...>
<issuedTokenParameters ...>
<additionalRequestParameters>
<!-- The RST template is copied here -->
</additionalRequestParameters>
...
</issuedTokenParameters>
</security>
...
</binding>
WCF claims (no pun intended) to support WS-SecurityPolicy 1.2, so I wonder -- is this a bug oder by design? IMHO, the claims from the policy should always appear in the <additionalRequestParameters>
of the binding configuration.
Microsoft Support confirmed to me that this is a bug in .NET 4.0 and a fix is planned for the next version.