In previous articles we have seen how the Code Access Security model changed in .NET Framework 4.0.In What's new in code access security in .NET Framework 4.0 - Part I we saw how the CAS Policy System that was used until .NET Framework 3.5 has now been replaced by the Level2 Security Transparent Model. Permissions to use the protected resources granted to an assembly have been moved from the assembly itself to the host in which the assembly runs. All assemblies in a host now have the same security restrictions, thereby conforming to the Homogeneous Domain concept. In What's new in code access security in .NET Framework 4.0 - Part II we saw that, despite the Level2 Security Transparent Model being apparently all-or-nothing, it is, in fact, possible to use Allow Partially Trusted Caller Attribute (APTCA) to mix together SecurityTransparent, SecurityCritical and SecuritySafeCritical attributes to define granular permissions to grant to an assembly when it need to access protected resources. In the two previous articles, we have demonstrated how the new CAS technology works, by providing some examples of simple console applications. We said that, in these cases, there is no host to manage, because any simple application will run as an unhosted application, always as full trust code. In this article we want to analyze how the Level2 Security Transparent Model works within a hosted environment. To do so, we will consider the most important hosted environment that is used today, the ASP.NET Application Domains. We will start by analyzing how ASP.NET application domains have been modified so as to implement the Level2 Security Transparent Model. We then see how to use configuration files to specify the permissions to grant to assemblies loaded inside these application domains. We will do this with the aid of some examples. Finally, we will see how to use APTCA assemblies in ASP.NET to define, in a more granular way, different permissions for different blocks of code, when more flexibility is required.
ASP.NET 4.0 Application DomainAs described in the MSDN library, an application domain is, “...a construct that hosts use to isolate code running within a process...”We know that, when a managed application is executed, the .NET runtime is able to create an application domain in which the assemblies are loaded and executed. For security reasons, an application domain is isolated from other application domains, and the assemblies loaded inside it cannot overpass its boundaries. Read more: Simple-talk
ASP.NET 4.0 Application DomainAs described in the MSDN library, an application domain is, “...a construct that hosts use to isolate code running within a process...”We know that, when a managed application is executed, the .NET runtime is able to create an application domain in which the assemblies are loaded and executed. For security reasons, an application domain is isolated from other application domains, and the assemblies loaded inside it cannot overpass its boundaries. Read more: Simple-talk
Posts
0 comments:
Post a Comment