«

I have created a web application that is utilizing Forms Authentication
and URL Authorzation for application security.

The problem arises when an authenticated user (the authentication
ticket cookie has been set) attempts to access a sub directory or file
where I have explicitely denied them access. For example the code in
the root web.config is as follows:

<authentication mode="Forms">
<forms loginUrl="authAgent.aspx"
name="csgOperationsAuthTicket"
protection="All"
timeout="60"
path="/"
/>
</authentication>

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

A web.config created in a protected directory called "protected" has
the following authorization tags:

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

Now if i attempt to visit a page within the "protected" sub directory
the forms authentication ticket is created for the user however if i
attempt to access the directory as any other user but "admin" I do not
get an access denied page or message. Instead it stays at the loginUrl
page (seems to reload over and over). If I do access the directory as
"admin" everything works fine.

Is there a way to display an access denied page to the user?

Note that when I use Windows authentication a nice access denied page
is displayed. If you try to use forms authentication the user is left
hanging. This cannot be by Microsoft's design can it? Is it a bug?

Any insight is *GREATLY* appreciated.

Thanks

Hello ,

Thats IMHO a flaw in FormsAuth - it would be nice to have two redirect URLs
in FormsAuth config - one for login, one for access denied.

What you can do (and that's what the built in module should do) is, check
on your login page if the a valid context.user is associated with the request.


In you login.aspx
If the user is unauthenticated, display login UI - if the user is authenticated
- display access denied.

---------------------------------------
Dominick Baier - DevelopMentor
http://www.leastprivilege.com

> I have created a web application that is utilizing Forms
> Authentication and URL Authorzation for application security.
>
> The problem arises when an authenticated user (the authentication
> ticket cookie has been set) attempts to access a sub directory or file
> where I have explicitely denied them access. For example the code in
> the root web.config is as follows:
>
> <authentication mode="Forms">
> <forms loginUrl="authAgent.aspx"
> name="csgOperationsAuthTicket"
> protection="All"
> timeout="60"
> path="/"
> />
> </authentication>
> <authorization>
> <deny users="?" />
> </authorization>
> A web.config created in a protected directory called "protected" has
> the following authorization tags:
>
> <authorization>
> <allow users="admin" />
> <deny users="*" />
> </authorization>
> Now if i attempt to visit a page within the "protected" sub directory
> the forms authentication ticket is created for the user however if i
> attempt to access the directory as any other user but "admin" I do not
> get an access denied page or message. Instead it stays at the
> loginUrl page (seems to reload over and over). If I do access the
> directory as "admin" everything works fine.
>
> Is there a way to display an access denied page to the user?
>
> Note that when I use Windows authentication a nice access denied page
> is displayed. If you try to use forms authentication the user is left
> hanging. This cannot be by Microsoft's design can it? Is it a bug?
>
> Any insight is *GREATLY* appreciated.
>
> Thanks
>

Hi Dominick thanks for the reply.

The problem is not that I need two redirect URL's the problem is that
when a user who is authenticated tries to access a resource they are
not authorized to access an access denied page is not provided from IIS
(instead it seems to try over and over to reauthenticate and redirect
which results in the endless loop). I notice IIS has an error page
associated with error code 401.7 which is for access denied because of
URL authorization. Why isn't this page shown? Maybe I have to trap
the event when a response of 401.7 goes out and redirect the user to an
appropriate page? This is ridiculous. I can't believe no one has
complained about URL authorization via forms authentication before.
I invite anyone to setup an application with forms auth and restrict
access to a particular folder or resource. Then try to surf to that
url. You will not get an access denied page, instead forms auth will
continually try to reauthenticate you in hopes of gaining new
credentials which will allow you access (this HAS to be a bug)!
Note that when you set all this up and use Integrated Windows
Authentication with URL Authorization, unauthorized users will see a
nice access denied page from IIS.

Again any insight appreciated!

One thing you might consider doing to work around this behavior is
implementing your own HttpModule that handles the EndRequest event, checks
for a 401 status code instead redirects to a custom "Access Denied" page of
your choosing (you would need to exclude this page from authorization via a
location tag or simply have your module set the SkipAuthorization flag for
requests to that page in the BeginRequest event).

That should give you a viable solution with hopefully only about 20 lines of
code.

Joe K.

"jfer" <> wrote in message
news: oups.com...
> Hi Dominick thanks for the reply.
>
> The problem is not that I need two redirect URL's the problem is that
> when a user who is authenticated tries to access a resource they are
> not authorized to access an access denied page is not provided from IIS
> (instead it seems to try over and over to reauthenticate and redirect
> which results in the endless loop). I notice IIS has an error page
> associated with error code 401.7 which is for access denied because of
> URL authorization. Why isn't this page shown? Maybe I have to trap
> the event when a response of 401.7 goes out and redirect the user to an
> appropriate page? This is ridiculous. I can't believe no one has
> complained about URL authorization via forms authentication before.
> I invite anyone to setup an application with forms auth and restrict
> access to a particular folder or resource. Then try to surf to that
> url. You will not get an access denied page, instead forms auth will
> continually try to reauthenticate you in hopes of gaining new
> credentials which will allow you access (this HAS to be a bug)!
> Note that when you set all this up and use Integrated Windows
> Authentication with URL Authorization, unauthorized users will see a
> nice access denied page from IIS.
>
> Again any insight appreciated!
>

Interesting advice Joe thank you very much. Do you have any articles
on this subject to help me begin an implementation?
Also are you SURE you can trap a 401* error? I could of swore I read
others trying to trap 401 errors in the forums in the past and saying
it would not work although they could successfully trap a 404 error.
Any thoughts?

You can handle the 401 in EndRequest if the 401 was generated by the
UrlAuthorizationModule. You can't if it was handled by IIS as the request
will never get to ASP.NET.

All the UrlAuthorizationModule does is checks the access of the user and if
it fails, sets status to 401 and calls CompleteRequest which short circuits
the event pipeline to the EndRequest method. This is nice because if it had
called Response.End, the response would have been aborted right there.
However, the UrlAuthorizationModule does its work politely and gives you one
last chance at the request.

Here is some VB.NET code that I modified from an actual thing we wrote that
does something similar. I didn't test this version, but you get the idea.
This would basically be the gut of an IHttpModule, although you could do
something similar in Global.asax:

Public Sub Init(ByVal context As System.Web.HttpApplication) _
Implements System.Web.IHttpModule.Init

AddHandler context.EndRequest, AddressOf HandleComplete
End Sub

Private Sub HandleComplete(ByVal sender As Object, ByVal e As EventArgs)
Dim application As HttpApplication
application = DirectCast(sender, HttpApplication)

If application.Context.Response.StatusCode = 401 Then
application.Context.Response.StatusCode = 200
application.Context.Response.Clear()
application.Context.Response.Write("Access Denied")
application.Context.Response.Flush()
End If
End Sub

In your code you might wish to redirect or at least render some valid HTML
, but you get the idea.

HTH,

Joe K.

"jfer" <> wrote in message
news: oups.com...
> Interesting advice Joe thank you very much. Do you have any articles
> on this subject to help me begin an implementation?
> Also are you SURE you can trap a 401* error? I could of swore I read
> others trying to trap 401 errors in the forums in the past and saying
> it would not work although they could successfully trap a 404 error.
> Any thoughts?
>

Wow thank you so much for the help Joe!! I am going to try and
implement this tonight.

I notice in your code above you are trapping ALL 401 errors. Is there
any way I can get at that sub status code? What I mean is I noticed
there are two sub status codes of the 401 errors that IIS can throw in
relation to access denied becase of a URL Authorization denial. I
believe one of the subcodes is 401.7. Again your insight is
appreciated.

Thanks again!!

If you look at the source for the UrlAuthorizationModule (using .NET
Reflector to reverse compile it is especially helpful here), you'll notice
that it just sets the status to 401. I'm guessing that IIS sets the
substatus on the way back out of the IIS pipeline but ASP.NET does not, so
it won't be set by the time your code gets to it.

Also, remember that this will only catch 401 errors generated by .NET code
in the ASP.NET pipeline. If IIS rejects the request for some reason, none
of this code will likely even get executed. Therefore, as long as you are
reasonably certain that only the UrlAuthorizationModule will be setting 401
status codes from .NET, you can be relatively sure that is a fair indicator.

However, in examining this a little further, I noticed that there is one
hitch. The FormsAuthenticationModule ALSO handles the EndRequest event and
checks for the 401 response code too. Since it is probably loaded in the
list of modules before you code, it will likely execute first and beat your
code to the punch.

As such, you may need to "reorder" the list of modules and place yours first
by removing the forms auth module, adding yours and then re-adding forms
auth. I'd also suggest taking a look via Reflector at exactly what
FormsAuth is doing in EndRequest so you can understand what it is up to
better.

HTH,

Joe K.

"jfer" <> wrote in message
news: oups.com...
> Wow thank you so much for the help Joe!! I am going to try and
> implement this tonight.
>
> I notice in your code above you are trapping ALL 401 errors. Is there
> any way I can get at that sub status code? What I mean is I noticed
> there are two sub status codes of the 401 errors that IIS can throw in
> relation to access denied becase of a URL Authorization denial. I
> believe one of the subcodes is 401.7. Again your insight is
> appreciated.
>
> Thanks again!!
>

This ordering is done in machine.config correct? Can I reorder inside
web.config so as to only change the ordering for the application where
I need this functionality?

Just out of curiousity why is it that that UrlAuthorization module
doesn't automatically send the user to an appropriate page or deliver
an access denied message? Seems odd that by design microsoft set this
up so that when an authenticated user tries to access a resource they
are not authorized to access that it redirects them back to the
loginURL page specified in the web.config for forms authentication.
This results in an endless loop of redirection until the redirectURL
becomes larger than some browser setting where it finally "dies" for
lack of a better term. I'm glad you offered your insight on this as
most people attribute my problem to something misconfigured in my forms
authentication. Due to the lack of internet discussion out there with
my problem it makes me wonder how many people out there are actually
utilizing URL Authorization with Forms Authentication. You would think
after several years of this being available someone would of stumbled
upon this problem. I had to search mercilessly over the net for
similar discussion, and even then was very minimal discussion.

Your help will assist those in the future I'm sure.

Thanks!

You can reorder in web.config although the original list is set in
machine.config. Just use the remove element in conjunction with the add
element. The documentation for the syntax is in the MSDN documentation
somewhere under config file schema for ASP.NET.

I have no idea what the motivation for the original MS design was.
Additionally, I make no warranty that my solution will not break some other
scenario that we are not considering. Please test carefully.

Best of luck,

Joe K.

"jfer" <> wrote in message
news: oups.com...
> This ordering is done in machine.config correct? Can I reorder inside
> web.config so as to only change the ordering for the application where
> I need this functionality?
>
> Just out of curiousity why is it that that UrlAuthorization module
> doesn't automatically send the user to an appropriate page or deliver
> an access denied message? Seems odd that by design microsoft set this
> up so that when an authenticated user tries to access a resource they
> are not authorized to access that it redirects them back to the
> loginURL page specified in the web.config for forms authentication.
> This results in an endless loop of redirection until the redirectURL
> becomes larger than some browser setting where it finally "dies" for
> lack of a better term. I'm glad you offered your insight on this as
> most people attribute my problem to something misconfigured in my forms
> authentication. Due to the lack of internet discussion out there with
> my problem it makes me wonder how many people out there are actually
> utilizing URL Authorization with Forms Authentication. You would think
> after several years of this being available someone would of stumbled
> upon this problem. I had to search mercilessly over the net for
> similar discussion, and even then was very minimal discussion.
>
> Your help will assist those in the future I'm sure.
>
> Thanks!
>