The following comes from
http://msdn.microsoft.com/library/de...html/DAMAZ.asp
Using Automatic Identity Flow
The common language runtime automatically provides identity flow when all of
the code that requires the identity executes in the same context. The caller
and callee are in the same context when they share the same application
domain. If the client code (referred to as the caller) and the component
being called (referred to as the callee) are running within the same
context, .NET automatically uses the same Thread.CurrentPrincipal object for
both the caller and the callee. For cases in which the callee and caller
execute on different threads, see "Performing Authorization with Multiple
Threads" later in this chapter.
"hazz" <hazz@sonic.net> wrote in message
news:ejiIHa9VEHA.808@tk2msftngp13.phx.gbl...[color=blue]
> I think I just discovered the obvious? You can't cross AppDomains with the
> Principal and Identity. Separate thread.
> As long as the app is alive, I can use GenericPrincipal to access the[/color]
Custom[color=blue]
> AuthenticationType and custom roles only within the "context" from which[/color]
the[color=blue]
> app is created, and only on the thread associated with that application.
> The app will authenticate the user, the app will assign the role for that
> user and retain the roles on the thread that both belong to the app and[/color]
the[color=blue]
> user for the lifetime of the application. If the user leaves (shuts down[/color]
the[color=blue]
> app) they will have to re-authenticate.
>
>
> "hazz" <hazz@sonic.net> wrote in message
> news:uVS6Qr8VEHA.3024@TK2MSFTNGP09.phx.gbl...[color=green]
> > If I successfully run a VS.NET app which includes the following;
> >
> > ************************** APP 1 ****************************
> >
> > m_iIdnt = new
> >[/color][/color]
System.Security.Principal.GenericIdentity(t.UserNa me,"MyAuthentication");[color=blue][color=green]
> > //user and My authentication type added to Identity
> >
> > string[] roles = {"Chief Cook and Bottle Washer", "Master Gardener"};
> >
> >
> > m_iPrincipal = new
> > System.Security.Principal.GenericPrincipal(m_iIdnt ,roles); //roles and
> > Identity added to Principal
> >
> > System.Threading.Thread.CurrentPrincipal = m_iPrincipal; //Threads
> > current principal is set
> >
> > ************************************************** **************
> >
> > and then create a new VS.NET app to retrieve the Principal and Identity[/color]
> off[color=green]
> > the thread created in APP 1 above
> >
> >
> > *************************** APP 2 ****************************
> >
> >
> >[/color]
>[/color]
AppDomain.CurrentDomain.SetPrincipalPolicy(Princip alPolicy.WindowsPrincipal)[color=blue][color=green]
> > ;
> > IPrincipal currentPrincipal = Thread.CurrentPrincipal;
> >
> >
> > IIdentity currentIdentity = currentPrincipal.Identity;
> > string authtype = currentIdentity.AuthenticationType;
> > string iden = currentIdentity.Name;
> >
> > ************************************************** **************
> >
> > I get NTLM as the authentication type.
> > I want to retrieve the thread that has "MyAuthentication" as the
> > authenticationtype.
> >
> > Where am I at in the landscape here? Different app domains, different
> > threads, different principle?
> >
> > Where I am trying to go is move from a role-based initiation of[/color][/color]
user/role[color=blue][color=green]
> > and then later using declarative security, grab the user/role from the
> > "appropriate runtime thread" (where my understanding falls apart) to[/color]
> compare[color=green]
> > with a database or config file user/role.
> >
> > Thank you for helping me with the context and any implementation[/color][/color]
details.[color=blue][color=green]
> >
> > -Greg
> >
> >[/color]
>
>[/color]
threading and Principal question - from Role-based security to declarative security. 
