Setting Role-Based Security Policy and Principals
Role-based security enables a component to identify current users and their associated roles at run time. This information is then mapped using a code-access security policy to determine the set of permissions granted at run time. For a given application domain, the host can change the default role-based security policy and set a default security principal. A security principal represents a user and the roles associated with that user.
Role-based security is commonly used to implement custom authentication schemes. For example, the ASP.NET host uses role-based security to implement an authentication scheme based on user information it gets from Internet Information Services (IIS).
The definition of both the user and the user's roles is application-specific. An application can have a different concept of user than Windows does. For example, an application might ask the user to provide a user name and password when logging on to the application. This user name/password is independent of the user name/password with which the user logged on to Windows.
Explicitly Setting the Principal for a Thread
If the principal for a thread has been set, the application domain's policy and default principal are ignored. For example, the thread might have set its own principal by using the CurrentPrincipal static property (Shared property in Visual Basic) of the Thread class. Alternatively, the thread might have acquired its principal from the thread that started it.
.gif "Note") Note |
|---|
In the .NET Framework version 2.0, when a thread starts another thread or queues a work item for execution by the thread pool, the thread's context (including the security principal) automatically flows to the child thread or the thread pool thread. In the .NET Framework versions 1.0 and 1.1, context flowed only to threads started by a thread, and not to thread pool threads. |
If a thread that does not have a security principal takes an action that requires a principal, a principal is supplied based on the current application domain's security policy and default security principal.
| Note |
|---|
When a thread that does not have a security principal uses the CurrentPrincipal static property to query its principal, the application domain's defaults are used to set the principal. That is, CurrentPrincipal never returns null. |
Policy and Default Principal for an Application Domain
A host can set a default principal for an application domain by calling the SetThreadPrincipal method. If a default principal has been supplied, it is assigned to any thread that is executing in the application domain, requires a principal, and does not already have a principal.
| Note |
|---|
The default principal is not automatically applied to the thread that calls SetThreadPrincipal, even if that thread does not have a principal. If the thread later requires a principal, and has not acquired one in the meantime, it is assigned a principal according to the default principal and policy of the application domain in which it is executing at the time. |
If a default principal has not been set for the application domain, the thread is assigned a principal according to the policy for the application domain. By default, the policy of an application domain is to assign an unauthenticated generic principal to the thread. A host can change this policy for an application domain by calling the SetPrincipalPolicy method. For example, the following managed code creates an application domain and sets its policy to use the current Windows principal.
Dim ad As AppDomain = AppDomain.CreateDomain("Child")
ad.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
AppDomain ad = AppDomain.CreateDomain("Child");
ad.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
AppDomain^ ad = AppDomain::CreateDomain("Child");
ad->SetPrincipalPolicy(PrincipalPolicy::WindowsPrincipal);
An unmanaged host can access application domains using the _AppDomain interface, which preserves vtable order across versions of the .NET Framework.