The IObjectContext interface provides two methods for basic programmatic security:
The key to understanding how MTS security works is to understand roles, as discussed in the following sections.
Roles from a Development Perspective
A role is a symbolic name that defines a logical group of users for a package of components. For example, an online banking application might define roles for Manager and Teller.
You can define authorization for each component and component interface by assigning roles. For example, in the online banking application, only the Manager may be authorized to perform bank transactions above a certain amount of money.
Roles are defined during application development. These roles are then assigned to specific users at deployment time.
Important Roles on a dual interface are not enforced when IDispatch (late-binding) is used.
Checking If a Caller Is in a Role
The IsCallerInRole method determines if a caller is assigned to a role. The caller is the direct caller, which is the identity of the process (base client or server process) calling into the current server process.
The following illustration shows an application used to order supplies for a business.
You can use roles to determine whether the base client has access to objects in the server process. In this scenario, the server process would check to see if the base client is allowed to place an order. Calling IsCallerInRole on the Order object context checks if the direct caller, which is in this case the base client, is in a given role. Such a role might be Purchaser, to restrict the placing of orders to employees within that role.
Security checks are made when a process boundary is crossed. If the Payment object accesses a database, the access rights to the database are derived from the identity of the server process, not the base client. The database would use its own proprietary authorization checking.
Server-process security does not use impersonation. IsCallerInRole has the same semantics regardless of how many calls have taken place within the server process. The identity of the direct caller is always used to make the check. For more information on impersonation, see Advanced Security Methods.
Security for In-Process Components
Because the level of trust is process-wide, running MTS components in-process is not recommended for secure applications. Access checks are not made on calls between components in the same server process. Configuring MTS components to run in-process with the base client gives the base client access to all components within that server process.
The IsSecurityEnabled method determines if security checking is enabled. This method returns FALSE when running in-process. IsSecurityEnabled can be a useful check to make before using IsCallerInRole. IsCallerInRole will always return TRUE when called on an object that is running in-process, which may have unintended effects.
When an MTS component is part of a Library package (in-process), it effectively becomes part of the hosting Server package that creates it. If you create Library packages with components that call IsCallerInRole, you should instruct installers of your Library packages to define the Library package's roles on the hosting Server package. Otherwise, IsCallerInRole will always fail.
IsCallerInRole, IsSecurityEnabled, Secured Components