This question came up a few times while I was away for my honeymoon: “If I am using BasicHttpBinding or WsHttpBinding, how do I setup the credentials for my proxy?”
In my earlier post on HTTP proxies I noted that all of our transport security implementations (including HTTP proxy authentication) leverage the shared WCF-wide credential provisioning framework. As a result, it’s pretty straightforward to configure your proxy credentials. I think what trips people up is that we don’t have a separate “ProxyCredentials” object. Rather, both the proxy authentication and the ultimate server authentication access credentials from the same location (such as ChannelFactory.Credentials).
One limitation of this approach is that if you are using the same authentication scheme for your proxy and your server, then you have to use the same credentials (e.g. the same username and password for Basic Auth). This was a concious tradeoff we made for V1. If any of you have a scenario that is broken by this limitation I’d love to hear about it.
Hi, I have a scenerio where we use the same authentication scheme for the proxy and my server, and the implemented scenario of WCF isn’t sufficient. My service uses MessageSecurity with username and password. And I have some clients who use a proxy which requires a username and password. The most logical solution is to at my username and password to the proxy and the problem would be solved, but for security reasons we generate passwords for all our clients and these passwords are send encrypted to the clients. This is done so that the customer doesn’t know his own password. But because of this limitation the client can’t add a user to the proxy with my username/password combination. Is there a solution to this problem except providing the customer with the generated password.
Hi Kenny,
I have problem getting through my proxy using a WCF client and calling a WCF service.
The proxy server uses windows authentication (different windows domain than client) and the WCF service uses username token.
The service is being hosted in IIS and am using basicHttpBinding.
I have tried many combinations and none seem to work. Can’t get past the proxy with 407, proxy authentication required.
My code looks like this:
// username token credentials
math.ClientCredentials.UserName.UserName = @”TheUser”;
math.ClientCredentials.UserName.Password = “Mickey1”;
// proxy credentials
math.ChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential(“domainuser”, “password”, “domainname”);
// call method now ….
My configuration looks like this:
Any help would be greatly appreciated it.
Regards,
Sergio
>> This was a concious tradeoff we made for V1
What is the situation in the .NET 3.5 version of WCF?
Thanks, Andrew
We have the same situation in 3.5, sorry 🙁
I’ve since come to the conclusion that it doesn’t matter.
WCF does not need to be used to provide credentials to the HTTP web proxy. Instead let the binding object use the default web proxy (it does so by default), and enable the supplying of the user’s default credentials for proxy server authentication by adding the following to your client app’s App.Config file:-
The fact that using the user’s default credentials for proxy auth is disabled by default is what trips up so many people. And it’s quite hard to enable it in code; the best place is in the XML config file.
For further reference, see here:-
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2497236&SiteID=1
Andrew
OK, so this forum stripped out the XML that I included in my post above! But visit the link to the MSDN forums, and scroll down to my third post on that page to see what you have to put into your App.Config file.
Andrew
I’ve got a situation that is problematic. Our application is using UserName message credentials for authentication and is being deployed in somewhat uncontrolled environments. We know there are proxy servers out there, and we know some of them use authentication which is not NTLM or Windows security based.
What we don’t know is whether the clients will be willing to save their credentials and thus be able to use the default proxy server. It seems like a smart thing to do given the limitations, but we don’t have a strong enough survey of customer environments to know for sure.
We’ve put together the steps to prompt for credentials, but where do we put them? We’re already filling ClientCredentials.UserName with the credentials to our server, and even though it’s not Basic Auth, we feel kind of stuck. I’ve spent alot of time digging through the ServiceModel library with Reflector and am a bit disappointed with how HttpChannelFactory.CreateAndOpenTokenProvidersCore was implemented. If you had left anything in there that would have allowed me to write a custom SecurityTokenProvider I’d do that, but the SecuritTokenRequirement for both is so similar it doesn’t look like that would work.
We have a similar but not identical situation. We run our service centrally, and deploy our client to customers via ClickOnce. Customers run the client in whatever network environment they happen to be in. Some of them are using proxy servers with Windows authentication, authenticating against an AD in their environment but not using the currently logged in Windows identity.
Our service also requires Windows authentication, but of course it authenticates against an AD located centrally with us. In other words, two completely separate user stores are used for the two types of authentication. Is there no way around this limitation?
Pingback: Setting a Web Proxy on a WebService in .NET 3.x