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.UserNa me,"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(Princip alPolicy.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.
"hazz" <ha**@sonic.net> wrote in message
news:uV**************@TK2MSFTNGP09.phx.gbl...

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

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

m_iIdnt = new
System.Security.Principal.GenericIdentity(t.UserNa me,"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(Princip alPolicy.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

[Scott Allen]

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

HTH,

--
Scott
http://www.OdeToCode.com

On Mon, 21 Jun 2004 15:27:14 -0600, "hazz" <ha**@sonic.net> wrote:

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.

[hazz]

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

"Scott Allen" <bitmask@[nospam].fred.net> wrote in message
news:j3********************************@4ax.com...

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

HTH,

--
Scott
http://www.OdeToCode.com

On Mon, 21 Jun 2004 15:27:14 -0600, "hazz" <ha**@sonic.net> wrote:

I think I just discovered the obvious? You can't cross AppDomains with thePrincipal and Identity. Separate thread.
As long as the app is alive, I can use GenericPrincipal to access the CustomAuthenticationType and custom roles only within the "context" from which theapp 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 theuser for the lifetime of the application. If the user leaves (shuts down theapp) they will have to re-authenticate.

[hazz]

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" <ha**@sonic.net> wrote in message
news:ej*************@tk2msftngp13.phx.gbl...

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.
"hazz" <ha**@sonic.net> wrote in message
news:uV**************@TK2MSFTNGP09.phx.gbl...

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

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

m_iIdnt = new
System.Security.Principal.GenericIdentity(t.UserNa me,"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(Princip alPolicy.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