Forms Authentication w/SubFolders

[JTR]

I'm trying to create a structure I can share
authentication from a root application with many
subordinate applications (subfolders).

The web.config file for the root has:

<authorization>
<allow users="*" />
</authorization>

Then, each subordinate application (subfolder) has a
web.config with the following:

<authentication mode="Forms">
<forms name=".BUZZARD"
loginUrl="../login.aspx">
</forms>
</authentication>
<authorization>
<deny users="?" />
</authorization>

When the user access a resource in a subfolder, the login
form is displayed and authenticates the user correctly,
including the creation of an authentication ticket. But,
when the login form attempts to redirect the browser to
the requested secure resource, the login form is
redisplayed. I have tried using
FormsAuthentication.RedirectFromLoginPage() and
Response.Redirect() with the same results.

Any ideas?

JTR.

[JTR]

I was able to demonstrate the same as you in terms of ASPX
pages authenticating/redirecting properly as long as they
exist in the root. Unfortunately, not much good for an
application.

I performed more testing/analysis and was able to get an
ASPX page in a nested folder to be
authenticated/redirected properly as long as the nested
folder was not classified as an ASP.NET Application (IIS
Manager) and the corresponding assembly (DLL) was located
in the root folder's BIN folder. I plan to follow this
path and use an application config file (<app>.dll.config)
in the root bin folder to setup alternate codebase paths.

JTR.

>-----Original Message-----
>I have come into this newsgroup precisely to look for an

answer to this. I

>am quite amazed to see this very question! Furthermore,

I see a posting

>made a few days later that reports a similar issue:

Sucessful authentication

>returns to the login page.
>
>My situation is that in root, aspx pages authenticate

fine (the login.aspx

>form is in the root, as well). But in sub-directories,

while the login.aspx

>form is correctly invoked, the redirect returns to the

login.aspx page.

>This happens regardless of the presense of a web.config

file in the

>subdirectory, or the contents of it. I have played

around with variations

>for about 3 hours. I have verified that the cookies is

being created and

>sent, but for some reason the application in the sub-

directory is not hip to

>the fact that this cookie exists, and returns to the

login.aspx page.

>
>Pretty big problem. Hope there is a simple fix.
>
>Thanks for all suggestions.
>-Joel
>
>
>"JTR" <jtrichard@sotasw.com> wrote in message
>news:038001c35618$a80ca270$a601280a@phx.gbl...

>> I'm trying to create a structure I can share
>> authentication from a root application with many
>> subordinate applications (subfolders).
>>
>> The web.config file for the root has:
>>
>> <authorization>
>> <allow users="*" />
>> </authorization>
>>
>> Then, each subordinate application (subfolder) has a
>> web.config with the following:
>>
>> <authentication mode="Forms">
>> <forms name=".BUZZARD"
>> loginUrl="../login.aspx">
>> </forms>
>> </authentication>
>> <authorization>
>> <deny users="?" />
>> </authorization>
>>
>> When the user access a resource in a subfolder, the

login

>> form is displayed and authenticates the user correctly,
>> including the creation of an authentication ticket.

But,

>> when the login form attempts to redirect the browser to
>> the requested secure resource, the login form is
>> redisplayed. I have tried using
>> FormsAuthentication.RedirectFromLoginPage() and
>> Response.Redirect() with the same results.
>>
>> Any ideas?
>>
>> JTR.

>
>
>.
>

[Joel Finkel]

JTR,

Does you server have any underscrores ("_") in its name?

-Joel



"JTR" <jtrichard@sotasw.com> wrote in message
news:07d901c35a99$c3e644d0$a601280a@phx.gbl...

> I was able to demonstrate the same as you in terms of ASPX
> pages authenticating/redirecting properly as long as they
> exist in the root. Unfortunately, not much good for an
> application.
>
> I performed more testing/analysis and was able to get an
> ASPX page in a nested folder to be
> authenticated/redirected properly as long as the nested
> folder was not classified as an ASP.NET Application (IIS
> Manager) and the corresponding assembly (DLL) was located
> in the root folder's BIN folder. I plan to follow this
> path and use an application config file (<app>.dll.config)
> in the root bin folder to setup alternate codebase paths.
>
> JTR.

> >-----Original Message-----
> >I have come into this newsgroup precisely to look for an

> answer to this. I

> >am quite amazed to see this very question! Furthermore,

> I see a posting

> >made a few days later that reports a similar issue:

> Sucessful authentication

> >returns to the login page.
> >
> >My situation is that in root, aspx pages authenticate

> fine (the login.aspx

> >form is in the root, as well). But in sub-directories,

> while the login.aspx

> >form is correctly invoked, the redirect returns to the

> login.aspx page.

> >This happens regardless of the presense of a web.config

> file in the

> >subdirectory, or the contents of it. I have played

> around with variations

> >for about 3 hours. I have verified that the cookies is

> being created and

> >sent, but for some reason the application in the sub-

> directory is not hip to

> >the fact that this cookie exists, and returns to the

> login.aspx page.

> >
> >Pretty big problem. Hope there is a simple fix.
> >
> >Thanks for all suggestions.
> >-Joel
> >
> >
> >"JTR" <jtrichard@sotasw.com> wrote in message
> >news:038001c35618$a80ca270$a601280a@phx.gbl...

> >> I'm trying to create a structure I can share
> >> authentication from a root application with many
> >> subordinate applications (subfolders).
> >>
> >> The web.config file for the root has:
> >>
> >> <authorization>
> >> <allow users="*" />
> >> </authorization>
> >>
> >> Then, each subordinate application (subfolder) has a
> >> web.config with the following:
> >>
> >> <authentication mode="Forms">
> >> <forms name=".BUZZARD"
> >> loginUrl="../login.aspx">
> >> </forms>
> >> </authentication>
> >> <authorization>
> >> <deny users="?" />
> >> </authorization>
> >>
> >> When the user access a resource in a subfolder, the

> login

> >> form is displayed and authenticates the user correctly,
> >> including the creation of an authentication ticket.

> But,

> >> when the login form attempts to redirect the browser to
> >> the requested secure resource, the login form is
> >> redisplayed. I have tried using
> >> FormsAuthentication.RedirectFromLoginPage() and
> >> Response.Redirect() with the same results.
> >>
> >> Any ideas?
> >>
> >> JTR.

> >
> >
> >.
> >

[Scott Scott]

Have you thought about using an ISAPI filter like AuthentiX ?

There is a free version (100 users/2 groups):

[url]http://www.flicks.com/authentix100/[/url]

and of course a full version .

[url]http://www.flicks.com/prod.htm#authnx[/url]



*** Sent via Developersdex [url]http://www.developersdex.com[/url] ***
Don't just participate in USENET...get rewarded for it!

[John Kraft]

Joel Finkel wrote:

> I have come into this newsgroup precisely to look for an answer to this. I
> am quite amazed to see this very question! Furthermore, I see a posting
> made a few days later that reports a similar issue: Sucessful authentication
> returns to the login page.
>
> My situation is that in root, aspx pages authenticate fine (the login.aspx
> form is in the root, as well). But in sub-directories, while the login.aspx
> form is correctly invoked, the redirect returns to the login.aspx page.
> This happens regardless of the presense of a web.config file in the
> subdirectory, or the contents of it. I have played around with variations
> for about 3 hours. I have verified that the cookies is being created and
> sent, but for some reason the application in the sub-directory is not hip to
> the fact that this cookie exists, and returns to the login.aspx page.
>
> Pretty big problem. Hope there is a simple fix.
>
> Thanks for all suggestions.
> -Joel
>
>
> "JTR" <jtrichard@sotasw.com> wrote in message
> news:038001c35618$a80ca270$a601280a@phx.gbl...
>

>>I'm trying to create a structure I can share
>>authentication from a root application with many
>>subordinate applications (subfolders).
>>
>>The web.config file for the root has:
>>
>><authorization>
>><allow users="*" />
>></authorization>
>>
>>Then, each subordinate application (subfolder) has a
>>web.config with the following:
>>
>> <authentication mode="Forms">
>><forms name=".BUZZARD"
>>loginUrl="../login.aspx">
>></forms>
>> </authentication>
>> <authorization>
>><deny users="?" />
>> </authorization>
>>
>>When the user access a resource in a subfolder, the login
>>form is displayed and authenticates the user correctly,
>>including the creation of an authentication ticket. But,
>>when the login form attempts to redirect the browser to
>>the requested secure resource, the login form is
>>redisplayed. I have tried using
>>FormsAuthentication.RedirectFromLoginPage() and
>>Response.Redirect() with the same results.
>>
>>Any ideas?
>>
>>JTR.

>
>
>

I was having this problem too. It turned out to not be a problem with
the cookie, but with the encryption/decryption of the cookie. Even
though the cookie was inside the same project, even though a subfolder,
the encryption key is supposed to be the same. It wasn't. I tried
manually setting the encryption key in the webconfig. I even tried
putting another copy of the same web.config into the subdirectory. For
some reason nothing seemed to work. We ended up setting the
protection="All" to protection="None" to get around it. We still have
not corrected the problem, but if you make that change it might indicate
that the problem is not actually with the cookie.

John

[Joel Finkel]

Glen,

Unfortunately, even under .NET 1.1 this problem still exists. I am quite
convinced that the FormsAuthentication.Authenticate works correctly and is
returning the proper value. The problem is that
FormsAuthentication.RedirectFromLoginPage is returning to the login page.

I am now also convinced that this problem is not related to improperly named
servers or domains, as I have completely rebuilt my network and completely
uninstalled and reinstalled .NET on the server.

I would like to know if ANYONE has this configured and running correctly!
In other words, can someone who actually has it working tell us how they
have things configured?

Thanks!

Joel Finkel
[email]finkel@sd-il.com[/email]


"Glen M" <glen@lfsh.com> wrote in message
news:ad561414.0308091953.590148d2@posting.google.c om...

> The solution is in the machine.config file. Under .Net 1.1, there is
> an option to isolate the security used by each application. The
> standard machineKey looks like the following.
>
> <machineKey validationKey="AutoGenerate,IsolateApps"
> decryptionKey="AutoGenerate" validation="SHA1"/>
>
> Under .Net 1.0 there was no option to "IsolateApps". So changing the
> key to the following will fix the problem.
>
> <machineKey validationKey="AutoGenerate" decryptionKey="AutoGenerate"
> validation="SHA1"/>
>
> Please note that this means that applications will now share security.
> If this is not what you intend to do then do not make this change. Of
> course if you're having the "problem" then it's because you want to
> share security across applications, right?
>
> -Glen
>
>
> John Kraft <jhkraft@ilstu.edu> wrote in message

news:<bgro3c$djo$1@malachite.ilstu.edu>...

> > Joel Finkel wrote:
> >

> > > I have come into this newsgroup precisely to look for an answer to

this. I

> > > am quite amazed to see this very question! Furthermore, I see a

posting

> > > made a few days later that reports a similar issue: Sucessful

authentication

> > > returns to the login page.
> > >
> > > My situation is that in root, aspx pages authenticate fine (the

login.aspx

> > > form is in the root, as well). But in sub-directories, while the

login.aspx

> > > form is correctly invoked, the redirect returns to the login.aspx

page.

> > > This happens regardless of the presense of a web.config file in the
> > > subdirectory, or the contents of it. I have played around with

variations

> > > for about 3 hours. I have verified that the cookies is being created

and

> > > sent, but for some reason the application in the sub-directory is not

hip to

> > > the fact that this cookie exists, and returns to the login.aspx page.
> > >
> > > Pretty big problem. Hope there is a simple fix.
> > >
> > > Thanks for all suggestions.
> > > -Joel
> > >
> > >
> > > "JTR" <jtrichard@sotasw.com> wrote in message
> > > news:038001c35618$a80ca270$a601280a@phx.gbl...
> > >
> > >>I'm trying to create a structure I can share
> > >>authentication from a root application with many
> > >>subordinate applications (subfolders).
> > >>
> > >>The web.config file for the root has:
> > >>
> > >><authorization>
> > >><allow users="*" />
> > >></authorization>
> > >>
> > >>Then, each subordinate application (subfolder) has a
> > >>web.config with the following:
> > >>
> > >> <authentication mode="Forms">
> > >><forms name=".BUZZARD"
> > >>loginUrl="../login.aspx">
> > >></forms>
> > >> </authentication>
> > >> <authorization>
> > >><deny users="?" />
> > >> </authorization>
> > >>
> > >>When the user access a resource in a subfolder, the login
> > >>form is displayed and authenticates the user correctly,
> > >>including the creation of an authentication ticket. But,
> > >>when the login form attempts to redirect the browser to
> > >>the requested secure resource, the login form is
> > >>redisplayed. I have tried using
> > >>FormsAuthentication.RedirectFromLoginPage() and
> > >>Response.Redirect() with the same results.
> > >>
> > >>Any ideas?
> > >>
> > >>JTR.
> > >
> > >
> > >

> > I was having this problem too. It turned out to not be a problem with
> > the cookie, but with the encryption/decryption of the cookie. Even
> > though the cookie was inside the same project, even though a subfolder,
> > the encryption key is supposed to be the same. It wasn't. I tried
> > manually setting the encryption key in the webconfig. I even tried
> > putting another copy of the same web.config into the subdirectory. For
> > some reason nothing seemed to work. We ended up setting the
> > protection="All" to protection="None" to get around it. We still have
> > not corrected the problem, but if you make that change it might indicate
> > that the problem is not actually with the cookie.
> >
> > John

[Joel Finkel]

Folks,

I have investigated the situation on my configuration a bit more, and have discovered an anomaly. Consider the following structure:

root/admin/secure

login.aspx is in root/admin
secret1.aspx is in root/admin
secret2.aspx is in root/admin/secure

Both secret1.aspx and secret2.aspx are "protected" by login.aspx because there is a Web.config file in root that looks like this:

<configuration>

<location path="admin">
<system.web>

<authorization>
<deny users="?" />
</authorization>

</system.web>
</location>

<system.web>

<identity impersonate="false" />

<authentication mode="Forms">

<forms
name="TESTCOOKIE"
loginUrl="/root/admin/login.aspx"
protection="All"
timeout="30"
slidingExpiration="true"
path="/">

<credentials passwordFormat="MD5" >
<user name="blah" password="0ED5819EAD9C9E11DDF202AE0B2993E4"/>
</credentials>

</forms>
</authentication>

<authorization>
<allow users="*" />
</authorization>

</system.web>

</configuration>

If you insert a call to FormsAuthentication.GetRedirectUrl() in login.aspx and look at the output, you will notice that it returns a slightly different string when login.aspx is called to authenticate secret1.aspx and secret2.aspx. Of course, the URLs are different in that when called from secret2.aspx: it has the suffix, "/secure". The anomaly is that:

for secret1.aspx, it returns: ROOT/admin
for secret2.aspx, it returns: root/admin/secure

This is one of those things that make you go, "Hmmm." If there is THIS anomaly, one wonders what others are to be found.

Joel Finkel
[email]finkel@sd-il.com[/email]




"Glen M" <glen@lfsh.com> wrote in message news:ad561414.0308091953.590148d2@posting.google.c om...

> The solution is in the machine.config file. Under .Net 1.1, there is
> an option to isolate the security used by each application. The
> standard machineKey looks like the following.
>
> <machineKey validationKey="AutoGenerate,IsolateApps"
> decryptionKey="AutoGenerate" validation="SHA1"/>
>
> Under .Net 1.0 there was no option to "IsolateApps". So changing the
> key to the following will fix the problem.
>
> <machineKey validationKey="AutoGenerate" decryptionKey="AutoGenerate"
> validation="SHA1"/>
>
> Please note that this means that applications will now share security.
> If this is not what you intend to do then do not make this change. Of
> course if you're having the "problem" then it's because you want to
> share security across applications, right?
>
> -Glen
>
>
> John Kraft <jhkraft@ilstu.edu> wrote in message news:<bgro3c$djo$1@malachite.ilstu.edu>...

> > Joel Finkel wrote:
> >

> > > I have come into this newsgroup precisely to look for an answer to this. I
> > > am quite amazed to see this very question! Furthermore, I see a posting
> > > made a few days later that reports a similar issue: Sucessful authentication
> > > returns to the login page.
> > >
> > > My situation is that in root, aspx pages authenticate fine (the login.aspx
> > > form is in the root, as well). But in sub-directories, while the login.aspx
> > > form is correctly invoked, the redirect returns to the login.aspx page.
> > > This happens regardless of the presense of a web.config file in the
> > > subdirectory, or the contents of it. I have played around with variations
> > > for about 3 hours. I have verified that the cookies is being created and
> > > sent, but for some reason the application in the sub-directory is not hip to
> > > the fact that this cookie exists, and returns to the login.aspx page.
> > >
> > > Pretty big problem. Hope there is a simple fix.
> > >
> > > Thanks for all suggestions.
> > > -Joel
> > >
> > >
> > > "JTR" <jtrichard@sotasw.com> wrote in message
> > > news:038001c35618$a80ca270$a601280a@phx.gbl...
> > >
> > >>I'm trying to create a structure I can share
> > >>authentication from a root application with many
> > >>subordinate applications (subfolders).
> > >>
> > >>The web.config file for the root has:
> > >>
> > >><authorization>
> > >><allow users="*" />
> > >></authorization>
> > >>
> > >>Then, each subordinate application (subfolder) has a
> > >>web.config with the following:
> > >>
> > >> <authentication mode="Forms">
> > >><forms name=".BUZZARD"
> > >>loginUrl="../login.aspx">
> > >></forms>
> > >> </authentication>
> > >> <authorization>
> > >><deny users="?" />
> > >> </authorization>
> > >>
> > >>When the user access a resource in a subfolder, the login
> > >>form is displayed and authenticates the user correctly,
> > >>including the creation of an authentication ticket. But,
> > >>when the login form attempts to redirect the browser to
> > >>the requested secure resource, the login form is
> > >>redisplayed. I have tried using
> > >>FormsAuthentication.RedirectFromLoginPage() and
> > >>Response.Redirect() with the same results.
> > >>
> > >>Any ideas?
> > >>
> > >>JTR.
> > >
> > >
> > >

> > I was having this problem too. It turned out to not be a problem with
> > the cookie, but with the encryption/decryption of the cookie. Even
> > though the cookie was inside the same project, even though a subfolder,
> > the encryption key is supposed to be the same. It wasn't. I tried
> > manually setting the encryption key in the webconfig. I even tried
> > putting another copy of the same web.config into the subdirectory. For
> > some reason nothing seemed to work. We ended up setting the
> > protection="All" to protection="None" to get around it. We still have
> > not corrected the problem, but if you make that change it might indicate
> > that the problem is not actually with the cookie.
> >
> > John

[Joel Finkel]

John,

Your workaround, to set "protection=none" does, indeed work. This provides
very poor security, however, as the cookies are neither encrypted nor
validated to ensure that they have not been tampered with. I suppose one
way to tighten things up is to use SSL for the authentication code
(login.aspx).

-Joel

> I was having this problem too. It turned out to not be a problem with
> the cookie, but with the encryption/decryption of the cookie. Even
> though the cookie was inside the same project, even though a subfolder,
> the encryption key is supposed to be the same. It wasn't. I tried
> manually setting the encryption key in the webconfig. I even tried
> putting another copy of the same web.config into the subdirectory. For
> some reason nothing seemed to work. We ended up setting the
> protection="All" to protection="None" to get around it. We still have
> not corrected the problem, but if you make that change it might indicate
> that the problem is not actually with the cookie.
>
> John
>