This section explains how roles are useful in building secured components. It also discusses how deployment configuration determines security boundaries.
A role is a symbolic name that defines a group of users for a package of components. Roles extend Windows NT security to allow a developer to build secured components in a distributed application. In this scenario, the Manager role is defined at development time, but not yet bound to specific users. For each deployment of the application, the administrator can then assign the users and groups to a role in order to customize the application for his or her business.
In this scenario, role checking is done by the MoveMoney and Account objects. When both MoveMoney and Account objects are used, the second check (on the Account object) is redundant. However, it yields the same result, because IsCallerInRole applies to the direct caller, and both the MoveMoney and Account objects run in the same server process.
If you place the MoveMoney and Account components into separate packages, the components run in separate server processes. In this scenario, calling IsCallerInRole on the Account object context would check if the MoveMoney object's associated server process is running in the Manager role. MoveMoney is now the direct caller because a process boundary has been crossed.
The Account object runs under a package identity that gives that process full access to the bank account database. Account objects have the authority to update any account for any amount. Roles provide a means of permitting and denying access to objects. Once this permission is granted, the client, in effect, has the same access rights as the server process.
When you configured the package, you chose a package identity of Interactive User. In a real-world scenario, packages are more likely to run as a specific user, such as SampleBank, which has access rights to the database.
Returning to the scenario where you split the MoveMoney and Account components into separate packages, running as the SampleBank user solves the role checking problem. Adding the SampleBank user to the Manager role would allow the second IsCallerInRole check (on the Account object) to always succeed.
Transaction Server security is enabled only within a server process. Because the MoveMoney component is configured to run within a server process, role checking is enabled.
If you configure the Sample Bank components to run in-process, role checking would be disabled. In this case, IsCallerInRole always returns TRUE, which means the direct caller would always pass the authorization check.
You could use the IsSecurityEnabled method to check if Transaction Server security can be used. IsSecurityEnabled returns FALSE when the object runs in-process. Using IsSecurityEnabled, you could rewrite the role-checking code to disable transactions when objects aren't running in a secured environment.
In-process components share the same level of trust as the base client. Because of this, it isn't recommended that you deploy your secured components to be loaded in-process with their clients.
Programmatic Security, Enabling MTS Package Security, IsCallerInRole method, IsSecurityEnabled method