I'm trying to determine if it is possible to programmatically force an
already authenticated user (Using Integrated Windows Authentication) to logi
n
again for my web site.  I want them to be able to "logoff" for security
reasons and not have to close their browser.  That way if someone sits at
their workstation and tries to link again to the site in question it will
prompt with the windows dialog again.  Currently, if I try to "login" again
in the same browser it appears to already know who I am (a believe some
cookie or token is being held onto) and doesn't prompt me to login again.
Any ideas anyone?
--
Thanks,
Otis

[ Post a follow-up to this message ]

I continue to research this and have hypothesized that what I'd really like
to happen is to have IIS issue a NEW session id to the client once
Session.Abandon is specified in my ASP.NET application.  What appears to
happen by default is that the Session ID remains the same after the abandon,
but on the next connection IsNewSession is true.  My hope is that when IIS
sees a different SessionID it will again prompt for the user with a windows
login dialog.  Anyone got any feedback on this "guess"?

Again,
Otis

--
Thanks,
Otis


"Otis" wrote:

> I'm trying to determine if it is possible to programmatically force an
> already authenticated user (Using Integrated Windows Authentication) to lo
gin
> again for my web site.  I want them to be able to "logoff" for security
> reasons and not have to close their browser.  That way if someone sits at
> their workstation and tries to link again to the site in question it will
> prompt with the windows dialog again.  Currently, if I try to "login" agai
n
> in the same browser it appears to already know who I am (a believe some
> cookie or token is being held onto) and doesn't prompt me to login again.
> Any ideas anyone?
> --
> Thanks,
> Otis

[ Post a follow-up to this message ]

Actually, what you want to do is impossible with your current
constraints. You will have to write a custom authentication protocol to
get the behavior you want.

And let's just leave your hypothesis alone - there are no
cookies/tokens involved; IIS has no idea what a session is; IIS does
not prompt with a login dialog.

The problem you face is that a browser will automatically attempt
Integrated Authentication using the currently logged in Windows user
credentials to login to a website which is in a Zone configured for
auto login. And the server cannot do anything about it because logins
(and auto-login) is a client-side optimization.

If you can control the browsers to not auto-login to your website, and
you can make your Web Application CLOSE the connection to logoff, then
you can get the behavior you want with Integrated Authentication
(NTLM). Integrated Authentication (Kerberos) is something different.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//


Otis wrote:[vbcol=seagreen]
> I continue to research this and have hypothesized that what I'd really lik
e
> to happen is to have IIS issue a NEW session id to the client once
> Session.Abandon is specified in my ASP.NET application.  What appears to
> happen by default is that the Session ID remains the same after the abando
n,
> but on the next connection IsNewSession is true.  My hope is that when IIS
> sees a different SessionID it will again prompt for the user with a window
s
> login dialog.  Anyone got any feedback on this "guess"?
>
> Again,
> Otis
>
> --
> Thanks,
> Otis
>
>
> "Otis" wrote:
> 

[ Post a follow-up to this message ]

David,
Thanks for the reply.  I was heading down the wrong path trying to reset the
SessionID with Response.Cookies.Add(New HttpCookie("ASP.NET_SessionId", ""))
and though that did force a new sessionid... it invalidated my hypothesis (a
s
I believe you were hinting at by not addressing it).
So, now it appears you are suggesting I either write a custom authentication
protocol ( I might be up for that) or I make the browsers not auto-login ( I
can specify that) while also having the Web Application CLOSE the connection
.

1) Could you suggest a web site or book with examples on writing the custom
authentication protocol please?
2) How does one CLOSE the connection programmatically from the Web
Application?
Thanks in advance for your reply!
--
Thanks,
Otis


"David Wang" wrote:

> Actually, what you want to do is impossible with your current
> constraints. You will have to write a custom authentication protocol to
> get the behavior you want.
>
> And let's just leave your hypothesis alone - there are no
> cookies/tokens involved; IIS has no idea what a session is; IIS does
> not prompt with a login dialog.
>
> The problem you face is that a browser will automatically attempt
> Integrated Authentication using the currently logged in Windows user
> credentials to login to a website which is in a Zone configured for
> auto login. And the server cannot do anything about it because logins
> (and auto-login) is a client-side optimization.
>
> If you can control the browsers to not auto-login to your website, and
> you can make your Web Application CLOSE the connection to logoff, then
> you can get the behavior you want with Integrated Authentication
> (NTLM). Integrated Authentication (Kerberos) is something different.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
> Otis wrote: 
>
>

[ Post a follow-up to this message ]

Unfortunately, I am bad at giving advice for websites or books for this
stuff because I don't use them (I'd just go build it myself with just
an API reference). I would not mind perusing/evaluating any
website/books that you come across.

Hmm, maybe I can get motivated with enough time to go blog about this
topic as well.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//



Otis wrote:[vbcol=seagreen]
> David,
> Thanks for the reply.  I was heading down the wrong path trying to reset t
he
> SessionID with Response.Cookies.Add(New HttpCookie("ASP.NET_SessionId", ""
))
> and though that did force a new sessionid... it invalidated my hypothesis 
(as
> I believe you were hinting at by not addressing it).
> So, now it appears you are suggesting I either write a custom authenticati
on
> protocol ( I might be up for that) or I make the browsers not auto-login (
 I
> can specify that) while also having the Web Application CLOSE the connecti
on.
>
> 1) Could you suggest a web site or book with examples on writing the custo
m
> authentication protocol please?
> 2) How does one CLOSE the connection programmatically from the Web
> Application?
> Thanks in advance for your reply!
> --
> Thanks,
> Otis
>
>
> "David Wang" wrote:
> 

[ Post a follow-up to this message ]