我一直在使用WIF来验证我们的新网站,STS基于starter-sts的实现。
为了使其在负载均衡环境下正常工作,我在global.asax中使用了以下内容来覆盖默认的证书行为。
void onServiceConfigurationCreated(object sender, ServiceConfigurationCreatedEventArgs e)
{
List<CookieTransform> sessionTransforms = new List<CookieTransform>(new CookieTransform[]
{
new DeflateCookieTransform(),
new RsaEncryptionCookieTransform(e.ServiceConfiguration.ServiceCertificate),
new RsaSignatureCookieTransform(e.ServiceConfiguration.ServiceCertificate)
});
SessionSecurityTokenHandler sessionHandler = new SessionSecurityTokenHandler(sessionTransforms.AsReadOnly());
e.ServiceConfiguration.SecurityTokenHandlers.AddOrReplace(sessionHandler);
}
这一切都很有效,人们已经成功地使用了这个系统,不过我们时不时地得到了爆炸:
ID1014:签名无效。数据可能已被篡改。
在事件日志中,所以我打开了WIF跟踪,并在日志中看到了以下内容。
ID1074:尝试使用ProtectedData API加密cookie时发生CryptographicException(有关详细信息,请参阅内部异常)。如果您使用的是IIS 7.5,则可能是因为应用程序池上的loadUserProfile设置被设置为false。
我有一种感觉,正如我想的那样,这导致我走入一条黑暗的小巷,因为我改变了使用RSA的实现,这不应该影响我。
有什么想法可以帮助我吗?
答案 0 :(得分:4)
浏览器cookie使用“旧”机制加密 - DPAPI。 因此,当服务器尝试解密cookie时,它会失败 - 您的代码现在使用RSA,而不是DPAPI。
作为解决方法,清除浏览器缓存,应用程序将按预期开始运行。
答案 1 :(得分:2)
我更改了实现以修改ontokencreated方法中的超时。这可以防止重新发行。
protected override void OnSessionSecurityTokenCreated(Microsoft.IdentityModel.Web.SessionSecurityTokenCreatedEventArgs args)
{
args.SessionToken = FederatedAuthentication.SessionAuthenticationModule.CreateSessionSecurityToken(
args.SessionToken.ClaimsPrincipal,
args.SessionToken.Context,
DateTime.UtcNow,
DateTime.UtcNow.AddDays(365),
true
);
//base.OnSessionSecurityTokenCreated(args);
}
答案 2 :(得分:0)
您是否尝试将loadUserProfile选项设置为true?问题是否仍然存在?
(在IIS中选择应用程序池,然后单击右侧的“高级设置”。“加载用户配置文件”位于“过程模型”部分中。)
答案 3 :(得分:0)
错误的间歇性发生以及跟踪中显示的DPAPI异常表明您实际上并未覆盖cookie转换,并且您的服务仍在使用DPAPI。
这可能是一个很长的镜头,但在你的代码片段中,我注意到你的方法覆盖“onServiceConfigurationCreated”以小写o开头。这样的拼写错误确实会阻止您正确地覆盖默认的WIF行为。