Csla.ApplicationContext.User is always valid, regardless of the CslaAuthentication setting.
If CslaAuthentication is "Windows" then CSLA does nothing with to set or manipulate the principal, but Csla.ApplicationContext.User will still provide access to the current .NET principal.
If CslaAuthentication is "Csla" then CSLA will transfer the principal to the app server on every data portal call. Csla.ApplicationContext.User provides access to the current .NET principal.
In version 3.5 or older the data portal has exactly one requirement: the custom principal must inherit from Csla.Security.BusinessPrincipalBase. It doesn't care if the principal is authenticated or not, just that it inherit from that base class.
So all you need to do is call Logout() (usually) to set the principal to a valid but unauthenticated principal, and the data portal will work.
In version 3.6+ the data portal no longer cares how you create your principal, as long as it is serializable. This version introduces the ability for you to provide a method that is invoked, on the server, for every data portal call, and that method can authenticate each call as you see fit. The default implementation allows all calls.
So in 3.6+ you usually don't even need to call Logout(), because the .NET default GenericPrincipal will work fine flowing through the data portal. This should eliminate one of the primary FAQs on this forum :)
Copyright (c) Marimer LLC