CustomAuth Overview

Since there is already an excellent overview for the original CustomAuth, I’m not going to re-invent the wheel. However, that overview is in a help file for CustomAuth on Windows Server 2003 and I could not find it anywhere on the web. So for the purpose of sharing that useful information to as many people as possible, I have taken that overview and put it into a word doc. This information will be skipping ahead of what I’m going to discuss in this post, but most of it is relevant.

CustomAuth Documentation

So after reading the initial documentation above, you should have a general understanding of the original purpose of the original CustomAuth.

The way CustomAuth works is based on denied permissions to access a file on a web server. When someone that is not authenticated tries to access a webpage, they access the page’s physical file using the anonymous user account (IUSR_*). This authentication method denies access to that page for the anonymous user, thus throwing a 401 denied access error response. Since CustomAuth is actually two parts, an ISAPI Filter and an ISAPI Extension, the filter portion is what catches this 401. The filter sees that this error was thrown and replaces that response to the user with a 302 redirection response to the login page, which is set in the CustomAuth.ini file.

One of the modifications added to the CustomAuth filter is the ability for redirection back to the original page trying to be accessed. This is done by adding the original url as a querystring variable added on to the login page url. So instead of just redirection to www.domain.com, we instead redirect to www.domain.com?url=www.domain.com/stuff/page.aspx. Then the login page can take that url and redirect to it instead of the normal login success url defined in the CustomAuth.ini file.

So the filter portion has redirected the user to the login page. The login page will take the user’s credentials and put them into a cookie. Normally the credentials would be in cleartext and each time the server reads the cookie it would be in cleartext. Using SSL is suggested, which with CustomAuth, SSL can be used while giving the functionality of Basic authentication. I suggest using some form of encryption along with SSL, which will provide more security, however you will need encryption that can be decrypted inside the filter which is written in C++.

Once the user logs in and the cookie is created, the ISAPI extension checks for the cookie and pulls the credentials from it. It then attempts to log the user into the server with those credentials. If the login fails, the user is redirected back to the login page. If the login was successful, the user is redirected to the login success page or the original page they were trying to access. Now any file the user has ACL read access to can be viewed, since they are no longer using the anonymous user credentials but their own ACL permissions. Additional permission restrictions can be applied to the user inside the website code as well, so instead of permission being granted or denied based on ACL permissions, they are instead given or denied based on a user group or database entry.

Since the credentials are stored in a cookie, the user will no longer need to login as long as that cookie persists. Also, if the cookie is setup with a specified domain, such as .domain.com, any subdomain that has the CustomAuth filter installed on it will automatically log the user in as well. So if two websites have the filter installed, books.domain.com and cooking.domain.com, if the user logs into one of the sites, they will automatically be logged into the other if they visit it.

Now the user can also log out of the server with CustomAuth. A simple link needs to be provided that the user can click and log off. When the user logs off, they will be redirected to a specified log off page set in the CustomAuth.ini file.

This was a very basic overview of CustomAuth and the modified CustomAuth on the flow of how it works. There is alot missing here, but hopefully it will give an idea of the general steps involved in this authentication process. More to come.

Leave a Reply

You must be logged in to post a comment.