don't understand AppDomain.CurrentDomain.SetPrincipalPolicy

don't understand AppDomain.CurrentDomain.SetPrincipalPolicy

• Juan M. Aguirregabiria

  Hi Amethyste,
  
  Please take a look at this Tutorial:
  Introduction to Role-Based Security in .NET
  
  For Repeated Role-based Validation: Use the AppDomain.CurrentDomain's SetPrincipalPolicy method instead of the Thread's CurrentPrincipal property when consistent validation against the current principal is present. The default is for the AppDomain to use the PrincipalPolicy.UnauthenticatedPrincipal policy.

  String strUsername = "";
  AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
  strUserName = System.Threading.Thread.CurrentPrincipal.Identity.Name);
  // strUsername will be 'DomainName\Username'

  AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.NoPrincipal);
  strUserName = System.Threading.Thread.CurrentPrincipal.Identity.Name);
  // A null reference exception will occur as no
  // principal object was automatically created

  AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.UnauthenticatedPrincipal);
  strUserName = System.Threading.Thread.CurrentPrincipal.Identity.Name);
  // strUsername will be '' (empty) even though an
  // IPrincipal object was automatically created
  
  Regards,
  Vikram
  
  

  
  
  

• Griffonbait

  OK thank you Vikram. Your link is very interesting and help me to clarify some details.
  
  I also disassembled some classes like thread, appdomain and httpapplication and I thing I have clear ideas now on what happened.
  
  In fact there is 2 cases:
  
  If the application is hosted by ASP.
  IIS authenticate a user (possibly anonymous) an HttpContext is created and passed to .NET application. This context has a Principal built by the athentification process. This principal is set to CurrentPrincipal property of the ASP thread every request.
  
  So in an ASP context I don't need SetPrincipalPolicy and this is what I have seen.
  
  If the application is a console or Windows form application things are differents.
  A principal is still created by Windows authentication or some customized process but not automatically affected to CurrentPrincipal.
  
  This is the reason why I should call SetPrincipalPolicy ot SetThreadPrincipal in order to provide a similar mechanism.
  
  I now have to check what happend for webservice and remoting
  
  
• don't understand AppDomain.CurrentDomain.SetPrincipalPolicy