There's no explicit support for security at the handler level for wwCallbackHandler. This means that if you need to secure access to your service handler you will need to use one of ASP.NET's security mechanisms to secure the service or build explicit authentication into your service itself.

Note that your ASP.NET server side code in the Callback methods has access to the security principle (HttpContext.Current.User) so your code can validate authentication as needed as long as the IIS/ASP.NET security is in place.

Page Security Context in AJAX calls

Typically the service handler will be called as part of inline AJAX requests from pages and in those scenarios the service request inherits the security context of the page. In many situations this security context is sufficient - for example once you are in an authenticated part of the Web site AJAX calls just work against a secured service because the user is the same as the logged in Web browser. So if you have Windows or Forms security set in a directory of your application the authentication automatically is passed on to the service AJAX call with the same credentials.

Explicit Access

If you have explicit external access (ie. cross domain or pure REST access from other applications) you may not be able to take advantage of existing Page security and so you will need to have your client authenticate the raw HTTP requests (ie. set the Principle with HttpWebRequest etc.). Again security for the server will have to be configured at the server level either with Windows Security on the service resource (ie. an .ASHX file) or by using an explict authentication scheme as part of the request (ie. pass username and password or an assigned token after an initial login).

Security Modes

You have few choices for securing services, which basically are the typical set of options you have with ASP.NET and Authentication:

• Forms Authentication
  This works well only if you're using AJAX callbacks from the same site/virtual as you would need to first login to a page before any AJAX callbacks and be made and succeed. In this scenario Forms Authentication prohibits access to the service resources and only after hitting a page and logging in will AJAX callbacks work.

• Windows Authentication
  Like Forms auth Windows security is also inherited from a page. So if you're logged in through a page, that page security can be passed to the AJAX callbacks that require those same rights. Again in that scenario you'd first need to log in on a page since AJAX callbacks generally do not pass security information.

  Windows Security is how IIS's challenge/response security is configured by default and so you can provide username and password to any client that supports Windows security (which most HTTP clients do). So direct access through HttpWebRequest can pass username and password to the server via the SecurityPrinciple.

• Manual Authentication
  Of course you can also set up your service to provide a code managed security model where you either pass a username/password as part of method calls or have a login method that generates a security token that is valid for the duration of a 'session'. This however is left up to your code implementation.