svcutil 忽略 WS-Trust 声明

发布于 2024-10-18 13:08:55 字数 2299 浏览 7 评论 0原文

场景:我正在编写一个 WCF 客户端来访问 Java/Metro Web 服务,该服务需要通过从 STS(也是 Java/Metro)获取的令牌进行身份验证。服务 WSDL 中的相关策略片段如下:

<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>

请注意 外部 部分,如 WS 中所定义-SecurityPolicy 1.2(这与之前放置 的版本有所不同)。

当这样放置时,svcutil 会完全忽略 。但是,当放置在 RST 模板中时,它们会被复制到生成的配置中:

<binding ...>
  <security ...>
    <issuedTokenParameters ...>
      <additionalRequestParameters>
        <!-- The RST template is copied here -->
      </additionalRequestParameters>
      ...
    </issuedTokenParameters>
  </security>
  ...
</binding>

WCF 声明(无双关语)支持 WS-SecurityPolicy 1.2,所以我想知道 - 这是设计上的错误吗?恕我直言,策略中的声明应始终出现在绑定配置的中。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

桃酥萝莉 2024-10-25 13:08:55

Microsoft 支持人员向我确认这是 .NET 4.0 中的一个错误,并计划在下一版本中进行修复。

Microsoft Support confirmed to me that this is a bug in .NET 4.0 and a fix is planned for the next version.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文