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