self-inflicted authentication issue

[kpg]

ASP.NET 2.0

I have an unusual situation dealing with forms authentication,
not doubt brought on by how I have structured the application.

The setup:

Users enter the site from one of several pages, A,B,C, etc.
These pages allow all users. In theses pages I setup site
customizing session variables then redirect users to a common
home page.

The home page is protected by deny anonymous users, so users
are sent to a login page to be authenticated. Authentication
is based on how they entered the site, A,B,C.

I set things up this way so I can use a common login page,
but that page is customized based on how the user entered the
site: A,B,C. (different logo, text, etc.).

The problem:

Let's say a user entered on page 'A', gets authenticated and
is sitting on the home page. Then they edit the browser URL
to navigate to page 'B'. (the user should not do this, but
users do all sorts of thing they shouldn't do).

Well, since the user is already authenticated the login screen
is by-passed. Additionally, since the home page is already
loaded in their browser, the home Page_Load event is not fired.
This results in Page A authentication but Page B session
variables - a big mess

To solve this problem I want to un-authenticate the user in
the page_load event of the entry pages (A,B,C..), but removing
the ASPXAUTH cookie does not seems to unauthenticate the user
as the login page is not displayed for some reason, but it does
force the home page_load event, so this is half correct - but
still no good.

I tried setting the web.config to allow anonymous, deny all on
the entry pages (A,B,C), and this works upon normal entry, but
when the user navigates there after authorization they can't
get past the login screen, because once they are authorized
they are denied access to the requested entry page and sent
back to the login page - and endless loop.

I did come up with something that works: I check for the
..ASPXAUTH cookie on the entry page and if it is present I
send the user to an error page.

To improve on this I keep a session variable "LastValidPage",
and if the user enters the site while authenticated (the
cookie is present) I simply redirect them to this page, so
from the users standpoint nothing has happened.

My question is - is there a better way?

I thought of having each entry page actually be a customized
login page (but I like the idea of having a single login page).

I'm not sure how this would work, the home page would deny
anonymous, so the system would want to redirect to a
login.aspx page - I suppose I could have the login.aspx page
display an error message instead of presenting a login. If
the user tried to access the home page directly they would
get the login error page. Then if the user changed to a
different entry page mid-site, they would need to login based
on that page's criteria and everything could be kept straight.
Thoughts or comments?

Thanks.
kpg

[Mr. Arnold]

"kpg" <[e-mail] in message
news:Xn*******************************@207.46.248. 16...

ASP.NET 2.0

I have an unusual situation dealing with forms authentication,
not doubt brought on by how I have structured the application.

The setup:

Users enter the site from one of several pages, A,B,C, etc.
These pages allow all users. In theses pages I setup site
customizing session variables then redirect users to a common
home page.

>
The home page is protected by deny anonymous users, so users
are sent to a login page to be authenticated. Authentication
is based on how they entered the site, A,B,C.

I set things up this way so I can use a common login page,
but that page is customized based on how the user entered the
site: A,B,C. (different logo, text, etc.).

The problem:

Let's say a user entered on page 'A', gets authenticated and
is sitting on the home page. Then they edit the browser URL
to navigate to page 'B'. (the user should not do this, but
users do all sorts of thing they shouldn't do).

Well, since the user is already authenticated the login screen
is by-passed. Additionally, since the home page is already
loaded in their browser, the home Page_Load event is not fired.
This results in Page A authentication but Page B session
variables - a big mess

http://www.devcity.net/PrintArticle.aspx?ArticleID=47

>
Thoughts or comments?

Why don't you pass an encrypted key between the Web pages? If the URL has
the encrypted key, then you proceed because your program supplied the
correct key in the URL, otherwise, you stop them or redirect them to a *I
got to slap you in the face for this* page.

[kpg]

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in
news:u6**************@TK2MSFTNGP02.phx.gbl:

Why don't you pass an encrypted key between the Web pages? If the URL
has the encrypted key, then you proceed because your program supplied
the correct key in the URL, otherwise, you stop them or redirect them
to a *I got to slap you in the face for this* page.

So you suggest I handle the authentication myself? I like the way you
think. I was 'trying' to do things the 'right way', by that I mean
using the login control and web.config settings, but like in so many
other areas I find that doing it myself is better.

So without the sekrit key I deny access and redirect to an error page,
other than that, all pages are allow anonymous.

I tried my multi-login page technique (which the sekrit key technique
will also use) but with forms authentication even if I authenticate the
user I get sent to the login.aspx page <sigh>. I'm sure there's some
config file I can edit to change that, but I still have the issue that
I will have multiple login pages (as I have found this works out better
for several other unrelated reasons).

So yes, I like your idea - thanks.

kpg

[Mr. Arnold]

"kpg" <[e-mail] in message
news:Xn******************************@207.46.248.1 6...

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in
news:u6**************@TK2MSFTNGP02.phx.gbl:

>Why don't you pass an encrypted key between the Web pages? If the URL
has the encrypted key, then you proceed because your program supplied
the correct key in the URL, otherwise, you stop them or redirect them
to a *I got to slap you in the face for this* page.

So you suggest I handle the authentication myself? I like the way you
think. I was 'trying' to do things the 'right way', by that I mean
using the login control and web.config settings, but like in so many
other areas I find that doing it myself is better.

So without the sekrit key I deny access and redirect to an error page,
other than that, all pages are allow anonymous.

If the solution is to be used by the public or not, it's a means of stopping
them from going where they want, by entering the URL and going there. You
should still keep secuirty in mind, and if a login provides that, then you
should implement that as well.

>
I tried my multi-login page technique (which the sekrit key technique
will also use) but with forms authentication even if I authenticate the
user I get sent to the login.aspx page <sigh>. I'm sure there's some
config file I can edit to change that, but I still have the issue that
I will have multiple login pages (as I have found this works out better
for several other unrelated reasons).

So yes, I like your idea - thanks.

I got that from MCTS 70-528 where they were talking about Encrypting the
QueryString.

Sometimes, one has to think out side the box. And nothing is the wrong way
if it works for you.