Client Impersonation

The procedure whereby a server application checks that a connected client actually has access rights to a requested object is called client impersonation. In this process, when the client application makes an object request of the server application, it passes along its access token. The server application uses this access token to log on as the client (impersonate the client), attempting to access the desired object in the same manner that the client is asking for it.

NOTE

It is true that the server application could instead look up the security information for the client, and then get the security information for the asked-for object, and see whether the client has the desired permissions that way. However, impersonation is the simpler and more foolproof method of doing this.

Here are the steps a server application might typically make to use client impersonation in implementing server-side security:

1. The client application establishes a connection with the server application.
   
   
2. The client application asks the server application for access to a particular object.
   
   
3. The server application uses ImpersonateLoggedOnUser to obtain an impersonated access token, which it then uses to attempt access in the same manner as the client application.
   
   
4. The server application reverts to its own access level, by making a call to RevertToSelf, so that it can be available to handle other clients’ requests.
   
   
5. If the server application’s access attempt succeeded, it passes back to the client either an actual handle to the requested object or to some other prearranged proxy token by which the client application can refer to the requested object in future requests to the server application.
   
   
6. Each time the client application wants access (again) to a secured object, the server application should call ImpersonateLoggedOnUser again before accessing the object to ensure that the client’s access rights haven’t changed during the interim. When the request is handled, the server application again calls RevertToSelf.
   
   
7. When the client disconnects from the server, the server application can delete the impersonated access token.

For private objects, the server and client must establish some consistent means of referring to desired objects. This could be done by using either a handle or token type, which the server assigns and keeps track of. Alternatively, it may be a string or whatever other protocol the server and client applications implement to refer to server-application managed objects.

For private objects whose security is being handled by the server application (as opposed to some other server application running on the same or another machine), it is still important to use ImpersonateLoggedOnUser, since in the course of handling the client’s request, the server may need to open or access objects for which Windows NT does have some level of built-in security assigned. By using impersonation through the entire request-handling section, the server application ensures that it won’t inadvertently do something on the client’s behalf that is explicitly restricted from that user.

Individual server threads (or processes) can each have a different impersonation access token assigned. This is necessary for permitting simultaneous services to multiple clients.

© 1998 SYBEX Inc. All rights reserved.