Can anyone give a clear explanation of the difference between using
clientCredentialType=Windows, and
clientCredentialType=Ntlm
in a server-side Web.config when hosting a WCF service?
I have a SOAP 1.1 (basicHttpBinding) service for interop with existing clients. It uses ASP.NET roles so needs clients to be authenticated.
When I am using the VS2005 (Cassini) server to host the service, I have to specify ClientCredentialType=Ntlm as above, and check the Ntlm authentication box in the project properties in VS2005. ClientCredentialType=Windows doesn't work - clients get a:
401 Unauthorized error
However when I'm running under IIS, it's the other way around: ClientCredentialType=Windows works, and ClientCredentialType=Ntlm fails.
Can anyone explain this, and preferably suggest a way I can have the same web.config file to run the service in Cassini and IIS?
Update
I have .NET 3.5 SP1 on my dev machine, which is XP SP2 running in a domain. Cassini therefore runs under a domain account, and IIS 5.1 under a local account.
I wonder if it could be related to the breaking change in .NET 3.5SP1 described in these articles.
http://www.aspnetpro.com/newsletterarticle/2008/12/asp200812ab_l/asp200812ab_l.asp
http://msmvps.com/blogs/alvin/archive/2008/11/14/net-3-5-sp1-breaking-change-to-wcf.aspx
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=354236
The situation sounds similar as clientCredentialType=Windows fails when the server is running under a domain account (which is my situation with Cassini - running as my normal domain user account), and works when running under a local account (which is my situation with IIS).
The problem is that the suggested fixes require changes to a WCF client configuration file - but in my case I'm using SOAP 1.1 (basicHttpBinding) with non-WCF clients.
clientCredentialType=Windows uses the built in Windows authentication which can be through Active Directory and NTLM.
Obviously the NTLM type will only use NTLM for authentication.
I'm sure you've seen it already, but here is a link to WCF security:
http://msdn2.microsoft.com/en-us/library/ms734769.aspx
Some more details on your setup would help. Are the IIS and Cassini servers running on the same box? If not do you have the same accounts setup on each box? IIS6 by default supports NTLM, so you shouldn't have a problem getting it to work.
Related
When using Kestrel with IIS you define an Application Pool and identity (user). The default identity is "ApplicationPoolIdentity" but can be one of the following or a custom user:
When the application runs, Kestrel runs under the Identity you defined in IIS:
However, when using Kestrel behind a proxy server such as nginx (or standalone) what is the recommended "identity" (user) to use and how does one go about using it with Kestrel?
When you host Kestrel behind a proxy on Windows it is recommended to host the ASP.NET Core app in a Windows Service. Nginx would be configured to reverse proxy the applications url (e.g. http://localhost:5000) and the ASP.NET application would run under whatever user the service is configured to run as.
If you are hosting on Linux then you are responsible for creating your own service using whatever technology the underlying operating system provides (e.g. systemd, upstart, etc.)
The 'recommended' identity to use depends on what resources the ASP.NET app needs to access. The LocalService account has the same privileges as a member of the Users group.
You seem to be confused here. What you're talking about is the Application Pool Identity (which is what the window is even labeled as). The App Pool is essentially the process that serves your website. Processes run under accounts, be it a system, service, network, or user account. What account the process runs under determines (obviously) it's permissions and access. By default, in IIS, App Pools run under ApplicationPoolIdentity, which is just a local service account, with relatively limited permissions.
None of this has anything to do with Kestrel. Kestrel is just a simple web server. IIS merely acts as a reverse proxy. It accepts requests, hands them off to Kestrel, gets the response from Kestrel, and then sends that response back to the client. IIS gives you your security and administration layer, while Kestrel just handles the grunt work of serving the requests.
As a result, IIS can be interchanged for pretty much any web server than can act as a reverse proxy, such as Nginx. This would work the same way. Again, you don't define anything with Kestrel. It's just grunting along serving the requests the reverse proxy forwards it. It doesn't know or care what that reverse proxy is, and it doesn't matter.
That said, in either scenario there is no such thing as a "recommended identity" to use. This is a security aspect you are responsible for making a decision on. IIS has a default service account and Nginx probably has one as well. (I haven't run Nginx on Windows, but on linux, it literally runs under nginx:nginx.) For some, that's fine. Others decide to use a dedicated network account or a custom local service account. Still others decide to run under an actual user account. There's various reasons for each option and there's no one "right" way to do it, only a "right" way for your app, your server, your network, and your organization. No one can make those decisions for you.
I have a scenario where I want to consume a Webservice from a different server within our corporate network using JQuery. My origin application is an ASP.NET Website running on IIS 7.5, the Webservice is running on an SAP Netweaver Gateway, so no Chance to allow my IIS host there or to use JSONP.
The problem is that I run into the CORS issue, so I installed ARR on my IIS machine and tried to do a rewrite url and use my IIS to consume the remote Webservice. But the problem is, that the target Webservice requires Certificate authentication and it seems that this is not supported by ARR. Am I correct?
Any help is appreciated,
Oliver
I have had a similar issue, in my first try I had both my application and ARR running on the same box and this was causing the Application's Authentication module to start first before ARR and was messing up the things, I found success when I had both of them run on different boxes. Below link helped me
http://blogs.msdn.com/b/asiatech/archive/2014/01/28/configuring-arr-with-client-certificate.aspx
I have a number of WCF 4.0 rest services on an internal application server which are accessed from a DMZ'd public facing web server. Essentially I am looking for the simplest way to restrict access to the services to calls from the web server and select internal accounts. It seems like a simple task of which I can find no simple answer.
Info:
IIS6 for both the web server and the application server
.NET 4
Web Server is not a part of a trusted domain
REST Services are 100% code.
Client calls are passing credentials via System.Net.CredentialCache.DefaultCredentials ( not sure if this is the way to go )
For the network part, you can disallow all IP's except the one of the ones you trust in IIS.
I have created and tested a WCF REST service that is protected with SSL and Windows Authentication through IIS 7. I have also created and tested a pure html/javascript web client that is hosted in IIS 7 that is protected with SSL and Windows Authentication -- same server, different "site" within IIS. The REST service is not public, but the web client is.
Without security, everything works beautifully, but now we are ready for field testing and security must be implemented.
My end goal is to have the user visit mywebclient.com and authenticate using their Active Directory accounts. Initially I thought it would be safe to leave the service calls from the client to the REST service unprotected (since the traffic from the web client to the web service would be internal), but this does not protect us from an internal attacker. Also, in the future, the REST services will be available to handhelds through native applications.
I've tried to gain as much information on this subject as possible, but every piece of Microsoft documentation contains client examples written in .NET.
How can I share the security context between these sites without converting the web client to a .NET-based application? Could this be accomplished by combining the web client and service into one IIS "site"?
Edit: If the client and service exist in the same app pool, does that mean they could share authentication information between client and server processes?
Two weeks ago I needed a way to communicate a wcf service with a windows service running on the same computer. The windows service had to get data from a external source and share it with the wcf service (hosted in IIS) who had to give it when a client made a request. I chose to do that with ipc.
I done it and now the windows service is the ipc server and the wcf service is the ipc client. This goes well but I think I made a mistake doing this because to make it run right the windows service must to be executed with the ASPNET account, for this the ASPNET password account must be assigned and when I do that the IIS does not work correctly.
I am thinking on different alternatives, but in all of them the problem persists. Some ideas?
Edit:
What I needed was a system that made public, in a web service hosted in IIS, data gotten through telnet from another old system, what is a little unstable. How the response of this second system was slow I chose to put a process (the windows service) between the web service and the old system. The windows service had to save the data collected from the old system and when the wcf service asked it give it all at once through ipc.
Why does the windows service need to run as the ASPNET user? Is that because you're using an IPC connection that requires authentication from the caller?
Another alternative (if you have control over the windows-service code) would be to make that a WCF service as well (using a ServiceHost in the windows service). The IIS service could connect to the windows service using a NetTcp or NetNamedPipe binding if you need the IPC-like performance.
Why not just create another account with the same permission set of the ASPNET user which both the WCF service and your other service run under? That way, you have control over the password.
Ideally, the windows service should run as a WCF service, that way its easy for the client to communicate with it.
The next question is weather the 'client' needs to be a WCF service. If this client needs to serve other applications then it is appropriate, otherwise it may not be nessesary. I don't know enough about your system, so its up to you to decide what's best!