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
 

COM(+) Security: Follow-up

In the second part of his article on COM+ security, Enrico explores the best practices in DNA security, roles, and identity, and goes deeper into the differences between the security in intra-application and cross-application calls.


advertisement


Introduction



In my previous article [1], published at VB2TheMax site, I've described briefly how COM+ security and role-based security work. I promised you to discuss in the next article about web/IIS security; still I realized, briefly later the article was published, that some more info about role-based security and some general security design guide lines were required: these are actually the subjects of this article.

Addendum

I think there is a couple of details about COM security settings that should have deserved more attention in the previous article. 

Authentication: Both client and server declare (in a programmatic or a declarative way)  their Authorization level preferences. The DCOM run-time set up the communication choosing the highest level between the two settings.

Identity: Since this setting appears as an option in the DCOMCNFG.EXE tool, I was mislead for a while about its real meaning. VB programmers tend to think of security settings as a server side problem only (I'm afraid to say that I've met some VB programmers that didn't even know that something like COM security existed). The reason for this lies on the fact that COM API functions like CoInitializeSecurity are not really VB friendly and DCOMCNFG.EXE is of no use to set up security settings on a standard exe application (the procedure to do this requires to insert some registry keys in the registry manually).
This is why, at the beginning, I thought that the identity setting went through the same negotiation process of the authentication setting (hence the identity setting appearing in DCOMCNFG.EXE being the server side preference on this setting). This is not the case, unlike the authentication setting, this setting is determined entirely by the client (the identity option on a COM server in DCOMCNFG.EXE appears since a COM server may act as a client when calling into other COM server). This is a reasonable behavior: it's actually up to the client decide "if and how" the server can perform "security sensitive" operations using the client identity token.

DNA Security: Best Practices

As I said, there is quite a lot of work involved setting up delegation correctly; nevertheless, when all user permissions and COM settings are set up properly, you still have only half of your work done; you need to request delegation programmatically in your method implementation: spawn a new thread (or pick it up from a thread pool) and ask the thread to impersonate the caller.
This is not easy feasible (and in any case unsupported) in VB (and there is no way to ask to the MTS/COM+ surrogate process to do this for you), but you shouldn't actually be worried at all since using delegation is considered a bad design practice when implementing security in business objects. I know that the use of impersonation and delegation sounds tempting, but most times it provides you more problems than benefits, exposing your application more easily to security holes and making them harder to maintain.
Impersonation and delegation fit only into some specific and low-level development scenarios such as file servers or some NT services like IIS.
Think about it: delegation basically means "I don't care about security, I delegate security checks to someone else". You are moving security checks away from your business objects entry point, down to the next inner level of your application (file access and DB access permissions), demanding security set up to system or DB administrators.
The recommended approach is exactly the opposite: 

  • Perform all access checks at the point at which client requests enter the middle tier
  • Use only role-based security and avoid lower level security API 

As Ted Pattison says in his book "Programming Distributed Applications with COM+ and MS Visual Basic 6.0", "Most companies who've successfully deployed distributed applications on large scale have found that this is the only sane approach."


The advantages implied are: 

  • You can set permissions using business rule semantic (you cannot withdraw more then 100$ since you are not in the manager role)
  • Applications are easy to set up and maintain 
  • Applications are more scalable since you can use DB connection pooling only if you do not delegate to the DB security access checks.

Deep into Role-Based Security

There is still a couple of details about role-based security you have to be aware when designing your multi-tier application properly.
Both of these two details fit naturally into a security architecture where you follow the DNA recommendations mentioned before.

  • Access checks within COM+ applications:
    Once a call into a COM object has passed role-based security using the caller identity, any file or database access (via the NT integrated security) that you require during a method execution is checked against the process identity, not the caller identity. 
  • Nested calls from COM+ application to COM+ application:
    Role-based access check is done against the process identity of the direct caller, not against the base client identity (original caller) that initiated the call chain.
    Example: Suppose a base client running under user A calls into a configured COM component named object 1, deployed in a COM+ application X. Application X runs under user B identity. During the method call execution, object 1 calls into object 2 deployed in application Y. Role-based access check in Application Y is done against user B, not against the original caller A.

Although not relevant to role-based security mechanism, MTS/COM+ maintains the identity chain while the logical thread of execution (activity) flows from one COM+ application to another. MTS users were limited in identity flow discovery, having available only a few methods like GetDirectCaller and GetOriginalCaller. In COM+ a new interface named SecurityCallers  has been introduced. Using this interface you can enumerate the whole set of identities that have been involved in the activity. Remember that  such info are made available for tracking and logging purposes only, not to set up some kind of custom security checks.

Conclusions

I hope I have provided valuable information to set up your distributed application security effectively as long as you are concerned with standard win32 clients.
As you know, you can call into a COM object from an ASP page, that is, basically, from an HTTP request. This poses a whole new bunch of security issues related to the fact that, in most cases, the identity calling into a web server via a browser request is not known inside the domain, hence it cannot be authenticated. IIS must act then  as the base client when calling into the domain where middle-tier COM objects reside, still providing you someway to distinguish among different internet users identity. What kind of security could you set up if all internet calls were seen as coming from the System account ? (the inetinfo.exe process runs under this account).

You will see in my next article how IIS behaves differently than a standard base-client, using impersonation and delegation to provide you different ways to map internet users to domain identities.

Errata

There is a couple of errata in my previous article about COM+ security (it's likely they have been fixed by the time you read this article): 

  • SSP stands for Security Support Provider, not Security Service Provider. 
  • Required user rights to set up Delegation: 
    The client account must have the "Account is Sensitive And Cannot Be Delegated" disabled.
    The server process identity must have the "trusted For Delegation" property enabled.

[1] A guerrilla course on COM(+) security : Enrico Sabbadin  

 

 



   
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.

 

 

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