Introduction

Most developers hate to deal with securityissues; 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 beused 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 separatearticle, 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 documentedinterfaces. 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 identity.

• 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 authenticated. 

• 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 andIdentity.

• 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: 

• Activation/Identity: Determines who can launch and access the server

• Identity: The identity under which the server process runs.

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 usedcomcnfg.exe to manage these settings (seefigure below). These options can be set programmatically via COM API calls such CoInitializeSecurity andfriends.

Role-Based Security

Role-based security is a higher-level security model, available in MTS server packages and COM+ applications, that maps easier to typical Business logic security requirements. Role based security is easier to configure than DCOM security: the surrogate process that hosts the configured components shelters you from most of the complicated details of the COM security API (CoInitializeSecurity and friends) calling them on your behalf.

A role identifies a logically related group of users that share the same permissions to access a defined subset of a COM application functionalities. Roles are, in a way, equivalent to NT groups that you use to configure the operating system and standard DCOM security, but, while NT groups have a domain scope, roles are specific toa MTS package and a COM+ application.

You configure declaratively the COM application security assigning roles to specific classes, interfaces and methods, according to the granularity access level control you need. You can also perform programmatic role-based access check at run-time, calling MTS/COM+ functions like IsCallerInRole and similar.

After the COM+ application has been deployed, it’s a NT Domain administrator’s task to put the proper domain users under each application-defined role, according to the domain policy organization.

Note: Role-based security was available for server packages only in MTS; on W2K library packages can provide role-based security aswell.

Limit ofs COM security under WNT4

The limits in the COM security model are due to some limits of the (only) SSPI available when it comes to establish a network authentication. 

NTLMSSP uses the NTLM authentication protocol that employs a so-called challenge-response protocol to authenticate clients. This protocol does not transmit the client password over the wire, thus the client identity cannot do a further hop to another server; in other words, the server can’t impersonate the client on a different machine but only on the server machine. This is the reason why delegation is not supported under WNT4.

Since cross-host calls of a server impersonating a client would fail, COM decides, in any case, even for local calls, to drop the thread identity token during an outgoing call and uses the process token during the identity check process. This seems to impose a huge limitation in Web application scenarios: any action your ASP script performs, like accessing files, is done using the identity of the client (but who’s actually the client depends on the IIS application security settings, more on it later).

When it comes to invoke COM objects from ASP scripts, COM security checks are performed against the web server process identity (not really nice). Later on this article we will see how MTS overcome this limitation via an ad-hoc mechanism that lets you exploit role-based security defined in your MTS package against the client identity.

COM+ Cloaking

Since the Kerberos SSPI provider doesn’t suffer the limitations of the NTLM challenge-response protocol, delegation is supported under Win2K, thus under COM+ as well. 

Nevertheless, setting the impersonation level to Delegate under W2K is not actually enough to have delegation working; for compatibility reasons withWNT4 (not to break existing COM applications) COM+ does not change the behavior of the delegate impersonation level.

To really enable true delegation under COM+ you must perform two additionalsteps:

• Turn on a new mechanism called cloaking. Cloaking is the way a client informs the COM+ run-time that the thread token shouldn’t be ignored. Cloaking can be enabled at process level via an opportune flag in the CoInitializeSecurity call or it can be set on a per proxy base via the flags EOAC_STATIC_CLOACKING or EOAC_DYNAMIC_CLOAKING. If you don’t pass either of these flags, COM+ will ignore the thread token as in the old days.
• The identity of the process that wants to perform delegation must have the “Trust for delegation” permission enabled. The delegated identity must have the “Account is sensitive” and “Cannot be delegated” disabled

MTS extension to the COM security model

MTS comes with a powerful feature; if the process runs under the MTS impersonator group (created when you install the Option Pack), role-based security is done against the thread token.How this feature works is undocumented, but it’s exactly what you wanted. Note that this is an out of band mechanism; COM security checksare still done against the process identity. COM and MTS disagree on the caller’s identity (download a powerful utility from Keith Brown site(http://www.developmentor.com/kbrown to see this at work on your web server). Tosummarize: role-based security works in the same manner under MTS and COM+. 

Important: use Server.CreateObject from your ASP page to create components registered under MTS; if CreateObject is used, the IIS application process identity will be used during role-based checks (another reason to avoid this mistake is that the transaction flow would be broken).

Conclusions

The next article will deal with Internet security issues (very different than the ones you meet in a LAN environment), how IIS supports Internet authentication protocols and how maps “Internet users” to domain users. If you want to go deep into these subjects I suggest the following articles (you can find them on line as well at http://msdn.microsoft.com/msdnmag/)

[1] MSJ, November 1999: Guy Eddon, “The COM+ Security Model Gets You out of the Security Programming Business” 
[2] MSJ, November 1999: Keith Brown, “Security Briefs”
[3] MSDN, June 2000: Keith Brown, “Web Security part 1” 
[4] MSDN, July 2000: Keith Brown, “Web Security part 2”