Where is the user impersonation token stored?

G

Gery D. Dorazio

When a user visits a web site and is authenticated through the popup dialog
box (Windows authentication) he enters his username and password. Evidently
this creates the users impersonation token that is used on subsequent
requests to secured web pages. On subsequent requests the
WindowsAuthenticationModule is what authenticates on each request. The code
that does this looks like this:

WindowsIdentity wi = new WindowsIdentity(ctx.WorkerRequest.GetUserToken(),
text2, WindowsAccountType.Normal, true);
Context.User = new WindowsPrincipal(wi);


The questions are:
1. Where did the initial Windows authentication put the user impersonation
token?
2. Where is the user impersonation token stored as the user makes web page
requests(or is it generated on each request and if so how?)?


Thanks,
Gery



--
Gery D. Dorazio
Development Engineer

EnQue Corporation
www.EnQue.com
www.ImagingHardware.com
 
D

Dominick Baier [DevelopMentor]

Hello Gery,

1) The outcome os IIS authentication is stored in a blob called ISAP Extension
Control Block - the ASPNET_ISAPI extension passes the token to ASP.NET (via
WorkerRequest). This token is availabe in ASP.NET 2.0 using the Request.LogonUserIdentity

2) There is some caching involved in IIS - but ASP.NET grabs the impersonation
token on each request from IIS to populate Context.User.

HTH
 
G

Gery D. Dorazio

Hi Dominick,

Thanks for the feedback. Can you explain a little more with respect to IIS?

Here is the scenareo that has me stumped and really the reason for the post:

1) User requests a restricted page and the Windows popup dialog appears so
the user logs in and is authenticated. Then the page is served up.
2) The user then clicks on another secured page link and is directed to that
page...no popup since he is already authenticated.

Here is a question that may hit the core of the problem:

How does IIS handle authenticated Windows accounts during client-server
requests to a web server?


Here is my thinking as to what happens and the source of my confusion:

When an HTTP request is finished and the response is sent back to the client
the worker thread is finished and recycled...at least that's how I
understand it. Along with this understanding the server then would have no
knowledge whether the user is logged in....eg http is stateless. Then for
subsequent requests IIS would have to log them in automatically for each
request since they already logged in once. But what happens on the next
request? Where does IIS (or some ISAPI authentication filter/extension) get
the information to re-logon the user? Translated....where is this:
ctx.WorkerRequest.GetUserToken() getting its user token from?...is it stored
in a header, an encrypted cookie passed back and forth between client and
server?...all this is only in regards to Windows authentication and not
ASP.NET forms authentication since I know that is encrypted in a forms
cookie...


Thanks and hope this is clear,


Thanks,
Gery


--
Gery D. Dorazio
Development Engineer

EnQue Corporation
www.EnQue.com
www.ImagingHardware.com
 
D

Dominick Baier [DevelopMentor]

Hello Gery,

first of all the browser never tries to authenticate if he doesn't need to
- when you hit a page where you don't have anonymous access - IIS bounces
back a 401 to the client along with the possible authentication methods.

From that point on the browser sends the authentication information as a
header to the server on each request.

download www.fiddlertool.com and try the different authentication settings
in IIS - you can see the headers flowing back and forth. A good testpage
to test the various settings can be found here:
http://www.leastprivilege.com/UpdatedShowContextsAndRequestLogonUserIdentity.aspx
 
G

Gery D. Dorazio

Hi Dominick,

Do you know what the header is that contains the authentication information
as I think that is what I am looking for? The ISAPI authorization filter I
am looking at calls the ServerSupportFuntion with the HSE_REQ_EXEC_URL
request with another parameter that contains the impersonation token...The
docs don't say what header(s) get set that contain this information.

The ISAPI authentication filter (CustomAuth from IIS 6 resource kit) is for
using a web page to do Windows authentication so that the IE dialog is no
longer used.

Thanks,
Gery

--
Gery D. Dorazio
Development Engineer

EnQue Corporation
www.EnQue.com
www.ImagingHardware.com
 
G

Gery D. Dorazio

Dominick,

It looks like this is an IIS question now. I am going to look around over on
the IIS.Security newsgroup and possibly post over there also.

Thanks,
Gery

--
Gery D. Dorazio
Development Engineer

EnQue Corporation
www.EnQue.com
www.ImagingHardware.com
 
K

Ken Schaefer

Credentials are in the Authorization: header sent from client -> server.
(unless you are using Passport authentication which is cookie based, or
using client certificates etc).

Again, using the HTTP Fiddler tool mentioned earlier will help you look at
these things.

Cheers
Ken


: Hi Dominick,
:
: Do you know what the header is that contains the authentication
information
: as I think that is what I am looking for? The ISAPI authorization filter I
: am looking at calls the ServerSupportFuntion with the HSE_REQ_EXEC_URL
: request with another parameter that contains the impersonation token...The
: docs don't say what header(s) get set that contain this information.
:
: The ISAPI authentication filter (CustomAuth from IIS 6 resource kit) is
for
: using a web page to do Windows authentication so that the IE dialog is no
: longer used.
:
: Thanks,
: Gery
:
: --
: Gery D. Dorazio
: Development Engineer
:
: EnQue Corporation
: www.EnQue.com
: www.ImagingHardware.com
:
: "Dominick Baier [DevelopMentor]" <[email protected]>
: wrote in message : > Hello Gery,
: >
: > first of all the browser never tries to authenticate if he doesn't need
: > to - when you hit a page where you don't have anonymous access - IIS
: > bounces back a 401 to the client along with the possible authentication
: > methods.
: >
: > From that point on the browser sends the authentication information as a
: > header to the server on each request.
: >
: > download www.fiddlertool.com and try the different authentication
settings
: > in IIS - you can see the headers flowing back and forth. A good testpage
: > to test the various settings can be found here:
: >
http://www.leastprivilege.com/UpdatedShowContextsAndRequestLogonUserIdentity.aspx
: >
: > ---------------------------------------
: > Dominick Baier - DevelopMentor
: > http://www.leastprivilege.com
: >
: >> Hi Dominick,
: >>
: >> Thanks for the feedback. Can you explain a little more with respect to
: >> IIS?
: >>
: >> Here is the scenareo that has me stumped and really the reason for the
: >> post:
: >>
: >> 1) User requests a restricted page and the Windows popup dialog
: >> appears so
: >> the user logs in and is authenticated. Then the page is served up.
: >> 2) The user then clicks on another secured page link and is directed
: >> to that
: >> page...no popup since he is already authenticated.
: >> Here is a question that may hit the core of the problem:
: >>
: >> How does IIS handle authenticated Windows accounts during
: >> client-server requests to a web server?
: >>
: >> Here is my thinking as to what happens and the source of my confusion:
: >>
: >> When an HTTP request is finished and the response is sent back to the
: >> client the worker thread is finished and recycled...at least that's
: >> how I understand it. Along with this understanding the server then
: >> would have no knowledge whether the user is logged in....eg http is
: >> stateless. Then for subsequent requests IIS would have to log them in
: >> automatically for each request since they already logged in once. But
: >> what happens on the next request? Where does IIS (or some ISAPI
: >> authentication filter/extension) get the information to re-logon the
: >> user? Translated....where is this: ctx.WorkerRequest.GetUserToken()
: >> getting its user token from?...is it stored in a header, an encrypted
: >> cookie passed back and forth between client and server?...all this is
: >> only in regards to Windows authentication and not ASP.NET forms
: >> authentication since I know that is encrypted in a forms cookie...
: >>
: >> Thanks and hope this is clear,
: >>
: >> Thanks,
: >> Gery
: >> EnQue Corporation
: >> www.EnQue.com
: >> www.ImagingHardware.com
: >> "Dominick Baier [DevelopMentor]"
: >> : >>
: >>> Hello Gery,
: >>>
: >>> 1) The outcome os IIS authentication is stored in a blob called ISAP
: >>> Extension Control Block - the ASPNET_ISAPI extension passes the token
: >>> to ASP.NET (via WorkerRequest). This token is availabe in ASP.NET 2.0
: >>> using the Request.LogonUserIdentity
: >>>
: >>> 2) There is some caching involved in IIS - but ASP.NET grabs the
: >>> impersonation token on each request from IIS to populate
: >>> Context.User.
: >>>
: >>> HTH
: >>> ---------------------------------------
: >>> Dominick Baier - DevelopMentor
: >>> http://www.leastprivilege.com
: >>>> When a user visits a web site and is authenticated through the popup
: >>>> dialog box (Windows authentication) he enters his username and
: >>>> password. Evidently this creates the users impersonation token that
: >>>> is used on subsequent requests to secured web pages. On subsequent
: >>>> requests the WindowsAuthenticationModule is what authenticates on
: >>>> each request. The code that does this looks like this:
: >>>>
: >>>> WindowsIdentity wi = new
: >>>> WindowsIdentity(ctx.WorkerRequest.GetUserToken(),
: >>>> text2, WindowsAccountType.Normal, true);
: >>>> Context.User = new WindowsPrincipal(wi);
: >>>> The questions are:
: >>>> 1. Where did the initial Windows authentication put the user
: >>>> impersonation
: >>>> token?
: >>>> 2. Where is the user impersonation token stored as the user makes
: >>>> web
: >>>> page
: >>>> requests(or is it generated on each request and if so how?)?
: >>>> Thanks,
: >>>> Gery
: >>>> EnQue Corporation
: >>>> www.EnQue.com
: >>>> www.ImagingHardware.com
: >
: >
:
:
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,014
Latest member
BiancaFix3

Latest Threads

Top