-- 最近在学习Windows® Identity Foundation,这是MSDN里面对WIF的介绍: ,里面已经说得很好了,小弟就不再介绍了.WIF框架下载
在没有WIF之前,我们在构建我们的应用程序时,往往都会设计自己的用户库和验证逻辑,比如给公司开发一个中文CMS系统和一个英文的电子商务系统(由于各种原因比如两个项目是不同软件公司设计的,总之两个系统未能集成在一起),而这两个系统的后台管理员理论上是有可能共享的,因为后台操作只会限定在公司内部成员.甚至将来还会继续开发其它的应用系统...
面对这样不尴不尬的情景,一个经典的作法是给这些系统额外的设计单点登录.
说到单点登录,不得不说的是一个一致的身份验证策略设计往往只有在若干安全领域专家辅助时才能完成.
如果公司没有超强的安全领域知识积累,设计的sso将是脆弱的,随着时间的推移,一些不合理的设计最终将成为扩展的瓶颈! 这些感受我想很多人都有过.
以上糟糕的情形还是被微软看出来了,终于,他们集结很多业界安全大师设计了一套全新的基于声明的新访问平台,WIF就是此平台组件之一(其它两个是ADFS V2和Windows CardSpace).
一个貌似很熟悉的名词"基于声明"展现了一种新的方案,下面来形象的解释下WIF的验证流程.
以购买机票的流程来解释:
有一天你要去买机票(访问信赖方RP系统),
售票阿姨必须要你出示用户名,生日,住址(声明),同时提供的信息必须是这位阿姨可以相信的,你不能自己随便写一个,很自然的你想到了身份证(安全令牌 ps:身份证是可扫描的,内部数据是加密的).
因为身份证是公安局(颁发机构)颁发给你的,同时公安局也是航空公司可以信赖的,信赖身份证就像信赖公安局一样,所以没什么要怀疑的,你成功的买到票了.
从上面的过程我们可以看出,航空公司没有维护自己的用户库,也没有自己去验证用户信息的真实性,因为身份证可以证明买票者同时提供了航空公司需要的信息(声明).
航空公司把这一切验证都外包给了一个统一的机构.同时这一机构可以提供足够的用户信息.
人类这些聪明的社会行为同样的被拿到软件设计上.下面用真实的web系统说明:
RP 公开了描述其地址、绑定和协定的策略。 但是该策略也包括 RP 所需的声明列表，如用户名、电子邮件地址和角色成员身份。 该策略还告知智能客户端应从中检索这些声明的 STS 的地址。 检索此策略后 (1)，
客户端此时已知道到哪里去进行身份验证：STS。 用户出示凭据 (2)，
智能客户端向 STS 提出 Web 服务请求 (3)，
从而请求 RP 在其策略中所要求的声明。 STS 的工作是对用户进行身份验证，并返回为 RP 提供所有所需声明的安全令牌。 然后智能客户端会对依赖方提出请求 (4)，
从而在安全 SOAP 标头中发送安全令牌。 RP 此时收到各个请求的声明，只拒绝那些不包括来自其信任的颁发机构的安全令牌的请求。
下面我来列出一些术语:
STS: SecurityTokenService(安全令牌服务),相当于公安局,提供身份证信息审查/办理/查询验证服务.
RP: 信赖方. 当某个公司需要使用身份证来办理公司业务时,它必须信赖公安局(STS),这个公司此时参与的角色被称谓 信赖方.
RP-STS:(信赖方STS) / IP-STS:(标识方STS)
好了,初次写博,总结下了MSDN的概述,以后将写更多关于WIF实际应用的文章