基于WIF的WCF服务需要调用方法FederatedServiceCredentials.ConfigureServiceHost(),或者将等效的element <federatedServiceHostConfiguration>
放在web.config
文件中才能工作。这是服务级别的设置,换句话说,它适用于所有端点。
根据方法文档,ServiceHostBase
实例以多种WIF特定方式进行修改。例如,授权由基于WIF的授权类替换。
现在我想要一个<service>
(内部<system.serviceModel><services>
),其中有一个<endpoint>
个,其中一个端点是基于WIF的,其他端点使用普通的Windows身份验证
更新。在回复an answer below时,让我解释一下为什么我们要混合使用WIF和非WIF端点。如果我们只使用WIF,那么我们的每个客户都需要STS,如AD FS。设置它并不困难,但这是一个障碍,特别是如果他们只想测试我们的软件。因此,我们所做的是安装在使用Windows集成身份验证的模式下(对于我们的Web服务,也用于我们的前端),然后他们可以切换到使用AD FS的模式。
基本上我们希望能够在没有AD FS的情况下安装,以降低我们应用程序的入门门槛。
要执行此操作,<service>
需要<federatedServiceHostConfiguration>
。但是 - 这是我的问题 - 这也会影响同一服务的非WIF端点:例如,他们突然使用WIF授权管理器(class ClaimsAuthorizationManager
的实例)。
所以我的问题是:在单个WCF <service>
中混合使用WIF和非WIF端点的推荐方法是什么?
答案 0 :(得分:2)
我认为你不能。但在您的情况下,您应该只有一个WIF端点已经为STS留下了多个凭据支持。
您可以在STS上放置多个端点来处理不同类型的身份验证。一个用于Windows,一个用于用户名/密码。
去年我做了一个代码营盎司会议,证明了这一点。该来源已附在我http://www.neovolve.com/post/2010/11/21/CodeCampOz-Not-a-WIF-of-federation.aspx的博客文章中。看一下 NotAWif Demo \ 4中的web.config - Identity Delegation \ NotAWif.DelegationSTS 。
<system.serviceModel>
<services>
<service behaviorConfiguration="ServiceBehavior"
name="Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract">
<endpoint address="UserName/IWSTrust13"
binding="ws2007HttpBinding"
bindingConfiguration="ws2007HttpBindingUserNameConfiguration"
contract="Microsoft.IdentityModel.Protocols.WSTrust.IWSTrust13SyncContract" />
<endpoint address="Windows/IWSTrust13"
binding="ws2007HttpBinding"
bindingConfiguration="ws2007HttpBindingWindowsConfiguration"
contract="Microsoft.IdentityModel.Protocols.WSTrust.IWSTrust13SyncContract" />
<endpoint address="mex"
binding="mexHttpsBinding"
contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="https://localhost/NotAWif.DelegationSTS/Service.svc" />
</baseAddresses>
</host>
</service>
</services>
<bindings>
<ws2007HttpBinding>
<binding name="ws2007HttpBindingUserNameConfiguration">
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="None">
<extendedProtectionPolicy policyEnforcement="Never" />
</transport>
<message clientCredentialType="UserName"
establishSecurityContext="false" />
</security>
</binding>
<binding name="ws2007HttpBindingWindowsConfiguration">
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="None">
<extendedProtectionPolicy policyEnforcement="Never" />
</transport>
<message clientCredentialType="Windows"
establishSecurityContext="false" />
</security>
</binding>
</ws2007HttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
<serviceCredentials>
<serviceCertificate findValue="DefaultApplicationCertificate"
x509FindType="FindBySubjectName" />
</serviceCredentials>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
这是我配置STS以支持多种类型身份验证的方式。 RP只应处理索赔,而不是索赔| WindowsIdentity。 STS有责任将特定类型的身份验证转换为RP将使用的一组声明。
答案 1 :(得分:2)
使用STS可能会混淆使用WIF。他们没有关系。
WS2007FederationHttpBinding将导致WCF端点期望发出的令牌(来自STS)。 WS2007HttpBinding或NetTcpBinding可能需要Windows令牌。
您可以使用WIF来处理这两者,实际上它是WITH WIF,您可以拥有更有效地支持两种不同令牌格式的服务行为。
发布的令牌端点将依赖于WIF配置中saml11 / saml2安全令牌处理程序的配置来处理令牌和受信任的颁发者部分以建立对该令牌的信任。 Windows端点将依赖其中一个Windows安全令牌处理程序来处理Windows令牌。
两者都将通过WIF服务authz管理器进行汇总,但会为Windows或您发放的令牌提供水合作用。您可以使用claimAUthenticationManager在到达claimauthorizationmanager授权访问权限之前转换这些声明。
有很多方法可以给这只猫上皮,但这绝对是可能的。