asmx web service: client authentication

Question

I have a web service with a bunch of methods that I'd like to somewhat secure. The data is not really all that confidential, but I'd still like to restrict access to only those who use a certain user id and password that's stored in the web services web.config file. A C# Windows service client will be calling this web service once a day or week.

Can anyone post a simple example of how I can do this? Thanks in advance.

Solution 1

This is pretty similar to my question: "What should we implement to authorize clients to use our web service?"

We ended up not publishing the WSDL and only serving up the service via https and requiring basic authentication. DON'T use basic auth if you can't force all clients to use https.

If this is a .net web service then here is the config file entry to keep the wsdl from being published.

  <system.web>
    <webServices>
      <protocols>
        <remove name="Documentation" />
      </protocols>
    </webServices>
  </system.web>

When you goto the page, you'll receive an error message similar to the message you'd get if you tried to manually pull down a web.config from a site. As Steven points out, this is security through obscurity and should NOT be used by itself to secure your web service. However, when used in addition to basic auth + https, its a nice little extra.

Client Side Code:

To access this web service from a client, add your web reference the normal way and in the calling code (assuming your web reference is named WebRef).

WebRef.Url = "url";
WebRef.Credentials = new System.Net.NetworkCredential("userid", "password");

Also, you may want to look into WebRef.PreAuthenticate to save some round trips. Just be warned that you'll have a fun time testing that out if you're behind a corporate proxy. Proxies are used via the WebRef by

WebRef.Proxy = new WebProxy("url");
WebRef.Proxy.Credentials = new System.Net.NetworkCredential("userid", "password");

Solution 2

There are three general approaches to ad hoc SOAP security:

1. The first is to pass the authentication information with each call.
2. The second is to pass it in once to receive a session ID that is then passed in with each call.
3. The third is essentially the same as the second, only using cookies.

Of the three, I recommend the first method, which does not require the server to maintain state, but can be just as fast due to caching.

Comments

[Steven Sudit]

This is not an unreasonable additional step, but it's security through obscurity, since nothing about https authenticates the client, so the whole thing falls apart the moment the server's URL is discovered (and it will be). Having said that, requiring https and using basic authentication is reasonable.

[Allen Rice]

Absolutely, not publishing the WSDL is security through obscurity. However, https + basic auth + some security built into the web service code itself is not security through obscurity. If the URL is discovered, they will not have the WSDL which is what was desired.

[Allen Rice]

By session ID, are you referring to token based security? Thats what I typically hear it referred to as. Also that "first method" can be wildly different and completely ineffective depending on how he sets it up. I.e. Basic Auth without HTTPS which is worthless since the login and password are sent in plain text.

[zSynopsis]

I don't have access to the server where the web service will reside so i'm not sure if they'll be able to set up https only access. Is there any other method that you can recommend?

[Allen Rice]

If you don't really care, skip the https and only go with basic auth shrugs. If you are somewhat serious, ask them to require https. You'll have to pay for a certificate and they will have to install it. ANY hosting provider you have should be able to require https only, its amazingly simple to do, just one checkbox

[zSynopsis]

Okay i guess i'll ask them. Another question. Do you happen to have some sample code of what the the authentication would look like on the web service side?

[Allen Rice]

There is no code on the server side, basic auth is setup via IIS and your host will have to do that. Its common and they should be able to set it up for you. Both requiring https and using basic authentication are very common (except for the modification of the web.config), so don't feel like you're asking for something amazingly special :)

[Steven Sudit]

@Allen: Agreed. While we can't depend on security through obscurity, once we're already secure then there's no reason to avoid having a defense in depth. With connections encrypted and the WSDL unavailable, the job of a hacker is made all that much more difficult, in that they'd now need to reverse engineer the client.

[Steven Sudit]

Sort of, though it can be as simple as a GUID. What matters is that it's big and effectively random, so it can't be gussed at. You don't need to send anything in plain text, either. For example, you could call GetChallenge to receive a GUID, then call LoginWithResponse, passing in that GUID, along with the cleartext account name and the hash of the concatenation of the GUID, account and password. Or, of course, you could use HTTPS, which solves it from another direction.