Interop & role-based security

I've written a serviced component in C# that interacts with some COM
components (in a separate process). All components are run on the
same machine (currently under the Administrator account). I've
enabled role-based security on the serviced component (at the
component level) through attributes in C#. This component implements
the standard IConnectionPointContainer interface. It looks like this:

In assembly.cs:

[assembly: ApplicationActivation(ActivationOption.Server)]
[assembly: ApplicationAccessControl(Value = true,
Authentication = AuthenticationOption.Integrity,
ImpersonationLevel = ImpersonationLevelOption.Identify,
AccessChecksLevel =
AccessChecksLevelOption.ApplicationComponent)]
[assembly: SecurityRole("MyRole")]


In the class's .cs file:

using System.Runtime.InteropServices;
using System.Runtime.InteropServices.ComTypes;
using System.EnterpriseServices;

[ComVisible(true)]
[ComponentAccessControl(true)]
[Guid("XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX")]
[ProgId("MyComponent.MyObject.1")]
public class MyObject: ServicedComponent, /* Other interfaces... */,
IConnectionPointContainer
{
[SecurityRole("MyRole")]
void IConnectionPointContainer.EnumConnectionPoints(out
IEnumConnectionPoints ppEnum)
{
// Implementation
}

[SecurityRole("MyRole")]
void IConnectionPointContainer.FindConnectionPoint(ref Guid riid, out
IConnectionPoint ppCP)
{
// Implementation
}

// Other interface implementations...
}

I can CoCreate my component using this IID, and call
IConnectionPointContainer's methods on it. However, if I have role-
based security enabled, the calls always fail with E_ACCESSDENIED.
The client code is run under a user account that is included within
"MyRole". In fact, the same client code can call other methods on
this component that are restricted to "MyRole".

If I remove the role restrictions from these specific methods (by
commenting out the SecurityRole attribute), it still does not work.
If I turn off role-based security on this component (by commenting out
the ComponentAccessControl attribute), it *does* work. So it seems
there is something odd going on with the IConnectionPointContainer
interface and role-based security.

One thing I am seeing is that IConnectionPointContainer does not
appear in the list of interfaces in the COM+ application GUI (in
Component Services) -- even though I am explicitly implementing the
interface and can CoCreate using that interface. I suspect this is
somehow related to my problem; maybe this interface is somehow being
treated "special" by the interop layer (I know that connection point
implementations are converted to .NET events, so I am guessing
something similar might happen with IConnectionPointContainers).

Any ideas on what is going on here, or how I can fix it? I really
don't care if the interface appears in the COM+ application as long as
I can use it with the object. But the security problem is a real
issue for me. How can I get these methods to work properly with role-
based security?

Thanks,

Carl

.

Relevant Pages

  • Serviced Components & Role-Based Security
    ... I've written a serviced component in C# that interacts with some COM ... IConnectionPointContainer interface. ... based security enabled, the calls always fail with E_ACCESSDENIED. ...
    (microsoft.public.dotnet.framework.component_services)
  • Re: FindConnectionPoints returns invalid access to memory location
    ... The IOPC common interface and implementation is working fine. ... helpstring("CoOPCServer Local Server TypeLib")] ... STDMETHODIMP CoOPCServer::FindConnectionPoint(REFIID riid, ... class CoOPCServer: public IOPCCommon, public IConnectionPointContainer ...
    (microsoft.public.win32.programmer.ole)
  • Re: Interface function and TPersistent
    ... that all these different applications are running - they will still be ... controlling such things as login and security. ... actually open a form of the required class and what they can do within it ... create an interface for each and every one and pass this through and have ...
    (alt.comp.lang.borland-delphi)
  • Re: remote control program
    ... The security of the interface has nothing to do with SSL. ... the security of your online banking technology also has nothing to do with SSL. ... If the technology was not properly assessed by a qualified security team then I wouldn't trust it. ... for remote work to the same location who complains about jitter and delay ...
    (Security-Basics)
  • Re: RMA Datashare Poll
    ... and speed is mediocre but it's nearly a universal protocol ... > and there's a client for every OS in existence. ... > 2) Web based interface - A cgi style upload/download interface with ... and can be run through https for heightened security. ...
    (rec.martial-arts)