ATL Server Security
Your ATL Server code usually runs in the security context of the client making the current request. This context is supplied by the IIS HSE_REQ_GET_IMPERSONATION_TOKEN server support function, which is wrapped by IHttpServerContext::GetImpersonationToken. The impersonation of the client is handled very early during the processing of a response (in CIsapiExtension::DispatchStencilCall) and remains in force unless you explicitly choose to impersonate another user.
This means that if the client has been authenticated, your code will run in the context of the authenticated user. If the client has not been authenticated, your code will run in the context of the anonymous user account specified for the Web site or virtual directory holding the currently requested resource. By default, the anonymous user account is the Internet Guest Account, IUSR_MachineName, but you can change this (using Internet Services Manager, for example).
By default, clients accessing your Web server will not be authenticated because anonymous access is automatically enabled for newly created virtual directories. However, you can force authentication for a particular Web site or virtual directory by disabling anonymous access (using Internet Services Manager, for example).
Even if you do not disable anonymous access, you can use administration tools or code to ask clients to authenticate themselves. You can require authentication for a particular server response file by setting its access control list so that it does not allow access to the anonymous user account. Alternately, you can request authentication more selectively by returning a 401 (Unauthorized) HTTP status code from your request handler. You can use the HTTP_UNAUTHORIZED constant for this.
If you need to change the security context in which your code executes for some reason, you can call a function such as SetThreadToken, execute your code, and then revert to the client's user account by calling AtlImpersonateClient.
You can determine whether the client has been authenticated by checking the "LOGON_USER" server variable. If the variable contains a value, the client was authenticated; otherwise, the client is accessing the resource anonymously.
You should be extremely careful to check the return values of security functions and ensure that the client's default security context has been successfully applied before executing any further code. Use destructors to ensure that your code is safe in the face of exceptions.
See the ShowUser section of the WebFeatures Sample.