threading and Principal question - from Role-based security to declarative security.

[hazz]

If I successfully run a VS.NET app which includes the following;

************************** APP 1 ****************************

m_iIdnt = new
System.Security.Principal.GenericIdentity(t.UserName,"MyAuthentication");
//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 off
the thread created in APP 1 above


*************************** APP 2 ****************************


AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
;
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 user/role
and then later using declarative security, grab the user/role from the
"appropriate runtime thread" (where my understanding falls apart) to compare
with a database or config file user/role.

Thank you for helping me with the context and any implementation details.

-Greg

 

[hazz]

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 Custom
AuthenticationType and custom roles only within the "context" from which the
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 the
user for the lifetime of the application. If the user leaves (shuts down the
app) they will have to re-authenticate.

 

[Scott Allen]

Check out:
A .net developer's guide to Windows security by Keith Brown.
http://www.pluralsight.com/keith/book/

HTH,

 

[hazz]

Thank you Scott!
Much appreciated....
-Greg

Check out:
A .net developer's guide to Windows security by Keith Brown.
http://www.pluralsight.com/keith/book/

HTH,

 

[hazz]

The following comes from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/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.

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 Custom
AuthenticationType and custom roles only within the "context" from which the
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 the
user for the lifetime of the application. If the user leaves (shuts down the
app) they will have to re-authenticate.

If I successfully run a VS.NET app which includes the following;

************************** APP 1 ****************************

m_iIdnt = new
System.Security.Principal.GenericIdentity(t.UserName,"MyAuthentication");
//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 off
the thread created in APP 1 above


*************************** APP 2 ****************************

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)

;
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 user/role
and then later using declarative security, grab the user/role from the
"appropriate runtime thread" (where my understanding falls apart) to compare
with a database or config file user/role.

Thank you for helping me with the context and any implementation details.

-Greg