I need to build a simple webservice to get data in and out of a HR System over the Internet (it's a hosted solution). I am using IIS and ASP.Net with .Net 2.0.
Having looked into it, there are several ways of making the webservice secure - I am after some advice on which method to choose, with some views on pros and cons.
These are the methods I am aware of:
Post the UID/PWD in a Soap header and implement a SOAP extension (link).
Pretty straightforward to implement and should be quite secure over SSL. This is by far my preferred option due to the relative simplicity. Also, for historical reasons, I will need to consume the webservice from VBScript of all things, so the ability to just deal with simple SOAP is a bonus.
However, are there any caveats? Am I going to have clients complaining this is a security risk?
I found a lot of old articles referring to WS and if I am not misstaken, this is what is now provided in WCF? This Microsoft link has a primer.
If I understand it correctly, this uses certificate-based security between client and server for authentication. Is this correct or have I got it completely wrong?
I suspect this will be a much bigger job, at least implementation wise. Also, I won't be able to access the Webservice directly from VBScript, so will have to write a dll it call call and then deploy that locally - correct?
Is this even available in .Net 2.0?
I would be very grateful for any advice on the best approach to this problem. If anyone has a good argument why Soap Headers are secure then I would love to hear it, as that seems like the simplest to use, as long as it is "secure enough".
NET offers the Web service developer two security options: rely on Windows security or provide custom security. You also need to disable anonymous access to the Web service. In IIS, display the properties of the Web service and select the Directory Security tab.
Security is critical to web services. However, neither XML-RPC nor SOAP specifications make any explicit security or authentication requirements.
The key Web services security requirements are authentication, authorization, data protection, and nonrepudiation. Authentication ensures that each entity involved in using a Web service—the requestor, the provider, and the broker (if there is one)—is what it actually claims to be.
You should strongly consider using IIS and Windows to provide the authentication. IIS can map incoming requests to an AD user (NTLM, Certificates, Kerberos, etc.). From there, you'll have a WindowsPrincipal you can use to demand that the user is in a group. If you don't mind compiling the group name into the code, you can even use the PrincipalPermissionAttribute on your service methods so it'd be completely declarative.
By using Windows, you get the platform to deal with all the security issues. Passwords won't be transmitted in plain text, nor will you need to create and specify your own challenge/response type system (yuck). Different clients could authenticate in different ways (require certificates for some, allow NTLM for others).
Finally, you'll end up with less code since you can use Windows to manage the users and the .NET Framework to enforce security checks.
Edit:
Maybe you think securing the ASMX is hacky because that's the only step you're looking at? I'd agree! A webservice that only depends that you've denied anonymous sounds very weak indeed. The webservice code itself should demand group membership after the authentication is done. That way if you misconfigure the server, you've made it inaccessible, not insecure.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With