Stop WCF from caching / reusing security tokens (SecurityContextToken)

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, it is a separate operation, and there is no need to save the state of the session.

  • I'm having a problem with the load balancer because WCF continues to use security tokens, so if the first call goes to NodeA, it creates a security token that is reused. If this token is passed to NodeB, a MessageSecurityException is thrown.

  • It looks like Microsoft advises using the sticky sessions that we learned, but that doesn't make sense in our setup.

Is there a way to simply force WCF to create a new security token on every call? (when using message-level security with a Windows credential type?

Update

i configure the trace on the client / server, and I can see that the token is cached for 24 hours.

 <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 TokenProvider release uses a cached service token.

I tried disabling the issuance of tokens 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 seems that the above does not affect negotiations at all.

I still see cached tokens being used.

+2
source share
1 answer

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

  • when using message-level security, WCF issues Security context authentication

  • this type of authentication simply relies on a sticky session, in no way around it.

  • there is a parameter that should disable it. SetSecurityContext = false, but this does not work. after installing this, I see in the trace that SCTs are used the same way as before (and I got someone at Microsoft to confirm that I did not do anything unusual here). Perhaps another dependence on this parameter, but the senior MS engineer did not know why this setting also does not work.

  • this leaves several options

    a. use "one shot" with Kerberos - I did not investigate this, because including Kerberos in my scenario would be a bigger headache

    b. use custom binding with NTLM based auth - I tried this, but SCT was still in use, so it didn't work for me

    with. Use federated security through a dedicated token issuing service. This gives you finer control over the issue of tokens, but with unnecessary (in my case) overhead for managing this

    e. use basic http binding with TransportCredentialOnly security mode. this is good because it stops SCT negotiation, but still passes Windows credentials.

4.d was the easiest for me because I didn’t have to make many changes besides config. I refuse the wshttpbinding functions, but for now this is normal, because this conversation takes place on a trusted network.

+3
source

Source: https://habr.com/ru/post/1269307/


All Articles