It's running into an Intranet, .net framework 3.5, hosted in IIS 7.0 and it's using wsHttpBinding with null security. Now I have to protect it to allow only specific users can run it.
Seems that I should use SSL and certificates but I'd really like stay away of that because looks complex, basically I'm looking for the simplest way.
I took a look to netTcpBinding and seems to me this is the right way, if so, can you confirm if using net.tcp it would be able to be consumed by some asp.net site.
Any comments are welcome.
Thanks,
In your case you have an intranet, which means that you have internal users. It depends where the call to the WCF service is coming from.
If we assume:
Internal users, who login to a windows domain
The client machines and the server are in the same domain
The user runs a windows app on their machine, which makes the WCF call
Then the simplest solution is to use windows authentication
The client makes the call in the security context of the logged on user
The server checks the group membership of the user to determin if it should allow access
You said you are using an Intranet app.
If so, you could turn on Windows Authentication, and allow only specific users in IIS (this is also controlled in the web.config). If everyone is on the intranet, it should authenticate automatically without users needing to enter a password or user name.
However, if anyone outside your intranet needs to reach this service, you'll need to include SSL & https to protect the credentials sent to the service.
Related
I've setup an Asp.Net Core 2.0 application following the guide here
The goal is to enable Windows Authentication. I've enabled NTLM and Negotiate. I'm working (and will update) on testing Kerberos and Basic as well, but I fear I might not get the automatic sign-in that negotiate brings.
The application works correctly, and when hosted on Service Fabric I can access it directly from the server IP and port. Windows authenticates correctly, everyone is happy, birds are singing, rainbows appear in the sky... its great.
However, when I try to access the application via the Service Fabric Reverse Proxy service, I hit a wall. My browser prompts me for credentials, and will not accept anything that I pass into it.
I fear this may be a limitation of the built in reverse proxy, but this is something so common that its hard to believe that to be the case.
Is there a way to enable pass-through Windows authentication for the built in proxy?
Note: This is not hosted in Azure, but on premises.
Update: Enabling Basic Authentication and Kerberos didn't help either. Basic authentication actually further complicated the issue. With just Basic authentication enabled, I got repeated 401s, even when connecting directly to the service.
My scenario is that I have to expose some API over WCF to third party clients. I wanna use the most secure option. Ideal solution would be making a windows account for each client in my server active directory and letting them access the service with Transport & Message security and Client credentials username. So I could ask the client to provide username and password and use windows group policy to role base authorization.
Since this is an internet facing WCF service, I'm not sure I could use windows accounts??? Should I be using database solution to manage usernames, pwd and roles?
Should be able to consume from .NET clients as well as Java clients. Third party clients could be anything that can consume soap.
What's the best security option to this scenario? VPN is not an option as this totally should go over internet. Your help is very much appreciated.
It sounds like what you need is some kind of a token based authentication setup. Microsoft seems to publish the best material in the game for this kind of thing. You can find their articles here and pick the scenario of security that most closely matches your needs:
Microsoft WCF Security
you can use ASP.net membership with form authentication for your service.
using windows authentication for internet facing service is not a good idea.
for more information:
How to: Enable the WCF Authentication Service
Windows Communication Foundation Authentication Service Overview
Securing WCF with Forms Authentication
We have self-hosted C# WCF service providing rest API over HTTPS.
Problem:Configuring the certificates for SSL requires admin rights. I assume it is to do with WCF depends on http.sys for http/https handling. The service is meant to be deployed on customer environments. So it would be nice if it can run without requiring admin rights.
Looks like WCF depends on http.sys,
Can I self-host an HTTPS service in WCF without the certificate store and without using netsh http add sslcert?
Like to know if any other embedded web server solution exist that support SSL and not requiring admin rights on the machine?
Checked so far,
http://nancyfx.org/
https://github.com/pvginkel/NHttp
Both doesn't seem to support SSL.
Most windows hosted web stacks rely on the HTTP Server API which is the API around the kernel HTTP stack (a.k.a HTTP.sys). The .Net HttpListener class does so as well (same as WCF, the OWIN self hosted asp.Net and so on which rely on it).
Just making sure, you do know you can authorize the identity you application runs under to bind to an HTTPS URL even if it's not running as an admin account, right? If you could gain admin right just for the installation phase that could solve you problem? (assuming you checked that already)
You can read more on a blog post i wrote about that here
To go into the effort of building an http stack on top of raw sockets would be a great effort and with little gain and so around .Net i doublt you would find anything like that.
Unless, it wished to be cross platform.
Any java based web server would probably do just that, using the JVM's http stack and relying on a java keystore to provide the required certificates for the SSL. (To keep it portable across different OS's)
If you wanna go java i am sure you can find many such web servers.
If you care to try and bind to a web server using CGI have a look at mongoose (Never used it to be honest).
Another option which comes to mind is to use an ssl proxy like Stunnel to stand in front of the web server. It would do the SSL part using non-windows certificate store.
I have a webservice that's behind form's authentication. The site that hosts the service also serves as a site that requires a user to log in via the login page.
I have a second site that needs to be able to access the service that the first site hosts. However, when attempting to access the service, it fails because the service requires that the user is logged in.
The first site is on a seperate server than the second site, but both sites are on the same subnet. Thus far the only way I have found to have the second site access the first sites service is to allow all users via a web.config setting specific to the directory that hosts the services .ASMX file. This is not acceptable because it leaves the door wide open to anyone who knows the .ASMX file directory.
I have attempted to mix and match windows authentication and use impersonation to access the web service, but according to microsoft, you cannot mix and match authentication types, and through personal trial, you can indeed not.
I'm looking for any helpful tips to help me accomplish this goal at a minimal reconfiguration of my two sites.
Thanks,
George
I implemented the solution by adding custom security to the headers on the SOAP packets. This allowed me to mix and match my security at a minimal reconfiguration to the service.
I want to write a web service using Visual Studio. The service needs to support some type of authentication, and should be able to receive commands via simple HTTP GET requests. The input would only be a method call with some parameters, and the responses will be simple status/error codes. My instinct would be to go with an ASP.NET Web Service, but this isn't an option in C# 4.0 and it makes me wonder if I should be using something that's more up-to-date. I've looked into WCF, but it seems like this requires a running application on the client-side - is there a way to query a WCF host by just accessing a URL?
The authentication is also an important piece. Developing my own little authentication system seems like a bad idea - I've read that it's too easy to mess up. What would be the standard way of authenticating with a web service like this?
I'd love to look up all of the specifics on this and learn it myself, but I really don't even know where to begin. Some direction would be greatly appreciated!
For a simple HTTP service that takes commands via GET (you should actually consider using POST...) I would use straight ASP MVC, not a true
'web service'. WCF wants to guide you down the path of SOAP and your clients will curse you forever. RESTful WCF is also an alternative, but it still seem overkill imho.
As for authentication, you have two viable authentication schemes:
Windows Integrated security, which will work only if client is inside intranet or connected with a VPN or DirectAccess solution
HTTP Digest, which is poorly supported by the ASP authentication modes (only support authenticating against a Active Directory forest user base).
With Windows authentication you don't do anything on the server side code, simply mark the the web.config <authentication mode="Windows" />. 'Windows' authentication is understood by most user agents. Is trivial to program clients of your service to use Windows authentication too, simple set the request's Credentials to the current user DefaultCredentials.
With Digest authentication the server will challenge the user agent to authenticate, but the ASP validation unfortunately, as I said, only works for validating a trusted NT domain. The client though does not need to be in the intranet (there is no NTLM SSPI exchange between client and server). Programming a client is faily easy, in .Net simply set the requet Credentials to a properly initialized CredentialsCache:
CredentialCache myCache = new CredentialCache();
myCache.Add(new Uri("http://www.contoso.com/"),"Digest", new NetworkCredential(UserName,SecurelyStoredPassword,Domain));
...
request.PreAuthenticate = true;
request.Credentials = myCache;
It is important to reuse the cache between requests, otherwise the client will do two round-trips with each call.
In theory you can also have a third authentication path: full duplex SSL. But the 'trivial' problem of client certificate deployment makes this alternative a dead end for anybody short of a fully pre-installed enterprise PKI.