Security Boundaries
COM+ makes a sensible assumption: two components from the same application trust each other, and intra-application security is not necessary. As a result, security is checked only at application boundaries. When two applications interact, a security check exists between them. For example, in the case of a library application that was loaded into a server application, there is an application boundary, and thus a security boundary, between them. When a client accesses the library application in the hosting process, COM+ verifies that the client has access to the library application component. When a client from the library application calls a component in the hosting process, COM+ uses the hosting application’s role-based security. The same is true when two library applications interact with each other while both share the same hosting process. You can draw a design conclusion from this behavior: if you have two components and you want security checks done when one calls the other, put them each in separate COM+ applications.
As you have seen, each COM+ method invocation has a call context object associated with it. COM+ will not update the security call context when no security boundary is crossed. If one component has done programmatic role-based security and is about to call another component in the same application, repeating the role membership verification is redundant, as no new security context information will be present.
Get COM & .NET Component Services now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
