当微软首次在Windows Server 2003 R2中引入活动目录联合服务（ADFS）时，该功能并没有得到太多的喝彩。有些功能理论上听起来很好，但是出现的时间有些早，ADFS就是这些功能中的一个。

　　微软在Windows Server 2008和Windows 2008 R2中囊括了活动目录联合服务，甚至还提供了可下载的2.0版本。但是，似乎没有人在生产环境中使用ADFS。这种情况也许要改变了。

　　ADFS提供管理在线身份和提供单点登录（single sign-on）功能的方法。由于从运行本地应用到运行云中应用的转变，ADFS变得越来越重要。

　　当应用程序在本地运行时，所有应用一般都直接安装在用户桌面、终端服务器或应用服务器上。在任意一种这些情况中，应用程序的权利都由活动目录对象（如用户和群组）保证。一旦用户登录到活动目录，他们在整个林中被识别，不管他们连接到哪台服务器来访问应用和其它资源。

　　尽管这种访问控制模式已经良好地运用了十年，但当云托管的应用进入到画面，它开始倒塌。例如，当用户早上登录到他们的电脑，他们登录到一个活动目录域。这建立了一个他们在企业中访问资源时会用到的身份。

　　但是，如果一个人从浏览器中打开Netflix，它无法识别该用户。这个网站，虽然技术上是一个云应用，并不在乎用户登录到活动目录域。Netflix管理他们的用户帐户信息，所以人们必须提供一套明确针对该网站的凭证。

　　登录到Netflix的行为不只是确认我是已付款的用户。同样地，每个用户都有必要拥有唯一的凭证，因为就像任何其它应用一样，Netflix保持人性化的设置，如演员表信息和电影顺序。例如，尽管一名用户也许只有一次简单的Netflix订阅，家庭中的每个人都有自己独立的登录，所以他们能够管理自己的电影顺序。

　　记住，相同的概念可以应用到企业环境。越来越多的组织开始在云中运行应用。而且，就像Netflix，这些应用中的大部分需要一套唯一的凭证，尽管记住Netflix密码很简单，这个概念确实没有在企业中扩展得很好。

　　为什么基于云的身份管理会是如此大的挑战？这有很多原因。首先，每个基于云的应用都可能由不同的提供商托管。例如，除了拥有Netflix帐户之外，用户还能拥有亚马逊帐户。这两者彼此没有关第，它们需要两套不同的凭证。试想一下，与这相同的概念如何能在企业环境中实施。如果一个组织购买了20个托管应用，接着用户就有20套不同的凭证要记住，不管是对于管理人员还是技术支持人员来说，这都是一场运维的噩梦。

　　管理人员面对设置所有这些帐户的负担，而技术支持人员面对管理密码重设的艰难任务。对于用户来说，打电话或说他们需要密码重设已经不够了。现在，他们必须指出他们访问出问题的应用是哪个，且帮助台必须重设用于该应用的密码。

　　也正是这类运维挑战让ADFS得到更广泛地采用。 现在，微软正在使用ADFS来为那些想迁移某些网络服务的用户引向一条朝向Office 365的道路。

　　Office 365包括微软的Exchange、SharePoint和Lync。所有这些应用都需要一个活动目录（AD）环境，但是不能只是将Office 365加入到域中。相反地，要使用ADFS来安装目录同步化。

　　因为Office 365应用程序需要一个活动目录环境，微软为你的Office 365购买创建了专用域。该目录同步化程序自动地在微软域中创建帐户 ，它与本地林中现存的帐户匹配（用户选择他们想同步化哪个帐户）。当然，还是有与同步化帐户相关的密码，这也正是ADFS起作用的地方。

　　当用户试图访问Office 365时，ADFS向微软服务器提交一次请求。该请求包括用户的身份信息。微软服务器验证请求真实后提取帐户信息。接着，该用户自动地登录到微软域中的帐户并获得到请求应用的访问权。在整个过程中，用户除了像往常一样登录本地林不用再做其它事情。

　　ADFS解决了云身份管理的挑战。现在还不是所有云应用提供商都支持ADFS。但随着着越来越多的组织采用Office 365，ADFS会成为将企业连接到托管Web应用的标准机制，这只是时间的问题。