I have spent some time investigating an issue relating to the configuration of WCF web services for SCT as described in this article and specific service accounts.
It turns out that when your web service is setup like this and you assign a specific service account rather than use the network service account or the new Application Pool Identities, you may get errors such as “The token provider cannot get tokens for target” or “Secure channel cannot be opened because security negotiation with the remote endpoint has failed. This may be due to absent or incorrectly specified EndpointIdentity in the EndpointAddress used to create the channel. Please verify the EndpointIdentity specified or implied by the EndpointAddress correctly identifies the remote endpoint” or “The request for security token has invalid or malformed elements”.
These errors are somewhat misleading as to the underlying cause. Instead of having anything to do with security negotiation and tokens per se, I deduced that it appears to be related to the service account not having a user profile on the server. In fact the article above does mention this in the following paragraph, although at first it isn’t an obvious link to the errors highlighted above.
“For applications that use stateful SCTs in a secure session, the thread identity for the service must be a user account that has an associated user profile. When the service is run under an account that does not have a user profile, such as Local Service, an exception may be thrown.”
Anyway, in order to get around this you can either logon as the service account on the server as part of the deployment (probably not the best option) or change the “Load User Profile” option in the associated Application Pool to True. This will create the user profile for the service account the first time the service is instantiated. You can then change this option back to false if you wish.
I would be interested to know exactly what it is from the user profile for the service account that is required when the requireSecurityContextCancellation attribute is set to false, as firstly I would just like to know, and secondly I don’t believe either of the options above are elegant. If anyone can shed any light feel free to let me know.