WCF在Windows Identity Foundation中使用2种身份验证方法

Question

我正在开发一个将成为我们新服务层的WCF项目。

这些服务将由2个独立的客户端调用，第一个是WPF应用程序，另一个是ASP.Net Web应用程序。 WPF客户端将由内部用户运行，并将通过域身份验证与服务进行身份验证，并在该用户的上下文中运行。另一个将由外部用户使用，需要使用一些单独的机制进行身份验证，然后在我们的域上模拟“WebUser”帐户。

我正在阅读一些关于Windows Identity Foundation的内容，听起来这可能是个不错的选择。我是否正确地认为我可以拥有2个令牌服务，一个用于域身份验证，一个用于ASP.Net成员身份验证（或类似的等价物），并让每个客户端从相关STS获取它的令牌并将其传递给WCF服务？

我假设有一个STS我可以开箱即用于域身份验证，但我是否必须自己实施第二个来验证Web用户？我找不到很多关于此的信息。

我是否正在考虑正确的思路，还是应该为每个使用不同身份验证机制的服务创建决斗端点？或者我应该做一些完全不同的事情？

由于

Answer 1

您应该查看identity server，因为它确实可以处理这种情况。

领导该项目的人在这个确切的场景中有一个很棒的pluralsight视频！您需要注册才能观看，但他们提供免费试用。

基本上，您从身份提供者处获取令牌（内部客户端的Windows ADFS，以及您为外部用户决定的内容）。您将此令牌提供给联合网关（可能是身份服务器，但它可能是Azure ACS）。这将返回一个身份验证令牌，然后您可以将其与您的服务一起使用。

Answer 2

使用基于声明的身份验证/ WIF的一大优势是，对用户进行身份验证和管理用户属性的任务都会从应用程序转移到STS /身份提供程序。

您正在开发服务层，但使用WIF的真正好处将是编写在图层顶部的应用程序。 WPF应用程序将不再需要连接到AD并获取用户的组以确定允许他们执行的操作。这些组已经在用户/ WIF提供的令牌中显示为声明。

Web应用程序（只是一个或多个Web应用程序？）将不再需要ASP.Net Membership数据库以及随附的用户管理。此功能将移至STS。

需要付费。 （总会有某种情况......）基于声明的身份验证具有相当陡峭的学习曲线。所有相关人员都需要一段时间才能下降。

因此，您的问题的答案取决于在您的服务层上构建的Web应用程序（s？）的用户类型和数量。他们希望了解他们多少。您是否可以信任Google / Facebook / Windows Live进行身份验证？用户是否已在您域中的现有数据库中？维护用户目录需要多少工作？您的营销人员是否希望定期向他们发送电子邮件？等等。

这可能不仅仅是服务层的开发人员决定，而是与组织其他人员讨论的内容。

如果收益不是特别大，那么另一种方法是简单地将这些职责保留在Web应用程序的服务器上。每个Web应用程序都有一个很好的旧ASP.Net成员资格数据库，它将自己对用户进行身份验证。当从服务层询问查询时，它将显示其Web服务器证书，并指定用户的名称和类型。

如果好处足够大，原则上您可以使用ADFS 2.0。它现在也可以存储外部用户，如果你已经拥有Active Directory，它是免费的。或者Ross推荐的ThinkTecture 2.0服务器。它更容易定制，也许你的系统管理员和安全人员不会太热衷于打开防火墙到ADFS服务器。

Microsoft已some good reads on WIF，特别是Overview of Claims-Based Architecture。