Trying to create an framework 4.0 WCF basicHttp service hosted by IIS (6) that is completely unauthenticated. Once deployed, I can successfully retrive the WSDL via a browser.
However whenever I try and connect to it via WCF Test Client or via a visual studio generated proxy, I'm getting "The server has rejected the client credentials.".
This still occurs when I add <security mode="None"/>, but my understanding is that this is the default anyway ...
In the IIS virtual directory properties I only have anonymous ticked, and in the web.config file <authentication mode="None"/> is set as well.
Any ideas?
Seems like the IIS site has anonymous authentication disabled. Check out this article on IIS 6 anonymous access configuration.
Turns out that the source of the exception was from an immediate attempt to connect to a downstream tcp service. As a workaround I ended up creating a plain jane webservice wrapper which successfully connects to the downstream service fine using a domain account specified in the <identity impersonate="true" userName=".." password=".." />.
Note, I've added a related question asking why one works and the other doesn't.
Related
I've seen a lot of posts about the WCF double-hop issue with impersonation, but none of them have specifically helped me resolve my problem.
What am I missing? What else do I need to do in order to retain my Impersonated User (DOMAIN\UserName) over on Service 2? I'm looking at ServiceSecurityContext.Current.WindowsIdentity.Name to confirm - maybe that's wrong.
The Setup:
Client App hosted in localhost IIS with Service Reference to Service 1 - Impersonating WindowsIdentity (DOMAIN\UserName)
Service 1 - WCF Service hosted in localhost IIS with Service Reference to Service 2
Service 2 - WCF Service hosted in localhost IIS
I'm using ALL basicHttpBindings to keep things simple. I've set up SPNs on both service endpoints.
I can successfully MAKE the double-hop and the code executes just fine
In Service 1 (hop 1) my ServiceSecurityContext.Current.WindowsIdentity is the person that I impersonated (DOMAIN\UserName)
In Service 2 (hop 2), my ServiceSecurityContext.Current.WindowsIdentity is the IIS App Pool user
ImpersonationLevel = "Delegation"
Both WCF Services have Windows Authentication Enabled and Anonymous Disabled
** Note: I'm running this all locally on my dev box. Even so, I've had my delegation level set to allow delegation from myself to myself. Maybe overkill.
Binding (similar for both services):
<binding name="...">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
I've set the impersonationLevel = "Delegation" on both the WCF service client and the service endpoint behavior configuration. My service methods are specifically decorated with impersonationOption="Allowed" (hop 1) and impersonationOption"Required" (hop 2).
As it turns out, the critical piece in my case was ensuring the following behavior attribute was set:
<serviceAuthorization impersonateCallerForAllOperations="true" />
Previously, when I set this value, I was receiving errors in Entity Framework, so I undid the setting. It appears that somewhere along the line of aligning my setup to the standard implementation (as described in other varios posts) that I was able to eventually set this attribute and have it work as expected.
Edit:
If this all works locally, but doesn't work in a distributed environment, check out this post: How can I fix the Kerberos double-hop issue?. You probably need to set the machines to trust delegation between each other.
When trying to access my WCF service it is throwing following exception
The HTTP request was forbidden with client authentication scheme 'Anonymous'.
Inner Expeption: The remote server returned an error: (403) Forbidden.
Other observations:
It was working earlier
Same application when I set up on other system there is not error.
Using windows application from my system itself it works fine.
Situation:
WCF service is hosted in remote DEV server and I add as service reference in my web app.
For now Web app which consumes service is running from VS not by hosting in IIS
A real mess. Did anyone faced such situation? Please share with me. I google about the issue but non of them are helpful.
Check the application pool in which the service is hosted. If Windows authentication is turned on over there, then include it in the manifest xml file.
<system.web>
<authentication mode="Windows" />
</system.web>
For Reference : Click here
It could be that windows authentication is turned on on your local machine but not in IIS.
Double check the app pool your service is running under. Also, make sure the app pool is running integrated mode and that the version is correct.
See this article specifically step one.
I have started the WCF security token service template in Visual Studio. I get all things up and running over http. So now I have an STS, a WCF Service and I can call GetData(int) with the WCFTestClient. This is running on http.
Now I want to run the STS on https. So I've added it to IIS and added an https endpoint. If I browse to the sts it works on https now.
Next I create a WCF Service, add an sts reference etc. I add this WCF Service to IIS too, on https.
And the last step I create a console app, but then when I call the WCF service Cardspace is started and I get an error. First problem: I don't want Cardspace to start, and it shouldn't start as far as I know. Second: the error message is 'incoming policy failed validation'.
What are the steps to run the STS on https? Is there a tutorial?
Does anyone else finds this a familiar situation, and knows a solution?
I had the problem of cardspace starting myself and after checking the wif configuration several times I found some error in the config. After fixing the config error, everything worked.
Sorry that I could be more spesific one the error (too long ago). But be very, very sure that you have configured your sts and wcf correctly.
Did you try specifying the following: in your config under message.
<issuer address="stsurl" binding="ws2007HttpBinding"
bindingConfiguration="stsbindingconfig">
<identity>
<userPrincipalName value="fqnofUpn" />
</identity>
</issuer>
I have deployed wcf services in machineA and tried to accessed it through wcftestclient which is another system machineB. But i am getting error "The caller is not authenticated by wcf service". This wcf services is working fine when i testing it in machineA itself.
I have used wsHttpBinding.
How to solve this? Please help me.
on Machine A remove security if that service is only exposed in intranet.
Add binding configuration as follows
<binding name="none">
<security mode="None" />
</binding>
and In service add
bindingConfiguration="none"
If you don't want any security then only.
On machine B you'll have to supply some credentials that have access to the service on A.
See this article: Debugging Windows Authentication Errors for details, especially the section Client Credentials Are Not Set Correctly at the bottom of that document.
I have a WCF web service, and I want to use Basic authentication. I am getting lost in the authentication options:
In IIS 6 Manager, I can go in to the properties of the web site and set authentication options.
In the web site's web.config file, under system.web, there is an <authentication mode="Windows"/> tag
In the web site's web.config file, under system.serviceModel, I can configure:
<wsHttpBinding>
<binding name="MyBinding">
<security mode="Transport">
<transport clientCredentialType="Basic"/>
</security>
</binding>
</wsHttpBinding>
What is the difference between these three? How should each be configured?
Some context: I have a simple web site project that contains a single .svc web service, and I want it to use Basic authentication over SSL. (Also, I want it to not use Windows accounts, but maybe that is another question.)
The first two are really about access to an ASP.NET virtual directory or virtual application in IIS6 - that has basically nothing to do with WCF (WCF is actually not part nor dependent on ASP.NET). The settings control how the HTTP request coming into the IIS6 web server is being handled in terms of authentication. This basically controls whether anonymous callers from the internet can just call in without authenticating, or whether they need to enter username/password, or whether only callers with a valid Windows identity in this domain are allowed in.
The only reason this is interesting to your WCF service is the fact that when you host the WCF service in IIS (only one of the many options), then you have a (myservice).svc file that needs to reside inside a virtual directory. Of course, access to that SVC file is controlled by the authentication settings of IIS6/ASP.NET.
The security mode inside the <wsHttpBinding> section is the security-related definition of how the WCF service will communicate with its clients. Mode=Transport means, you're securing the actual transport layer - typically using SSL - not each message separately. This setting works great in Intranet scenarios where you have all clients behind a corporate firewall - but it won't work too well in Internet scenarios, since you can't really control the whole chain from the client (anywhere on this planet) over a series of intermediary hops to your server - you just can't. In this case, you'd have to use Mode=Message which basically encrypts and signs each message that goes over the wires - that works over any number of routers and relays along the way from the point of origin to your server.
The first two are related, if they don't match your service will not be able to activate. If you choose Windows authentication obviously there is an assumption that you will be tied to a windows domain or local machine.
Since you are going to be doing SSL basic authentication you are going to set this to None and then configure your transport security.
Your one stop shop for setting up transport + basic authentication
MSDN Article on Transport+Username + Windows Forms
I am not sure if you are still planning out how you are going to be doing security but i would recommend thinking about using message security versus transport(personal bias toward message security)..
Transport vs Message Comparison
Patterns & Practices on Message and Transport Security