"Otis" wrote:

> I'm trying to determine if it is possible to programmatically force an
> already authenticated user (Using Integrated Windows Authentication) to login
> 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

> 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 login
> > 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

"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:
> > 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 login
> > > 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
>
>

> 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 (as
> 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:
> > > 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 login
> > > > 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
> >
> >