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

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

Step #1 - managing the resource through .config

Apply 61 a <location> tag for the resources you want secured. Assuming 60 it's a single ASMX file you can simply do 59 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 58 to decide how you're actually going to authenticate 57 users. There are several ways to do this 56 and several authentication standards you 55 could leverage. You need to pick the approach 54 that's the right fit for you.

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

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

<authentication mode="Windows" />

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

Step #3 - securing the resource

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

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

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

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

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

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

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

You can stop WSDL being shown by removing 10 the Documentation protocol from the element 9 in Machine.config

Update: Web Services authentication - best practices? If your users 8 have usernames/passwords you can use HTTP 7 basic authentication via HTTPS.

You can also 6 implement it in a slightly differnt way. The 5 first call to your web service should be 4 the authentication method. Client authenticates 3 and receives an authentication token. This 2 token should be presented to all other methods 1 exposed by your web service.

I don't know how practical this is for you, but 6 you could consider upgrading to WCF. WCF 5 is fully backward compatible with ASMX web 4 services, and lets you control whether or 3 not the WSDL is exposed by defining a MEX 2 (metadata exchange) endpoint. No MEX endpoint, no 1 WSDL.

Two options: Create an entirely different 14 site on a different port with locked down 13 permissions. This has the advantage of 12 providing some amount of "security through 11 obscurity" (half joking...) Or you can 10 add a new Application under your site(same 9 port, different path), on a different app 8 pool and assign permissions that way.

In 7 either case, your web service isn't going 6 to be able to talk with the various ASP.NET 5 "things" like the application object (well 4 it will, but it won't be the same one). Deployment 3 is only slightly harder: deploy the same 2 binaries, but only include the one web service 1 file.

You can authenticate using an HttpModule. SSL 6 + BasicAuthentication should yield the best 5 interop with other tool chains.

In the HttpModule, you 4 have access to the request and can deny 3 unauthenticated users access to just .asmx 2 requests. And even then you might let them 1 access the WSDL.

Add <add path="*.asmx" verb="*" type="System.Web.HttpForbiddenHandler" validate="True" /> to the <httpHandlers> section of the web.config file

0