adfs和java 应用_WIF应用与ADFS 2.0配置实战

步骤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

上面的错误消除后，应该能够回到应用的代码了。但是，如果有代码类似于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站点中。没有的话，添加。

最基本的几个步骤。暂时记录一下，不然真的要忘了。