使用WIF实现单点登录Part II —— Windows Identity F

在上一篇文章中,我们已经使用WIF构建了一个基于MVC4的简单的身份验证程序,在这篇文章里,我们将探讨一下到底什么是WIF,以及它的工作原理 。然后在下一篇文章开始,我们将实际操作,实现单点登录功能 。
身份标识的挑战
在上一篇文章也提及到了,大部分的开发人员并不是安全方面的专家,很多人对于身份验证,授权以及用户体验个性化等工作感觉非常的不爽 。传统的计算机技术的课程里通常也不会教这些课题,因此这些东西经常在软件开发周期的后半部分才会凸显出来 。当今,一个公司里有数十上百个Web应用程序和服务已不是什么新鲜事儿,很多公司都有自己的一套用户标识,而且大部分公司都不会去用特定的身份验证方法 。开发人员都知道要为每一个程序都支持身份标识是多么乏味的事情,而且IT专家也知道要管理这些程序的结果集是多么昂贵 。解决此问题的很有用的一步就是将用户账号集中到企业目录中去 。通常只有IT专家才知道查询目录的最有效方法,但如今这项工作通常都交给了开发人员 。而且面对合并,收购和合作伙伴关系的时候,开发人员可能要访问多个目录,使用多个API 。在微软 .NET里,有很多在程序里支持身份标识的不同方法,而且每一个通信框架对身份标识都有不同的处理,它们采用了不同的对象模型,不同的存储模型,等等 。甚至在ASP.NET里,开发人员对于上哪找身份标识也会感到困惑:应该用 .User 属性?还是.?对密码的使用不当导致了网络钓鱼的猖狂 。而这么多程序都自己干自己的事儿,对公司来说就很难升级到强大的身份验证技术 。
更好的解决方案
一个解决这些问题的方法是别再在每个新的程序里建造自定义的身份标识管道和用户账户数据库 。但即使是依赖企业目录的开发人员仍然对合并,收购和合作伙伴感到痛苦,甚至还有可能由于其它程序的低效查询拖累了目录而被责难为性能低下 。本文所要讲的基于声明的解决方案不需要开发人员为了查询用户身份标识的细节而连到任何特定的企业目录 。相反,用户请求带着程序需要干活儿的标识信息一同到达 。带着这些声明的用户请求到达的时候,用户就已经是验证通过了,应用程序无需担心管理或者查找用户账户的事儿,只需专注于业务即可 。在应用程序之外处理身份验证可以为开发人员,IT专家和用户带来很多好处 。简单地说,需要每个人来管理的用户账户少了,身份验证的集中化使其随着其发展更容易升级到强壮的身份验证方法,即使与其它平台和组织进行联合身份标识也是如此 。本文将帮你,作为一个开发人员,去理解基于声明的标识模型以及通过使用微软的新框架(WIF)来利用它 。
【使用WIF实现单点登录Part II —— Windows Identity F】什么是?
(WIF) 是一组 .NET类 。它是为了在程序里实现基于声明的标识的框架 。通过使用它,将更简单地感受到本文所说的基于声明的标识模型的好处 。可以用于任何基于.Net3.5 SP1以上版本的Web应用程序或者Web服务 。WIF只是微软标识和访问平台( and)软件家族的一部分,这个家族实现了可互操作的标识原系统( )这么一个共享的产业愿景 。包括活动目录联合服务(ADFS) 2.0 (之前被称为 “” ),2.0,以及(之前称为 “” ),来自于微软新的基于声明访问策略的核心部分 。可以参考in来获取更多关于ADFS和组件的信息 。
基于声明的标识模型
当创建声明感知(-aware)的应用程序时,用户向程序出示他的身份标识,标识以一组声明来表示(见图1) 。一个声明可能是用户名,另一个声明可能是电子邮件地址 。此处的想法是一个外部的标识系统被配置来对于用户发起的每一个请求,都为程序提供它所需要知道的用户信息,以及接收到的标识数据都经过受信任来源的加密保护 。