WIF 4.5 BootstrapContext安全令牌空 [英] WIF 4.5 BootstrapContext security token null

查看:142
本文介绍了WIF 4.5 BootstrapContext安全令牌空的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我公司采用新的4.5 WIF的东西来验证网站的用户,并确保我的MVC网站和WCF服务之间的通信。

I am using the new 4.5 WIF stuff to authenticate users of the website and to secure the communication between my MVC website and WCF services.

我已经配置保存引导背景下,这样我可以重复使用同样的安全令牌的所有请求到服务层的网站。

I have the website configured to save the bootstrap context so that I can re-use the same security token for all requests to the service layer.

在正常条件下,所有通过的情况下工作正常与验证每一个网页请求和SecurityToken提供给固定WCF调用。

Under normal conditions all is working fine with each website request authenticated and the SecurityToken made available via the context to secure the WCF calls.

然而,如果网站的应用程序域被重置(例如建立应用程序而开发)的网站的任何请求仍将进行身份验证,但SecurityToken不再在上下文中可用​​传递到WCF调用。

If however the websites app domain is reset (e.g. building the app while developing) any requests to the website will still be authenticated but the SecurityToken is no longer available in the context to pass on to the WCF calls.

调试<一href="http://msdn.microsoft.com/en-us/library/system.identitymodel.tokens.bootstrapcontext.aspx"><$c$c>BootstrapContext它有4个有用的属性:

Debugging the BootstrapContext it has 4 useful properties:

SecurityToken
SecutiryTokenHandler
Token
TokenBytes

pre-应用程序域复位SecurityToken和SecurityTokenHandler有价值观和后重置令牌的值。

Pre-app domain reset SecurityToken and SecurityTokenHandler have values, and post reset Token has a value.

看起来这是原始SAML XML这样我就可以presumably从它补充水分全SecutiryToken但这似乎奇怪的行为,我无法找到任何文件复位后,目测令牌的值。

Eyeballing the value for Token after the reset it looks like this is the raw SAML XML so I can presumably rehydrate a full SecutiryToken from it but this seems strange behavior that I cannot find any documentation about.

任何想法我可以做,以确保SecurityToken始终可用救了我插科打诨与令牌XML?

Any ideas what I could do to ensure the SecurityToken is always available to save me messing around with the token XML?

更新

使用dotPeek来看看是怎么回事,在框架的源$ C ​​$ C我看得出来,casues这种行为的执行​​路径,但我不能确定任何理由为什么它需要的是这样的,怎么可能avioded。

Using dotPeek to look at what is going on in the framework source code I could see the execution path that casues this behaviour but I couldn't determine any reason why it needed to be this way and how it could be avioded.

在最后,我放弃了试图解决它,现在使用下面这段code,以确保我有一个令牌

In the end I gave up trying to work it out and now use the following piece of code to ensure I have a token

if (context.SecurityToken != null)
{
    token = context.SecurityToken;
}
else if (context.Token.IsNotEmpty())
{
    var handlers = FederatedAuthentication.FederationConfiguration.IdentityConfiguration.SecurityTokenHandlers;
    token = handlers.ReadToken(new XmlTextReader(new StringReader(context.Token)));
}

我现在做什么担心的是我错过了这个行为体背后的一些推理和我的修复以上是要炸毁在某些时候。

What I am now concerned about is I have missed some reasoning behind this behaiour and my fix above is going to blow up at some point.

推荐答案

在同样的问题,我已经迷迷糊糊。 我看到令牌有令牌和SecurityToken是空的XML重新presentation。 我还注意到,这是很容易被杀死的w3wp.exe重现。

I have stumbled upon the same issue. I see the Token to have the xml representation of the token and the SecurityToken being null. I also noticed that this is really easy to reproduce by killing w3wp.exe.

这篇关于WIF 4.5 BootstrapContext安全令牌空的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆