Forms Authentication to protect a cgi application

[Stephen Davies]

I have enabled forms authentication on an IIS 6 W2k3 server to protect access
to the application files until authenticated.

The actual application apart from the login/logout files is .cgi based so I
have added a “Wildcard Application Map†entry

site properties
home directory tab
Configuration
Application Configuration

to point to the “aspnet_isapi.dll†so that .cgi application files must be
authenticated before they can run.

So far all seems to be working well, direct invocation of the .cgi
application is trapped and redirected to the login screen but after logging
in I am prompted with a download dialog (as if there were no mime type)

1. If I remove the Wildcard Application Mapping the .cgi application runs
2. If I allow users=â€*†in the authorization section of the web config (with
the wildcard application mapping in place) it also works perfectly.

On top of this I also have an httphandler routine to perform a URLRewrite to
catch the application logout command, although the symptoms above are exactly
the same when its removed from the web config.

Any help on this would be greatly appreciated.

Regards
Stephen Davies

 

[[MSFT]]

Hello Stephen,

How did you redirect from the logon form to the CGI file? If you code like:

Response.Redirect

or

Server.Transfer

Will it get work?

Luke

 

[Stephen Davies]

Hi Luke

I am using Response.Redirect and example would be

Response.Redirect("urchin/session.cgi?action=login&user=" + tbUserName.Text);

The next dialog is asking me where to save “session.cgi†seems IIS does not
know what to do with it. The saved file (as expected) is the session.cgi
executable.

As soon as I remove the Wildcard application mapping the cgi is executed
perfectly. I have tried specific .cgi application mapping rather than the
wildcard, same problem!

-----------------------------------------------------------------
In response to your question I tried Server.Transfer with the same URL as
the Response.Redirect and get the following

Error executing child request for urchin/session.cgi.
[HttpException (0x80004005): Error executing child request for
urchin/session.cgi.]
System.Web.HttpServerUtility.ExecuteInternal(String path, TextWriter
writer, Boolean preserveForm) +1773
System.Web.HttpServerUtility.Transfer(String path, Boolean preserveForm)
+24
_dayUrchin.loginAdmin.Login_Click(Object sender, EventArgs e) in
d:\development\urchin\loginadmin.aspx.cs:60
System.Web.UI.WebControls.Button.OnClick(EventArgs e) +108

System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +57
System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler
sourceControl, String eventArgument) +18
System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +33
System.Web.UI.Page.ProcessRequestMain() +1262

I let the second parameter default as well as testing true and false, all
with exactly the same response. Server Transfer produces this exception with
and without the wildcard application mapping.

Steve

 

[Patrick Olurotimi Ige]

Try going through this article at:-
http://www.microsoft.com/india/msdn/articles/57.aspx
Can u try posting some more code since u are using some string.
*Guess there must be a workaround!

 

[Stephen Davies]

Patrick

I had already seen the httpmodules document thanks, I used these to create
the http module originally, it has no bearing on the problem at hand. Same
symptoms installed and uninstalled.

Don't think posting the code would help as its simply constructing a URL for
the Response.Redirect i.e. "urchin/session.cgi?action=login&user=steve".

On top of that I don't think its the response redirect that's the issue here
it's the passing of the .cgi through the IIS "Wildcard Appplication Mapping"
to the dotnet ISAPI "aspnet_isapi.dll" so that the .cgi can partisipate in
the forms authentication process that’s the issue. Same problem is
experienced by deleting the wildcard mapping and pointing to the dot net
isapi via the .cgi extension.

Steve

 

[[MSFT]]

Hi Steve,

It seems ASP.NET's default HttpHandler didn't recognize the CGI extension,
You may need to add a httphandler for CGI like:

<httpHandlers>

<add verb="*" path="*.cgi"
type="System.Web.HttpForbiddenHandler"/>


Luke

 

[Stephen Davies]

Hi Luke

I don't want to block .cgi, I want to RUN them (once Forms Authenticated).

I have removed any reference to my "httpModules" entry for URL rewriting to
eliminate it completly from the problem.

Simply the issue is when I add the “aspnet_isapi.dll†to the "Wildcard
application mapping" front ending all requests (including .cgi) then it seems
the mime type is NOT honoured and I am requested with a prompt to save the
cgi executable locally (rather than run it and present me with the output).

Instructions outlined in the section "Edit Script Mappings in Internet
Services Manager" on this page:
http://support.microsoft.com/kb/815152/EN-US

I am not adding additional httpModules, httpHandlers
I have Forms Authentication ON
Same problem with auth set to Allow users=â€*†as with Deny users=â€?â€

If I remove the “Wildcard Application Mapping†(or an Application Mappingâ€
on .cgi) the problem goes away and the .cgi Mime is honoured and executed.

Regards
Stephen Davies

 

[[MSFT]]

Hi Steve,

HttpForbiddenHandler just block the downloading, not executing. For
example, .ASP aslo used this handler and be executed by asp.exe. In your
system, what is the program that will use .cgi file on web server?

Luke

 

[Stephen Davies]

Hi Luke

That wasn't how I read it, but I tried it as you suggested. The program I am
trying to use is Urchin web reporting which is implemented using .cgi
programs.

Server Error in '/' Application
--------------------------------------------------------------------------------
This type of page is not served.
Description: The type of page you have requested is not served because it
has been explicitly forbidden. The extension '.cgi' may be incorrect. Please
review the URL below and make sure that it is spelled correctly.

Requested Url: /urchin/report.cg
--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:1.1.4322.2032; ASP.NET
Version:1.1.4322.2032


Exactly the same message if I change the extension to .aspx like you
referred to

Server Error in '/' Application
--------------------------------------------------------------------------------
This type of page is not served.
Description: The type of page you have requested is not served because it
has been explicitly forbidden. The extension '.aspx' may be incorrect. Please
review the URL below and make sure that it is spelled correctly.

Requested Url: /default.asp
--------------------------------------------------------------------------------
Version Information: Microsoft .NET Framework Version:1.1.4322.2032; ASP.NET
Version:1.1.4322.2032

You might want to re research this. As I said before the http
modules/handlers are not the issue here, in fact I don't have any implemented
when the problem is present.

Regards
Stephen Davies

 

[Steve Schuler]

Unfortunately, I believe you are probably SOL with your preferred approach.
Here's a link to a thread I was researching a while back on a different
Wildcard usage (URL Authorization), but it has a bearing on this issue:
http://groups-beta.google.com/group...01090736.76126185%40posting.google.com&rnum=1

Note the first response from Wade Hilmo of MS.

It's a lot more work than what you wanted, and adds layers of ASP.NET
overhead on top of the CGI processing, but you could probably still use
ASP.NET forms authentication if you created your own handler that used
Platform Invoke to launch the CGI via CreateProcess.

Probably not the answer you were after... :-(

 

[Stephen Davies]

Thanks for the pointer Steve

That looks like the issue here

Snipped from Wade A. Hilmo's post
I believe that an ISAPI is your only alternative, for exactly the reasons
that you state below. ASP.NET does not utilize HSE_REQ_EXEC_URL,
so if you set up a wildcard mapping for it, there is no way to get the
request back out of the managed code environment.

Darn, there is always a catch....

I don't suppose there is any way I can confirm that authorisation has been
processed from within the ISAPI, I know its unmanaged but I presence of the
session cookie from the System.Web.Security.FormsAuthentication methods might
do the trick. Its just how can I at lest retrieve the cookie from the cookies
collection (in the ISAPI) and ideally decode the cookie? (this might be
pushing it though!)

The only other (a bit dodgy though) method I can think of is to provide my
own hashed token as a querystring variable to be verified and redirected by
the ISAPI extension (to either the login page or the cgi) accordingly.

Any pointer on this would be appreciated.

Regards
Stephen Davies

 

[Stephen Davies]

Thanks for the pointer Steve

That looks like the issue here

Snipped from Wade A. Hilmo's post
I believe that an ISAPI is your only alternative, for exactly the reasons
that you state below. ASP.NET does not utilize HSE_REQ_EXEC_URL,
so if you set up a wildcard mapping for it, there is no way to get the
request back out of the managed code environment.

Darn, there is always a catch....

I don't suppose there is any way I can confirm that authorisation has been
processed from within the ISAPI, I know its unmanaged but I presence of the
session cookie from the System.Web.Security.FormsAuthentication methods might
do the trick. Its just how can I at lest retrieve the cookie from the cookies
collection (in the ISAPI) and ideally decode the cookie? (this might be
pushing it though!)

The only other (a bit dodgy though) method I can think of is to provide my
own hashed token as a querystring variable to be verified and redirected by
the ISAPI extension (to either the login page or the cgi) accordingly.

I will start on this now, any pointer on this would be appreciated.

Regards
Stephen Davies

 

[Steve Schuler]

I'm not sure which ISAPI you're talking about? In the post from Wade Hilmo,
the suggestion was to write an ISAPI that would do the forms authentication,
rather than relying on ASP.NET forms auth. Or were you proposing to host an
app domain from the ISAPI in order to use forms auth? I'm not sure that
would be possible because forms auth is probably bolted pretty tightly to
ASP.NET pipeline infrastructure, and in any case, it would probably be more
trouble than simply writing the forms auth stuff yourself in an ISAPI. In
fact there's a CustomAuth sample in the IIS6 resource kit that provides a
great start on that approach.

OTOH, if you can delay a while, supposedly ASP.NET 2.0 on IIS6 can do this.
(I say supposedly, since I've only seen a few mentions of this, and no
official MS documentation or samples.)

Sorry I don't have better news!

--Steve

Thanks for the pointer Steve

That looks like the issue here


Darn, there is always a catch....

I don't suppose there is any way I can confirm that authorisation has been
processed from within the ISAPI, I know its unmanaged but I presence of the
session cookie from the System.Web.Security.FormsAuthentication methods might
do the trick. Its just how can I at lest retrieve the cookie from the cookies
collection (in the ISAPI) and ideally decode the cookie? (this might be
pushing it though!)

The only other (a bit dodgy though) method I can think of is to provide my
own hashed token as a querystring variable to be verified and redirected by
the ISAPI extension (to either the login page or the cgi) accordingly.

Any pointer on this would be appreciated.

Regards
Stephen Davies

http://groups-beta.google.com/group...01090736.76126185%40posting.google.com&rnum=1

[snip]

 

[Stephen Davies]

My response was based on some digging around where I found people were having
problems getting hold of cookie information from within the ISAPI. I was
imagining d retaining forms authentication and only processing .cgi only with
the ISAPI confirming the existence of the session cookie (and confirming its
a session cookie). That’s what ideally I would have liked a cut and paste
example.... humm.

I am leaning towards encrypted token which can be parsed from the forms
authentication redirect and processed by the ISAPI and if not verified
redirect to the Forms Authentication login page.

I took a look at the IIS6 resource kit but no source supplied urggg. The
CustomAuth example is dll and help only, I have some specific authorisation
requirements that negate the use of the example dll.

Thanks again
Regards Stephen Davies

I'm not sure which ISAPI you're talking about? In the post from Wade Hilmo,
the suggestion was to write an ISAPI that would do the forms authentication,
rather than relying on ASP.NET forms auth. Or were you proposing to host an
app domain from the ISAPI in order to use forms auth? I'm not sure that
would be possible because forms auth is probably bolted pretty tightly to
ASP.NET pipeline infrastructure, and in any case, it would probably be more
trouble than simply writing the forms auth stuff yourself in an ISAPI. In
fact there's a CustomAuth sample in the IIS6 resource kit that provides a
great start on that approach.

OTOH, if you can delay a while, supposedly ASP.NET 2.0 on IIS6 can do this.
(I say supposedly, since I've only seen a few mentions of this, and no
official MS documentation or samples.)

Sorry I don't have better news!

--Steve

Thanks for the pointer Steve

That looks like the issue here


Darn, there is always a catch....

I don't suppose there is any way I can confirm that authorisation has been
processed from within the ISAPI, I know its unmanaged but I presence of the
session cookie from the System.Web.Security.FormsAuthentication methods might
do the trick. Its just how can I at lest retrieve the cookie from the cookies
collection (in the ISAPI) and ideally decode the cookie? (this might be
pushing it though!)

The only other (a bit dodgy though) method I can think of is to provide my
own hashed token as a querystring variable to be verified and redirected by
the ISAPI extension (to either the login page or the cgi) accordingly.

Any pointer on this would be appreciated.

Regards
Stephen Davies

http://groups-beta.google.com/group...01090736.76126185%40posting.google.com&rnum=1

[snip]