Role-Based Security

Hi friends,
Know about security
Role-based security is not new to the .NET Framework. If you already have
experience with developing COM+ components, you surely have come across
role-based security.The concept of role based security for COM+ applications is
the same as for the .NET Framework.The difference lies in the way in which it
is implemented. If we talk about role based security, the same example comes up,
over and over again.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 this amount.
Therefore, as you can see, role-based security has to do with limiting the tasks
a user can perform, based on the role(s) he plays or the identity he has.Within
the .NET Framework, this all comes down to the principal that holds the identity
and role(s) of the caller. Every thread is provided with a principal object. In order to have the .NET Framework handle the role-based security in the same manner as it does code access security, the permission class PrincipalPermission is defined.To avoid any confusion, PrincipalPermission is not a derived class of CodeAccessPermission. In fact, PrincipalPermission holds only three attributes: User, Role, and the Boolean IsAuthenticated.