16.3. Defining Security with the .NET Framework
The .NET Framework has several procedures and namespaces to help you build secure applications. The term managed applications is used to refer to applications written to run within the common language runtime (CLR ), the engine used to process and run all .NET assemblies. Assemblies are the core of all .NET Framework applications, be they a Web application or a Windows-based application. An assembly is actually a collection of types and resources that are compiled and built to work together to form a complete application. Assemblies provide the CLR with the information needed during the runtime of your application.
16.3.1. Defining Assemblies
Defining .NET assemblies is basically just coding. When you create types, enums, properties, and so on, you are defining the .NET assembly. A .NET assembly can be a single code class or can be spread out over multiple code classes and then compiled into a new language called Microsoft Intermediate Language (MSIL ). The CLR uses this as its base for figuring handle versioning, deployment, reuse, security, and scoping.
The advantage of using MSIL is that when an assembly is loaded the MSIL is interpreted and run by the CLR for the platform on which it is residing. The advantage of this is that CLR can handle file validation, code verification, integrity checking, and code security.
16.3.2. Assemblies in Web Services
A Web service is basically an assembly with an .asmx file (ASP.NET Web page) that is loaded into an IIS instance. When you call a Web service, you're basically asking the ASP.NET runtime to grab the assembly and process the instructions there using the CLR. A Web service file, an .asmx, contains a directive that tells the CLR where the Web service can be found. This directive is used by ASP.NET to bind the Web service to the .dll that contains the actual code to be run. Think of using a pointer; you call the .asmx file (the Web service), which tells your application to use a particular .dll (library file) and where to find it.
Creating Web services and how to use them with InfoPath is discussed in Chapter 15, "Creating and Working with Web Services."
16.3.3. User versus Code Security
The .NET Framework holds two types of security models. The first is Code Access Security (CAS ), which is used to figure out if the code has the right permissions and to verify the origin of the assembly. The second is a group of role-based permissions. This model is based on having users make a request, and then figuring out if they have the right permissions to access the requested assembly or resources.
16.3.4. Code-Based Security
Coding your security levels is a very common practice. This allows the developer to grant access to certain resources without having to worry about what machine the assembly is running on. CAS isn't concerned with the user because the code has sent the request and has passed the correct credentials.
16.3.5. Role-Based Security
Role-based security is exactly what the name implies. You define particular groups, each of which has its own security policies; your application is then coded to join one of those groups. For example, when you use Windows authentication in your application, the CLR pushes security onto Active Directory or even SQL Server to handle. There are three types of Authentication objects available for your use:
Windows: Windows authentication verifies credentials using the Security Accounts Manager (SAM ) or Active Directory. Windows or Domain groups are used for these types of roles.
Forms: Forms authentication requires you to add code to verify credentials and retrieve the role from some sort of security store, usually held in a database table.
Passport: Passport authentication relies on the Microsoft Passport SDK to authenticate the user against the .NET passport role, equivalent to MSN/Windows Messenger.
16.3.6. System.Security Namespace
The System.Security namespace is the base assembly that handles all security for the CLR. One thing to remember is that the CLR enforces security on the location where the code is run from rather than on the location where the user logged in. There are many classes that can be used in the System.Security namespace. You can see the classes that apply to InfoPath in the following table:
| Class | Description |
|---|---|
| AllowPartiallyTrustedCallersAttribute | Allows signed assemblies to be called by InfoPath. |
| CodeAccessPermission | Base class for all access permissions. |
| NamedPermissionSet | Defines permissions with name and description attributes. |
| PermissionSet | Collection of different types of permissions. |
| SecurityManager | Main class for security interaction between InfoPath and CLR. |
| VerificationException | The exception raised if anything goes wrong. |
You can implement the following interfaces in your classes created with Visual Studio to use in your custom security model for InfoPath.
| Interfaces | Interface Description |
|---|---|
| IEvidenceFactory | Gets an object's Evidence (property value). |
| IPermission | Defines methods implemented by permission types; can be inherited for utilizing methods and properties of a permission object. |