By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,847 Members | 2,354 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,847 IT Pros & Developers. It's quick & easy.

ASP.NET and custom ISAPI filter authentication

P: n/a
We have an existing ISAPI filter that performs authentication for all pages
on our web site, including pages we are now writing for ASP.NET. The filter
is pretty basic, receiving the user name and password in clear text and
checking them against a database of users. The filter has been in use for
some time with classic ASP pages.

From classic ASP pages, the application can retrieve the login name that the
user entered from Request.ServerVariables("AUTH_USER"), which I assume
simply parses the http Authorization header. The account used by the
authentication filter for impersonation can be retreived using
Request.ServerVariables("LOGON_USER").

The problem we are running into with ASP.NET is that no matter what
authentication mode we set in the Web.Config file (Windows or None), we are
having problems accessing the login name entered by the user.
Request.ServerVariables("AUTH_USER") will always return blank, and
IIdentity.Name will either be blank or will contain the name of the
impersonation account.

We were planning on writing our own implementation of the IPrincipal and
IIdentity interfaces so that we can set the IIdentity.Name property
correctly, but I am trying to figure which authorization mode is correct and
how we should extract the login name entered by the user. I would prefer to
not parse the http headers in our code just to extract the login name, but I
can't find any other way to do it.

Any suggestions?

TIA

MJS
Nov 17 '05 #1
Share this Question
Share on Google+
1 Reply


P: 1
I have the exact same problem and I am considering what to do.
I don't have a clean solution, but as a workaround I am thinking of doing something like this:

1. In Global.asax in Session_Start check Session for some value like say "REAL_USER_NAME"

2. If it is not there then do a redirect to a *.asp page that will pick up AUTH_USER server variable (that does actuall have the value I want since it is a normal ASP page and not ASP.NET)

3. Pass the value you got in the *.asp page to an *.aspx page in the query string and that *.aspx page can put it in the Session object

4. Redirect from the *.aspx page above to the page that originally started the mess.

This will create an overhead at the session start and does not look very elegant.
Hope somebody has a better idea.

We have an existing ISAPI filter that performs authentication for all pages
on our web site, including pages we are now writing for ASP.NET. The filter
is pretty basic, receiving the user name and password in clear text and
checking them against a database of users. The filter has been in use for
some time with classic ASP pages.

From classic ASP pages, the application can retrieve the login name that the
user entered from Request.ServerVariables("AUTH_USER"), which I assume
simply parses the http Authorization header. The account used by the
authentication filter for impersonation can be retreived using
Request.ServerVariables("LOGON_USER").

The problem we are running into with ASP.NET is that no matter what
authentication mode we set in the Web.Config file (Windows or None), we are
having problems accessing the login name entered by the user.
Request.ServerVariables("AUTH_USER") will always return blank, and
IIdentity.Name will either be blank or will contain the name of the
impersonation account.

We were planning on writing our own implementation of the IPrincipal and
IIdentity interfaces so that we can set the IIdentity.Name property
correctly, but I am trying to figure which authorization mode is correct and
how we should extract the login name entered by the user. I would prefer to
not parse the http headers in our code just to extract the login name, but I
can't find any other way to do it.

Any suggestions?

TIA

MJS
Mar 24 '06 #2

This discussion thread is closed

Replies have been disabled for this discussion.