Security Is for Servers

When planning your security implementation, always design using the client/server model! In other words, do not use the security API just anywhere in your Win32 applications; these functions belong only in software that will be run on a server.

Split the project into a client application, which individual users will use, and a server application, which runs on a server and handles all incoming requests for secured objects. Why insist on this extra work? There are several reasons:

The software running on the client side might end up being run under Windows 98 or another operating system that doesn’t support security, such as a Web browser.
This provides a clear division between a server application, which handles all security and therefore “clears” all your secured-object requests, and the client application, which makes use of the objects. The client/server model centralizes the security issues on one machine, rather than several or many, leaving that many fewer potential security loopholes.
Separating the client and server functions provides you with much greater flexibility down the road, in terms of adding new types of client applications or extending the size of your LAN. You eliminate the need to change your server implementation, which would thereby reopen a can of security worms.

WARNING

Always use the client/server model when designing systems that need Windows NT’s security services. The security checking should always (and only!) be performed by an application functioning on a server or in a server capacity. A client application, running on the user’s system, should use any of the standard network communications means to request access to the secured objects from the server application. This technique allows you to combine secure access with the ability to access the objects via workstations that do not internally support NT security—for example, from Windows 98, a Java applet running in a Web browser, or a Unix or Macintosh machine.

So how is the client application supposed to communicate with the server application? There is more than one right answer to this; however, the method you choose must be a secure one. Typically, any of the following means of communicating between client and server applications can be used:

Named pipes
Remote procedure calls
Distributed COM (DCOM)
Secure sockets (and supporting Web server)

These are not the only means you could use, of course. However, in most cases, any one or a combination of those listed here are excellent choices.