Browse DevX
Sign up for e-mail newsletters from DevX


A guerrilla course on COM(+) security  : Page 2

Most developers hate to deal with security issues; that's why the security-design subject is, most of the time, left out from the application prototypes you show your boss. This article provides a sort of "security for dummies" manual, and provides a "big picture" that can help you not to get lost among the plenty of info you can find on MSDN, Technet, etc. It covers Windows Security Provides, limits of COM security under NT, and COM+ cloaking.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

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 to a 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 as well.

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 with WNT4 (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 additional steps:

  • 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 checks are 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). To summarize: 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).



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"



Enrico Sabbadin is a software developer (MCP) that works, since 1995, on distributed and Internet based applications design on the Microsoft platform. He is an author for several Italian programming magazines and for the ASPToday web site, and occasionally speaks at Microsoft MSDN conferences in Italy. Enrico maintains at his own site a MTS FAQ (http://www.sabbasoft.com).
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date