Last month, I wrote about securing Web applications by running them in the authenticated user context. In Windows DNA architecture, trusting a Web server for delegation ensures that a Kerberos ticket is properly handed from Active Directory (AD) on the domain controller (DC) to the IIS 5.0 Web server to the client and back. You achieve the same result in Microsoft .NET Server architecture by setting identity impersonate="true" in config.web on the IIS server.
I also discussed perceived security implications in these architecture models, and I asked how we can develop security outside the firewall without using VPN, public key infrastructure (PKI), Secure Sockets Layer (SSL), or some combination thereof because Simple Object Access Protocol (SOAP) currently has no security specification.
Reader Patrick Nolan of StormRanger Computer Security, a Microsoft Security Services Partner Program Specialist, emailed me immediately after the issue mailed. Pat is very well versed in layered service providers (LSPs), base service providers, and security service providers (SSPs). He also knows plenty about network device interface specification (NDIS) 5.0, Microsoft's protocol stacks (including the new .NET stack and its request/response layer), and Windows Sockets.
Pat said, "I feel that LSPs are flexible enough to address the issue of secure authentication outside the firewall through some sort of programming injected by using a custom LSP"—that is, an installed protocol stack. Layered protocols, for example SSL, can't stand alone; they rely on a base protocol such as UDP, TCP, or SPX. Layered protocols operate only through the service provider interface.
LSPs are slick pieces of code integrated in Windows Sockets 2.0. They provide the flexibility to accomplish demanding tasks such as encryption. Before Windows Sockets 2.0, we had to create a completely new DLL. Because Windows Sockets 2.0 is extensible, we now can seamlessly add component-like code without recompiling the DLL.
You can insert the optional LSP layer between the Windows Sockets 2.0 DLL and the underlying protocol stack. You can also add LSPs to extend the underlying protocol stack, thus adding services such as authentication or proxy server services. A few software vendors (e.g., Atelier) now provide LSPs for authentication and integrity.
You can also use LSPs to secure a Web application outside of the firewall—if you aren't faint of heart. Doing so involves systems-level programming at the network layer, and it's C++ only. For a thorough discussion of LSPs, see the Host Integrity and Auditing white paper at http://home.nycap.rr.com/practical.
Until next month, keep looking into these new (and sometimes challenging) technologies. Feel free to email me at [email protected] about issues you'd like to read about in this column or post your suggestions as a Reader Comment.
