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:
SoapHeaders over SSL
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?
Using WCF with TransportWithMessageCredential
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?
Other methods
- I could disallow anonymous access to the asmx file and use rely on IIS to do authentication through challenge/response. This is actually practical in my scenario but feels very inelegant (and no idea how to make that work from VBScript either).
- Passing in a UID to the method call is a poor cousin of the SoapHeader so I won’t use that.
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’.
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.