您所描述的问题是一个众所周知的问题,它有(至少)两个标准化解决方案。
使用 WS-Trust 进行联合
第一个选项是基于 SOAP 的选项,它使用基于 WS-Trust 的活动联合。在这个解决方案中:
- 您的客户端向身份验证服务提供凭据
- 如果凭据有效,则身份验证服务会向客户端返回一个签名(和加密)的令牌。它被加密,因此令牌中包含的任何信息都保持机密 - 甚至客户端也无法读取它。它使用属于您的 WCF 服务的公钥加密。它使用属于身份验证服务的私钥进行签名。
- 客户端将签名/加密的令牌提交给您的 WCF 服务。该服务可以解密它,因为它拥有用于解密的私钥。它可以信任它,因为它是由身份验证服务签名的。
- 根据解密后的令牌内容,服务可以建立客户端身份并做出授权决策。
在这个模型中,通常的术语是:
- 您的身份验证服务 Security Token Service
- 您的 WCF 服务是依赖方
- 您的客户是客户
这听起来很复杂,但在使用 Windows Identity Foundation 的 .Net 和 WCF 中得到了很好的支持。有很多可用的示例,其中大部分(可能全部)都可以通过 WCF 配置而不是代码来完成。
这非常适合客户端具有加密功能(如您的 .Net 客户端)和存在良好框架(如 WIF)的场景。对于浏览器和某些手机等低规格客户端,或者您无法控制客户端的情况,它并不是那么好。
常用于企业场景,包括企业到企业联合。它在互联网场景中使用较少。
它的优点是
- 它是标准化的,因此通常得到框架的良好支持
- 这意味着您的 WCF 服务永远不必处理客户端凭据(= 更安全)
- 它可以很容易地切换到不同的身份验证服务(因为它是标准化的)。例如,本地 AD 和 Windows Azure AD 都支持这一点,其他独立的身份服务也是如此
可以在此处找到概述:
http://msdn.microsoft.com/en-us/magazine/ee335707.aspx
Google 会向您展示更多的演练和示例。
使用 OAUth 2 进行联合
在这个解决方案中:
- 客户端显示认证服务提供的一些UI(一般是网页)
- 用户在该 UI 中输入他们的凭据,身份验证服务进行身份验证并最终将令牌返回给客户端。令牌的性质没有标准化,也没有加密。一般来说,它至少会被签名。
- 客户端将令牌与每个请求一起提交给 WCF 服务
- WCF 服务像之前的解决方案一样对令牌进行身份验证
在 OAuth 术语中:
- 您的身份验证服务是授权服务器
- 您的 WCF 服务是 资源所有者
- 您的客户是客户
再一次,这听起来很复杂,但它在 .Net 中得到了相当好的支持。虽然目前可能不如 WS-Trust 方法好。它由 Windows Azure AD 和客户端支持,使用 Windows Azure 身份验证库。其他服务可能会使用这种方法 - 例如。脸书。
这在哪里很有效
- 您的客户端规格低或不支持加密(例如浏览器或某些手机)
- 您无法控制客户端(例如,第三方应用程序正在访问您的服务)
它在 Internet 应用程序中非常常用,您作为 WCF 服务的所有者不一定知道用户或客户端。在某些方面它是一个不太完整的标准(例如,它没有准确定义身份验证的发生方式),因此不太容易切换到其他授权服务器。
它的优点是:
- 它更简单,因此具有更广泛的平台支持
- 它越来越受欢迎,因此对库的支持也越来越好
- 用户从不将他们的凭据输入到您的 UI 中,只输入到身份验证服务器中,因此它更有可能被信任(在互联网场景中)
- 它具有控制授予客户端的权限范围和撤销这些权限的内置方式,因此它在互联网场景中更受信任
对此的官方 .Net 支持位于 Windows Azure AD 身份验证库中
http://msdn.microsoft.com/en-us/library/windowsazure/jj573266.aspx
还有其他开源组件,例如 DotNetOpenAuth
http://dotnetopenauth.net/
哪种解决方案最适合您,主要取决于您的身份验证服务的性质。以及您是在企业还是互联网场景中。如果授权。服务可以很容易地调整为 WS-Trust 安全令牌服务 (STS),那么这将是一条很好的路线。如果向身份验证添加一些 Web UI。服务可行,OAuth可能会更好。
或者,如果这两种方法都不可行,您可以从一种方法中借用模式并使用它,而无需采用完整的标准。
祝你好运!