Is there a way to restrict access to an ASMX Webservice, i.e. the asmx page and its WSDL?

Question

I have a C# .net webservice that I need to restrict access to. I already require my consumers to use a username and password to call the service. But, is there a way to restrict access to the actual asmx page and the WSDL? I would need to restrict access to the webservice by username/password and IP address. If a user did not have the correct credentials, I would not want them to know what webmethods exist in the webservice.

Can this be done though IIS? I know that I can restrict IP addresses through IIS, but can I also use usernames/passwords?

Is there any other way to do this outside of IIS, maybe using C#.net?

Answer 1

Well, since it's ASMX you have the entire ASP.NET runtime stack at your disposal.

Step #1 - managing the resource through .config

Apply a <location> tag for the resources you want secured. Assuming it's a single ASMX file you can simply do the following in your web.config:

<location path="MyWebService.asmx">
    <system.web>
        <!-- resource specific options will go here -->
    </system.web>
</location>

Step #2 - authenticating your users

You need to decide how you're actually going to authenticate users. There are several ways to do this and several authentication standards you could leverage. You need to pick the approach that's the right fit for you.

If you're on an intranet and are using Windows authentication I would highly suggest leveraging that because it's truly the simplest option to get setup. However, if your services are being accessed over the internet then Windows authenticatio is not really an option and you need to choose from a web standard. The simplest of those is Basic Authentication, but you should only use this over SSL since the username/password are not encrypted (only base64 encoded). The next step up from that is Digest authentication which doesn't require SSL because the username/password are sent using an MD5 hash. For the ultimate you can go with SSL v3 where you issue a specific client certificate to each user of your API.

Now, which option you select for security dictates what else needs to be done. If you choose Windows security, it's as easy as adding the following element to the <system.web> element we started with in Step #1:

<authentication mode="Windows" />

The remainder of the security protocols are going to require a little more work. ASP.NET doesn't provide intrinsic support for Basic, Digest or SSL v3. Technically you can leverage IIS to do this type of authentication for you, but it's always going to map to a Windows user. If that's an option for you, then simply leave the <authentication mode="Windows" /> element and configure IIS accordingly. If, however, that is not an option, either because you simply have no control over IIS/ActiveDirectory or you need to authenticate against a custom user database, then that means that you need to hook up a custom HttpModule to provide support for these security protocols.

Step #3 - securing the resource

The simplest approach to securing the resource is to basically say: "don't let anyone who hasn't successfully authenticated in some way into this resource". This is done using the following authorization configuration:

<authorization>
    <deny users="?" />
</authorization>

If you wanted to only allow certain users you could change to do the following instead:

<authorization>
    <deny users="*" />
    <allow users="jdoe, msmith" />
</authorization>

Another approach is to define roles (groups) and simply lock the resource down to a special role which you put the users who you want to access the resource into.

<authorization>
    <deny users="*" />
    <allow roles="My Service Users" />
</authorization>

This maps well to Windows authentication because you can just setup a Windows group and let your MIS team manage which users are in that group using ActiveDirectory. However, the feature also works just fine for non-Windows authentication assuming the security implementation you've used exposes roles via its IPrincipal implementation.