Windows Azure Access Control Service是基于Token的一种验证模式，旨在对你的应用程序设计好的验证功能，比如在public的云计算平台上发布你的应用程序和服务，如果不像所有的模块的功能都会被匿名的用户所访问，这时候你的工作就是需要依赖于ACS来保护你的程序和数据了。
ACS工作原理是这样的，首先Client将会被导向你的应用程序在云端的地址，这时候应用程序会判断你的权限，如果不符合验证规则，ACS自动提供一个Identity Providers的功能，这个功能的作用是让你设置你需要验证的方式，比如Google账号，FaceBook，ADFS，或者是自己定义的一套验证功能（通过SQL Azure数据库验证用户名和密码），这个时候由这些providers来验证你的账户，如果通过了这些验证，那么这些provider将会返回一个Identity Provider的Token给客户端，然后再由客户端将这个Token发给ACS（包含在HttpRequest header上），然后由ACS来判断这些Token是不是受信任的provider发送过来的，如果是则通过验证码。
可能上面的步骤有些复杂，但是这种工作机制的确很好的解决的第三方验证和云端的验证的结合，大大减轻了不同验证手段的结合，比如你可以使用表单验证，使用Window验证，使用数据库验证，或者同时使用多种验证，你的工作只是建立一个个对应的provider并且与ACS结合。
放一张图片介绍下ACS的机制：
.png)
这里我们简单创建一个示例来介绍怎么在你的Cloud程序中引入ACS验证功能
首先创建好你的cloud application，功能这里写的非常简单，有一个Content.aspx页面（只能被验证用户访问），然后再All文件夹下有个Default.aspx页面，可以被所有用户访问（包含登录功能）。这里我们需要设置访问权限，web.config中添加如下XML节点：
<location path="All">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
这里表示All文件夹下的所有文件可被任何用户访问（包括匿名用户）。接着你的工作是将你的应用程序发布到IIS（也可以不发布，但是指定好程序的端口），这一步很重要，因为ACS需要通过你的IP和端口来确定目标应用程序。然后你需要进入ACS的Portal设置好Identity provider，这里我建立一个普通的STS site (预先安装WIF)，ASP.NET Security Token Service Web Site, 这是一个基于WIF的自定义方式，你可以在这个site上面写你的验证逻辑（自定义）。
在你的ACS Portal上面建立这些identity provider （这里写的很详细，如何配置及每个字段的意思。例如RealM就是你的程序地址：http://localhost:7777/Content.aspx）,还有Token时长等一些设置，好了之后关联这个providers到你的应用程序，这里我们用了3个。Google，Windows Live和刚刚创建的WIF验证。
参阅：http://msdn.microsoft.com/en-us/wazplatformtrainingcourse_introtoacs2_topic2#_Toc309123875
配置好之后，请右键点击你的应用程序并且点击“Add STS Reference”添加ACS作为你的程序使用的STS，Application URI是你的应用程序地址，下一步选中“Use Existing STS”，并且从Azure Portal上复制下来你的ACS地址：
例如https://xxx.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml
后面继续点击Next即可。
