步骤1：配置主机头。这应该不是必须，但是我配了。详见上一篇博客。
步骤结果：经测试用主机头的地址能访问。
步骤2：Add STS Reference:
其中Use an existing STS一步，输入ADFS的FederationMetadata.xml所在。这里需要注意输入机器名称和完整名称有轻微不同。例如：机器名为xxx，域名为abc，我这边的环境机器的完整名称应为：xxx.abc.loc。而在xxx这台机器上的证书是按照完整名称颁发的，所以输入机器名称和完整名称的区别是，输入机器名称然后下一步时会有警告，说证书和地址不符。
其他的步骤暂时都是按照最简单的来。
完毕后，结果是：
更改了web.config和增加了自身的FederationMetadata.xml文件。
步骤3：
在ADFS中增加信赖方
选择手动输入有关信赖方德数据。并启用对WS-Federation被动协议的支持。这里输入的url应为应用的url，即之前Add STS Reference时候指定的Application URI。
然后下一步的时候，这个url会自动作为信赖方标识符出现。注意！这里的标识符貌似是case sensitive的！也就是应和应用的audienceUris完全匹配（这个不是100%确定，忘了，反正是要和一个什么东西一致）
完毕。暂时可以不添加声明规则。
结果：增加了ADFS中的依赖方的配置。
步骤4：
测试。排查错误：
@Passive client: The X.509 certificate CN=Geneva Signing Certificate is not in the trusted people store
如果运行过程中出现了这个错误，那么恭喜，整个过程是正常的。说明已经成功从issuer方返回到了application方，只不过因为是测试环境的证书，所以不认。参考http://social.msdn.microsoft.com/Forums/en-SG/Geneva/thread/ca0be31e-ab2e-447f-8562-99ea9cbec86b 做更改。
上面的错误消除后，应该能够回到应用的代码了。但是，如果有代码类似于HttpContext.Current.User.Identity.Name，则会报NullReference的异常。明明认证通过，为什么会是null呢？断点看看，可以知道Identity已经是Microsoft.IdentityModel.Claims.ClaimsIdentity的类型，而其有一属性为：DefaultNameClaimType = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"。而默认FedUtil工具生成的Claims会包括name和role，而这里是name，言下之意是ClaimsIdentity会根据name来确定Identity的name。
了解，行动：回到ADFS，添加一个转换传入声明，把Windows 账户名转成名称。
再来，搞定！
接下来应该差不多了。但如果测试的时候发现每次关闭browser再重新登陆都要log in的话，检查一下ADFS那个机器的adfs url的站点是否已经在IE的intranet站点中。没有的话，添加。
最基本的几个步骤。暂时记录一下，不然真的要忘了。
