COM+ (Enterprise Services) security

While I programmed quite some VB6 COM+ components, I didn’t have the chance yet to do too much of COM+ programming in .NET. I did write an article on it once (included below), but haven’t put it all into practice.

Today I did a demo on Role Based Security in COM+ using .NET Enterprise Services. I was quite surprised to see that my demo did not work. I had marked the two methods of an interfaces with the SecureMethod attribute like so:

Imports System.EnterpriseServices
Imports System

<Assembly: ApplicationName(“COM+ Demo”)>
<
Assembly: ApplicationActivation(ActivationOption.Server)>
<
Assembly: ApplicationAccessControl(True, _
  AccessChecksLevel:=AccessChecksLevelOption.ApplicationComponent, _
  Authentication:=AuthenticationOption.Default)>

PublicInterface IMethods
  Function Method1() As
Guid
  Function Method2() As
Guid
EndInterface

<JUSTINTIMEACTIVATION(

<JUSTINTIMEACTIVATION(True), ComponentAccessControl(True)> _
PublicClass
Klant
  Inherits
ServicedComponent
  Implements
IMethods

  <AUTOCOMPLETE(True), SecurityRole(“Programmeurs”, _
    SetEveryOneAccess:=
True
), SecureMethod()> _
  PublicFunction Method1() As Guid Implements
IMethods.Method1
    Return ContextUtil.ApplicationId
  EndFunction

  <AUTOCOMPLETE(True), SecureMethod(), SecurityRole(“Managers”)> _
  PublicFunction Method2() As Guid Implements IMethods.Method2
    Return ContextUtil.ContextId
  EndFunction

EndClass

At first I called the code like so:

Dim k As Klant = New Klant
MessageBox.Show(k.Method1().ToString())
MessageBox.Show(k.Method2().ToString())

expecting this to work (notice the SetEveryoneAccess named argument), while the second call to k.Method2 should fail. Well, this first one failed as well: UnauthorizedAccessException. After a sudden coffee break (“Boys, I think it’s time for some coffee. At least for me: I need it.”), it suddenly came to me: you should call a secure method through an interface reference.

Dim k As IMethods = New Klant
MessageBox.Show(k.Method1().ToString())
MessageBox.Show(k.Method2().ToString())

Quickly changed it to the above, and … it still didn’t work. Man, I would have put some money on that. Luckily nobody was interested in a bet. And I suddenly noticed the code crashed on the first line, not the second. 

As it turns out, it is something new for Enterprise Services. As soon as you use a SecureMethod, a new role called Marshaler is added during registration by the RegistrationHelper. Every user that will call a method or access an interface needs to be added to this role. That was another new one for me. The rabbit hole goes even deeper. It seems that the Marshaler role is also needed for a couple of extra interfaces that ES will add to your class. Read all about it in chapter 12 of Building Secure ASP.NET Applications. From that chapter:

Note   The Enterprise Services infrastructure uses a number of system-level interfaces that are exposed by all serviced components. These include IManagedObject, IDisposable, and IServiceComponentInfo. If access checks are enabled at the interface or method levels, the Enterprise Services infrastructure is denied access to these interfaces.

As a result, Enterprise Services creates a special role called Marshaler and associates the role with these interfaces. At deployment time, application administrators need to add all users to the Marshaler role who needs to access any methods or interface of the class.

 

Enterprise Services in Visual Basic.NET.doc (111 KB)

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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