tracing rich client wstrust signin processing

[robertob]

if I configure fiddler | tools | fiddler options | https | capture https connects + decrypt https traffic [ ...from all processes ] + ignore server certificate errors then I can successfully use fiddler to trace browser client wsfederation signin processing.

 

when I try to trace rich client wstrust signin processing, e.g. using those generated by implementations like the following, it fails with a FaultException where InnerException message = "An error occurred when processing the security tokens in the message."

 

If I simply disable fiddler capture the same code works.

 

Any insights as to the fiddler configuration setting I need to make to enable tracing rich client wstrust signin processing?

 

var binding = new CustomBinding(new BindingElement[] { SecurityBindingElement.CreateKerberosOverTransportBindingElement(),
    new HttpsTransportBindingElement() { AuthenticationScheme = AuthenticationSchemes.Negotiate } });
var wsTrustChannelFactory = new WSTrustChannelFactory(binding, adfsaddr + "/adfs/services/trust/13/kerberosmixed");
wsTrustChannelFactory.Credentials.Windows.ClientCredential = CredentialCache.DefaultNetworkCredentials;
wsTrustChannelFactory.Credentials.SupportInteractive = false;  // optionally disable prompt for creds if default creds fail
wsTrustChannelFactory.TrustVersion = TrustVersion.WSTrust13;
var wsTrustChannel = wsTrustChannelFactory.CreateChannel();
var rst = new RequestSecurityToken();
rst.RequestType = RequestTypes.Issue;
rst.AppliesTo = new EndpointReference("https://myrelyingparty.domain.com/");
rst.KeyType = KeyTypes.Bearer;
var securityToken = wsTrustChannel.Issue(rst);

 

 

 

 

 

 

[EricLaw]

Unfortunately, there's such a high level of abstraction in this code sample that it's very difficult to have any idea what's going on. Is Windows Authentication used in this scenario (e.g. are there any HTTP/401s in the response)? If so, have a look at http://blogs.msdn.com/b/fiddler/archive/2011/09/04/fiddler-http-401-authentication-workaround-to-support-channel-binding-tokens-removing-endless-prompts.aspx

[robertob]

Yes this wif wstrust [ soap call ] signin using the /kerberosmixed endpoint and DefaultNetworkCredentials results in an integrated windows auth (iwa) negotiated connection occurring between the client running this code and my corporate adfs server.  

 

There may be corporate kerberos ticket generation server traffic involved in establishing this connection, not sure.  I'd assume one would have to attach a network sniffer such as old netmon or newer wireshark option to capture non-http traffic being exchanged.

 

I tested what you outlined in your blog post http://blogs.msdn.com/b/fiddler/archive/2011/09/04/fiddler-http-401-authentication-workaround-to-support-channel-binding-tokens-removing-endless-prompts.aspx but it didn't resolve the issue, I think because the client proactively generates some initial soap request that is signed which passing thru fiddler for that one call to my corporate adfs server ends up corrupting.  If we could tell fiddler to not proxy alter that request/response exchange I think we'd be in business.

 

Others that I've been working with on legacy wstrust signin based scenarios are seeing this as well so that would suggest its not just something messed up on my dev wks.  Attached is a fiddler trace of the request/response where this issue arises and a simple console application that allows one to repro it.

[robertob]

status update

 

I trust tried the following settings again my negotiated connection sigins are working in case of browser wsfed sigins but not the wstrust signins.  So that is some progress wrt at least being able to do fiddler capture in the wsfed signin negotiated connection case.  

 

e.g. fiddler | ctrl-r | ctrl-f "function OnPeekAtResponseHeaders" | insert following block at start of function
// To avoid problems with Channel-Binding-Tokens, this block allows Fiddler itself to respond to Authentication challenges from HTTPS Intranet sites.
if (oSession.isHTTPS && (oSession.responseCode == 401) && // Only permit auto-auth for local apps (e.g. not devices or remote PCs)
    (oSession.LocalProcessID > 0) &&  // Only permit auth to sites we trust
    (Utilities.isPlainHostName(oSession.hostname) || oSession.host.EndsWith("corp.sts.microsoft.com")))
{
    // To use creds other than your Windows login credentials, set X-AutoAuth to "domain\\username:password"
    oSession["X-AutoAuth"] = "(default)";   
    oSession["ui-backcolor"] = "pink";
}