Role-based security is not new to the .NET Framework. If you already have experience developing COM+ components, you surely have come across role-based access security. The concept of role-based security for COM+ applications is the same as for the .NET Framework. The difference lies in the way security is implemented.

When we talk about role-based security, we repeatedly use the same example. This is not because we can t create our own example, but because it explains role-based security in a way everyone understands. So here it is: You build a financial application that can handle deposit transactions. The rule in most banks is that the teller is authorized to make transactions up to a certain amount let s say $5,000. If the transaction goes beyond that amount, the teller s manager has to step in to perform the transaction. However, because the manager is only authorized to do transactions up to $10,000, the branch manager has to be called to process a deposit transaction that is over that amount.

Therefore, using this analogy, role-based security has to do with limiting the tasks a user can perform, based on the role(s) that user plays or the user s identity. Within the .NET Framework, this all comes down to the principal that holds the identity and role(s) of the caller. As discussed earlier in this chapter, every thread is provided with a principal object. To have the .NET Framework handle the role-based security in the same manner as it does code access security, we...