ASP.NET Architecture, Part 2 - Error Handling and Security
(Page 7 of 7 )
The Page_Error handler helps manage error handling at the page level. Whenever the page encounters an error, it generates an exception. You can scrutinize the error by applying the Server.GetLastError method. This is invaluable when trying to trace the error to its source.
System.Exception is the base class for all exceptions. When an error occurs, either the system or the executing application throws the exception in a “try, catch” block. Once the exception is thrown, the application handles it by employing the default exception handler.
If you consider how the classicWindows applications handle security, the user has the option of deciding whether to let the executable run or not. For example, if you download some code from the Internet and allow the code to run, you have no control over what the executable actually does. The .NET Framework removes this option and places the application security within the assembly itself.
The assembly defines type scope as well as an assembly’s security boundary, so to speak. The CLR implements two distinct types of security:
- Code access security
- Role-based security
The .NET code access security has two criteria: permissions that the code requests and what permissions are based on the security policy in effect when the code executes. An assembly interacts with the CLR in numerous ways. It can request the specific permissions it requires for executing in a given environment. Here are some permissions an assembly can request:
- UI Permission Permits access to a specified interface
- FileIOPermission Allows access to both files and directories
- EnvironmentPermission Enables access to environment variables
- ReflectionPermission Provides access to metadata residing within the assembly
- SecurityPermission Permits granting access to a group of permissions
- WebPermission Manages Internet connections
You have two methods for embedding security permissions within an application: a declarative method and an imperative method.With the declarative method, you can write security code attributes in your code. The attributes become part of the metadata for the assembly. The imperative method lets you insert security permissions dynamically at runtime. The CLR inspects application security requests and compares them with any existing machine security roles. If the security permissions only allow read access to metadata or to specified files or directories, the assembly denies any further access.
An assembly provides several pieces of information about itself:
- The assembly’s identity contains a digital signature generated by its publisher.
- The assembly’s identity is represented by its strong name.
- The assembly specifies the exact URL from which an assembly was downloaded.
- The assembly identifies the zone defined by Internet Explorer. It reveals the exact source from which the assembly was downloaded.
When the assembly loads, the CLR examines permissions requested by the assembly. Subsequently, the assembly receives permissions specified by the security role in effect for a machine on which the assembly resides.
Role-based security allows the CLR to restrict what permissions are granted based on the assembly’s name, its origin, and who published it. Code access security makes no provisions for controlling the behavior of an assembly based on a user’s identity. Rather, the Object contains all information concerning the object’s identity and roles to which the object is assigned. If you consider the classic Windows method for assigning a role to a user or user group, you can fully understand what role-based security is.
 This has been part two of ASP.NET Architecture (see part 1 here), chapter six of .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223054-1, 2004).
Buy this book now. |
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
/ 15 
