Most developers hate to deal with security
issues; that's why the security-design subject is, most of the time, left out from the "typical developer" MSDN surfing and the application prototypes you show your boss.
From time to time, unfortunately, your prototype must turn into a real-world application to be
used into a production environment (pretty disturbing, isn't it? :) ).
This is the moment you find out that you are not that confident with Access permissions and IIS authentication settings as you are with COM marshaling and Interface design.
Well, at least this is what happened to me; now I feel a bit more confident with security design issues,
so I want to share my experience with you.
I wrote this article to provide a sort of "security for dummies" manual. I know that each paragraph could be expanded into a separate
article, but I want to provide here the "big picture" that can help you not to get lost among the plenty of info you can find on MSDN, Technet, etc. Depending on the feedback I get, I'll possibly write follows-up to get into details on some areas I cover briefly in this article.
Operating System Security Service Providers
COM security in W2K and WNT4 is built on top of the operating system security. The OS security on the NT and W2K platform is provided by Security Support Providers (SSP). Security Service Providers must expose a set of documented
interfaces. Since they are documented, "anyone" could implement a SSP as a pluggable module into the OS; in practice, this task is so difficult that the only SSPs available on the Windows platform are the ones provided by Microsoft. In WNT4 the only SSP available is NTLMSSP. In W2K a new SSP (named Kerberos) is available; Kerberos is a sophisticated, industry standard, security protocol. It provides enhanced scalability and features if compared to NTLMSSP.
According to some rumors I heard, W2K was released later than scheduled basically for difficulties on the implementation of this protocol.
Here are a few benefits of Kerberos vs. NTLMSSP:
Kerberos offers a two-way authentication mechanism while NTLMSSP can only provide authentication of the client to the server,
but it doesn't provide a way to assure the client about the server
Kerberos issues security tickets with
about 10 hours validity, while, with NTLMSSP, the security authority (PDC) must be contacted for each operation that must be
Kerberos provides delegation (more on it later), while NTLMSSP does not.
COM security basis
COM security is based on 4 main concepts: Authentication, Impersonation, Activation/Launch and
Authentication: Determines if and when the caller identity must be verified and the security applied to data packet transmission (encryption, packet signature check, etc). Note that the "None" option, although listed, is not available; in other words, the client must always provide its identity to the server.
Impersonation: Determines to what extent the server can use the client identity to perform some operations on its behalf. Available options are:
Anonymous (not supported): The server doesn't know the client identity
Identity: The server knows the identity of the client and it can perform access checks using client credentials, but it
cannot access system objects as the client
Impersonate: The server can impersonate the client, but only on the server machine
Delegate: (not supported in WNT4, supported in W2K) The server can impersonate the client, even when doing outgoing calls to other servers
Most of such options can be set in a declarative way (they are stored in the registry under the HKEY_LOCAL_MACHINE/AppID section), you use
dcomcnfg.exe to manage these settings (see
figure below). These options can be set programmatically via COM API calls such CoInitializeSecurity and