Security

If you create a VB component today, your choices for implementing security are somewhat limited. You can use NTFS to set permissions on the file itself. You can place the component in MTS/COM+ Component Services and turn on role-based security. You can call it over DCOM and use DCOMCNFG to set permissions. You can always just code your own security.

One of the runtime's main benefits is that an entire security infrastructure is built right in. In fact, two major security models are set up in the .NET Framework: code access security and role-based security. These are discussed in more detail in Chapter 12, “Performance and Security.”

Code Access Security (CAS)

This security does not control who can access the code; rather, it controls what the code itself can access. This is important because it allows you to build components that can be trusted to varying degrees. If you build a VB component today and want to perform database access, you are free to call ADO and connect to a database (provided, of course, that you have a valid user ID and password). With .NET, however, you can actually specify, with the tools in the .NET Framework, what actions your component can and, more importantly, cannot perform. This has the benefit of preventing others from using the code in ways that you did not intend.

Perhaps the main benefit of CAS is that you can now trust code that is downloaded from the Internet. Security can be set up so that it becomes impossible for the code to perform any mischievous actions. This would prevent most of the macro viruses that are spread via e-mail today.

Role-Based Security

Role-based security is the same type of security you get when you use MTS or COM+ Component Services. In .NET, the Framework determines the caller, called a principal, and checks the principal's individual and group permissions. Unlike COM/COM+ role-based security, however, .NET cannot make an assumption that the user will have a valid NT user account and token to pass in. Therefore, .NET allows for generic and custom principals, as well as standard Windows principals. You can define new roles for each application if you want.