More COM+ security mysteries

Continuing with the quest for the workings of COM+ and security from this posting, I now stumbled on something else.

Consider this scenario: you have a web-based IIS-hosted front-end to your distributed application. The middle tier is hosted on a different server and holds a COM+ server application. Security is enabled on the COM+ app and set to check both application and component access.

[assembly: ApplicationName(“Middle Tier COM+ Application”)]
[assembly: ApplicationActivation(ActivationOption.Server)]
[assembly: ApplicationID(“35E4F39E-4C97-43b6-ABF0-6CBC5D4D9965”)]
[assembly: ApplicationAccessControl(
true, AccessChecksLevel = 
[assembly: Guid(“35E4F39E-4C97-43b6-ABF0-6CBC5D4D9966”)]

OrderProcessing: ServicedComponent, IOrderProcessing
  publicvoid PlaceOrder(int customerID, int productID, int
    // Implementation not shown

When you try to access this component from the web tier, you will not be able to do so. This is completely understandable:
When COM+ creates a remote component the RemoteServiceProxy will use a RCW to call the COM+ component on the middle tier where a CCW will perform the actual method call. This way the DCOM infrastructure can bridge the network gap and perform the necessary security checks.

The web process aspnet_wp.exe runs under the credentials of the ASPNET user if you are not using impersonation (it is not enabled by default). ASPNET does not have network rights and can therefore not access the remote COM+ component. In case you are wondering: yes, the ASPNET user has been added to one of the roles Clerk or Manager.

Now here’s the funny thing. Change the activation type of the COM+ application to Library and the assembly for the COM+ app will be loaded in-process with aspnet_wp.exe. In this scenario, no DCOM should be necessary, nor involved in any method calls. Yet, the problems remain. Spelunking around on the Internet, googling here and there, there’s not much mentioning of this problem. I have to admit that not using impersonation is a bit weird. Who would turn on security to do role based security checks when all calls are made by the ASPNET user?

The solution to the problem is indeed to turn on impersonation in your web.config file

  <identity impersonate=”true” />

where the authenticated user will be impersonated on the executing thread. You can see which user this is by calling System.Security.Principal.WindowsIdentity.GetCurrent(). HttpContext.Current.User.Identity will give you the authenticated user. When anonymous access is turned on for your web application, you are not authenticated and the authenticated user identity is empty. The servicing thread will run under IUSR_machinename.

What I cannot figure out is why the ASPNET user doesn’t have sufficient rights to instantiate a component in a COM+ library application. I have checked with FileMon and RegMon if files or registry keys are being accessed to which it has no rights. Nope. Maybe no Launch or Access permissions on a DCOM application? There’s no DCOM application defined for a COM+ application. Check for yourself using dcomcnfg.exe (Component Services in Windows XP or Server 2003).

I wonder if any of you have an idea as what might be the case here. Feel free to enter suggestions, guesses and so forth into the comments section.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s