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. Hosts can set both role-based security policy and a current security principal for a given application domain. 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.

A host can set a principal for the current thread by calling the SetThreadPrincipal method of the System.AppDomain class. The current principal is used as input to code access security. It determines whether a given principal can perform a specified action.

The .NET Framework provides the concept of a default principal. This is a principal that is automatically associated with a running thread if no principal has been explicitly set. The built-in values for the default principal include an unauthenticated user and the Windows user in whose account the thread is currently executing. Hosts can change the default principal by calling the SetPrincipalPolicy of the System.AppDomain class.

See Also

Hosting the Common Language Runtime | System.AppDomain Class | Role-Based Security | Key Security Concepts