Is it possible to have a web service require ssl on some urls but not on others? The service as a whole provides 1 function but talks to 2 different clients. I can split it into 2 different services if necessary but was wondering if it's possible.
In IIS (i'm using version 7), there is a option for you site called SSL Settings, in there make sure the Require SSL checkbox is unchecked. This will not force SSL on the service.
However, this will not prevent your SSL required client from using the non SSL link, it will basically allow you to hit the service with and without SSL.
Related
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’m building a webservice and having some troubles witch option I should choose. Therefor I was hoping someone could point me in the right direction. I found many articles but none of them have more or less the options then I want.
What I want the webservice to do:
Client should get a WSDL derived from the ASMX file. Within that service there is one unauthenticated webmethod called “Authenticate(string Username, String Password)” that returns a custom AuthenticationSoapHeader. The AuthenticationSoapHeader is exactly and preferably same as the System.Web.Security.FormsAuthenticationTicket class that is used in the webapplication.
http://www.codeproject.com/Articles/4398/Authentication-for-Web-Services-using-SOAP-headers
http://www.codeproject.com/Articles/27365/Authenticate-NET-Web-Service-with-Custom-SOAP-Head
I’m thinking of using the articles above to implement this and changing the username password combination for a ticket that will be encrypted including a datetime stamp to expire the ticket. My questions.
Would this be considered a best practice? If not, what better option do I have.
Is using WSE3 “Microsoft Webservice Enhancement” necessary?
Is WCF a better option if your kinda new to webservices?
The soap requests go over Https SSL and do not need further encryption on the client side. Thank you in advance.
Best regards,
Danny
I can't answer all these questions, but I can answer a few: IMO WCF is all you need as a tool set for this project, based on your description. WCF has a number of different flavors (http, TCP, etc.) and each has several different options for how you implement security.
WCF has options for user/pwd authentication, or you can construct a custom method, or you can construct a Login() function that takes a UserID and Password as parameters, returning a boolean. There are also options that allow you to authenticate BEFORE the main program receives the request. That's what the built-in UserID/Password authentication does.
If you implement SSL on the host, assuming you're using an http-centric binding, you won't need anything on the client side for encryption as the WCF software will take care of that, once you have both the Host and Client software configured properly. In effect, your WCF client app will behave like a browser, handing all the nasty cert stuff under the covers.
WCF also lets you a) run your web service as a stand-alone windows service (called "self hosted"), or b) allows you to configure your web service behind IIS, which has some advantages. WCF will also provide a WSDL for your clients if needed.
There are some other nice things about WCF; if 10,000 concurrent users hit your web service at 8 am on Monday, WCF automatically queues the requests it can't handle, processing them in order as it can. I've slammed our testing web service with numbers like that, and the program never broke down, processing >150 logins and file uploads / second. WCF is also works fine with Java, iOS and Android.
I need to call a .NET SOAP webservice in a secure way. It must be secure in such a way that others can't call the WebService methods, and also it should not be possible for "the middle man" to understand the content of the messages.
The caller will also be a .NET webapplication installed on another IIS.
I can design the webservice methods as I want, so no restrictions there.
I have been researching HTTPS/SSL with certificates, but I don't know if it actually solves my problems in a good way? For example, it would be anoying if the certificates has an expiration date, although it's not a showstopper in any way.
So how would I go about this in a good way..?
Thanks for any help.
As #BrokenGlass said, SSL only encrypts the traffic between points. It doesn't handle securing individual functions from usage without authorization. Here is a good article on just such a topic using SOAP headers:
How to: Perform Custom Authentication Using SOAP Headers
This can be mixed with any form of authentication except Windows Integrated. To use Windows authentication, you'll need to have a separate library which accesses the Active Directory through the DirectoryServices namespace.
Assuming you control the infrastructure then keeping the server that is providing the web services behind a firewall so it's accessible only from the web servers and implementing IPSec should provide the necessary security.
From the software point of view, this article contains all you need to know about protecting the service interactions.
HTTPS/SSL works fine. Just make sure to renew your certificate in time to avoid warnings and messages for your client.
I need to call a .NET SOAP webservice in
a secure way. It must be secure in
such a way that others can't call the
WebService methods, and also it should
not be possible for "the middle man"
to understand the content of the
messages.
HTTPS/SSL only solves the "middle man" part of what you want to achieve. You would still need proper authentication in place on your web service. You could do this i.e by using the built in Forms authentication and providing a Login method that returns your authentication ticket.
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.
This the situation: I have one webservice without SSL, which provides two pages for the other web application. When the user submits these pages, an XML file with private information is sent to the webservice.
How can I provide the necessary privacy protection on the XML file? Is the one certificate good enough to give the appropriate security?
I'm not sure about this one, and am in the preparation phase of a project... So need to know the involved work on this part...
As an alternative to SSL you could encrypt the file yourself using any of the algorithms available in using System.Security.Cryptography but then you have to work out a mechanism to exchange your key(s).
However by far the easiest way will be to have both web services using SSL endpoints. That will take care of all your confidentiality, integrity and identity considerations in one fell swoop.
Certificates are tied to the hostname of the server (or, with wildcard certificates, all the hosts in a domain). So if the two services are on the same host, then both can use the same certificate.
If they are not on the same host there will be no transport security on the non-SSL service unless this is added separately. WCF has support for message (or part of message) encryption.
The simplest solution is certainly to use TLS, ex-SSL (widely supported in every programming language).
There is no need to buy a certificate (and it brings no extra security, it is mostly there to make PHBs feel better): either create self-signed certificates or set up your own CA.