Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A guerrilla course on COM(+) security

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.


advertisement


Introduction



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 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 and Identity.

  • 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

  • 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 use dcomcnfg.exe to manage these settings (see figure below). These options can be set programmatically via COM API calls such CoInitializeSecurity and friends.



Comment and Contribute

 

 

 

 

 


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

 

 

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