阻止 WCF 缓存/重用安全令牌 (SecurityContextToken) [英] stop WCF from caching / re-using security tokens (SecurityContextToken)

问题描述

我正在使用 WCF 消息级安全性和以下 wsHttpBinding

 <message clientCredentialType="Windows" createdSecurityContext="false"/></安全>

• 每次调用服务都是一个单独的操作，不需要保持任何会话状态.

• 我遇到了负载均衡器的问题，因为 WCF 不断重复使用安全令牌，所以如果第一次调用转到 NodeA，它会创建一个可重复使用的安全令牌.如果将该令牌传递给 NodeB，则会触发 MessageSecurityException

• 似乎微软对此的回答是使用粘性会话，这是我们探索过的东西，但在我们的设置中没有意义

有没有办法简单地强制 WCF 在每次调用时创建一个新的安全令牌?(同时使用 Windows 凭据类型的消息级别安全性?

更新

我在客户端/服务器上设置了跟踪，我可以看到令牌缓存了 24 小时.

<SessionTokenType>System.ServiceModel.Security.Tokens.BufferedGenericXmlSecurityToken</SessionTokenType><ValidFrom>2013-03-23T21:21:32.569Z</ValidFrom><ValidTo>2013-03-24T07:21:32.569Z</ValidTo><InternalTokenReference>LocalIdKeyIdentifierClause(LocalId = 'uuid-291b4a38-af17-4832-bc7a-6fb65dcc3c3c-18', Owner = 'System.ServiceModel.Security.Tokens.SecurityContextSecurityToken')</InternalTokenReference

<块引用>

IssuanceTokenProvider 使用了缓存的服务令牌.

我尝试使用以下方法禁用令牌兑现:

IssuedTokenClientCredential itcc = service.ClientCredentials.IssuedToken;itcc.CacheIssuedTokens = false;itcc.LocalIssuerAddress = new EndpointAddress("http://localhost:####/myservice");itcc.LocalIssuerBinding = new WSHttpBinding("my_wsHttp_bindingConfig");itcc.MaxIssuedTokenCachingTime = new TimeSpan(0,0,0);

但是查看 wcf 跟踪，似乎上面根本不影响协商.

我仍然看到使用了缓存的令牌.

解决方案

经过大量研究，并通过 WCF 跟踪和联系 Microsoft，我找到了这个问题的根源.

1. 在使用消息级安全性时，WCF 发布基于安全上下文令牌的身份验证 (SCT)

2. 这种类型的身份验证仅依赖于粘性会话，无法绕过它.

3. 有一个设置应该禁用它EstablishSecurityContext=false，但这不起作用.设置后，我可以在跟踪中看到 SCT 的使用与以前一样(我让微软的人确认我在这里没有做任何不寻常的事情).此设置可能存在其他依赖性，但一位高级 MS 工程师也不知道为什么此设置不起作用.

4. 剩下几个选项

   一个.对 Kerberos 使用一次性"调用 - 我没有探索这个，因为在我的场景中打开 kerberos 会更头疼

   B.使用基于 NTLM 的身份验证的自定义绑定 - 我试过了，但仍在使用 SCT，所以它对我不起作用

   c.将联合安全与自定义令牌发行服务一起使用.这可以更好地控制令牌的发行方式，但有不必要的(在我的情况下)管理此开销

   d.使用具有 TransportCredentialOnly 安全模式的基本 http 绑定.这很好，因为它停止 SCT 协商，同时仍然传递 Windows 凭据.

4.d 对我来说是最简单的，因为除了配置之外我不需要做很多改变.我正在放弃 wshttpbinding 功能，但到目前为止还可以，因为此对话是在受信任的网络中进行的.

I am using WCF Message level security with the following wsHttpBinding

  <security mode="Message">
    <message clientCredentialType="Windows" establishSecurityContext="false" />
  </security>

• Each time i call the service is a separate operation, and there is no need to keep any session state.

• I am running into a problem with load balancer, because WCF keeps re-using security tokens, so if the first call goes to NodeA, it creates a security token which is re-used. If that token is passed to NodeB tripping up MessageSecurityException

• Seems like microsofts answer to this is to use sticky sessions, which is something we explored but it does not make sense in our setup

Is there a way to simply force WCF to create a new Security Token on every call? (while using Message level security with Windows credential type?

update

i setup trace on client / server and i can i see that the token is cached for 24 hrs.

<ServiceToken>
<SessionTokenType>System.ServiceModel.Security.Tokens.BufferedGenericXmlSecurityToken</SessionTokenType>
<ValidFrom>2013-03-23T21:21:32.569Z</ValidFrom>
<ValidTo>2013-03-24T07:21:32.569Z</ValidTo>
<InternalTokenReference>LocalIdKeyIdentifierClause(LocalId = 'uuid-291b4a38-af17-4832-bc7a-6fb65dcc3c3c-18', Owner = 'System.ServiceModel.Security.Tokens.SecurityContextSecurityToken')</InternalTokenReference>

The IssuanceTokenProvider used the cached service token.

i've tried disabling token cashing using the following:

IssuedTokenClientCredential itcc = service.ClientCredentials.IssuedToken;
itcc.CacheIssuedTokens = false;
itcc.LocalIssuerAddress = new EndpointAddress("http://localhost:####/myservice");
itcc.LocalIssuerBinding = new WSHttpBinding("my_wsHttp_bindingConfig");
itcc.MaxIssuedTokenCachingTime = new TimeSpan(0,0,0);

but looking at the wcf trace, it appears that above doesn't affect the negotiation at all.

i am still seeing that cached tokens are used.

解决方案

after a lot of research, and pouring through the WCF trace, and contacting Microsoft, i got to the bottom of this problem.

1. when using message level security, WCF issues Security Context Token based authentication (SCT)

2. this type of authentication simply relies on sticky session, no way around it.

3. there is a setting which is supposed to disable it EstablishSecurityContext=false, but this does not work. after setting this i can see in a trace that SCT's are being used just as before (and i got someone at Microsoft to confirm i wasn't doing anything unusual here). There might be another dependency on this setting, but a senior MS engineer didn't know why this setting wasn't working either.

4. this leaves a few options

   a. use "one shot" calls with Kerberos - i did not explore this because turning on kerberos in my scenario would have been a bigger headache

   b. use a custom binding with NTLM based auth - i tried this, but SCT's were still being used, so it didn't work for me

   c. use federated security with custom Token issuing service. This gives a finer control over how tokens are issued, but with unnecessary (in my case) overhead of having to manage this

   d. use basic http binding with TransportCredentialOnly security mode. this is nice because it stops SCT negotiation, while still passing a windows credential.

4.d was the easiest for me because i didn't have to do a lot of changes besides config. i am giving up wshttpbinding features, but so far this is ok because this conversation is happening within a trusted network.

这篇关于阻止 WCF 缓存/重用安全令牌 (SecurityContextToken)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！