CustomAuth.cpp Get User Info and Decode It

GetUserInfoAndUpdateCookie

This function pulls the user information out of the cookie. It parses out the credentials from the cookie and passes them along to the DecodeAndDecryptCredentials function. In return, it gets the plain username and password, and uses those to log the user into the server.

The LogonUser function used essentially logs the user in the same as Basic authentication. So anything you might have been doing with Basic authentication you should be able to do with this, and then some.

Then the user information is set along with the token used for impersonation.

DecodeAndDecryptCredentials

This is the function where you would put your decryption code. That is, if you encrypted the credentials in the first place, which I HIGHLY suggest you do.

The login page I used was a ASP.NET page, so I used encryption that could be encoded/decoded in both .NET and C++.

CustomAuth.cpp Logon/Logoff

ProcessLogon

The first part of this function checks for the login cookie. It does not do any verification of the data in the cookie here, only that it exists, because if the data was not verified, the cookie would be deleted elsewhere.

If the cookie exists, then we set the url that the user will be directed to now that they have logged in. This is where the DEFAULT_USE_SUCCESS_URL information could be used, but I’m not going to go into that.

Then the user is redirected with a 302 response to the successful login page specified with a Location header.

ProcessLogoff

This is what I used to get all of my debugging information while I was learning. By using the built-in logoff page, I could insert information from elsewhere in the filter to the logoff page.

If using the built-in logoff page, then a 200 response is sent while printing out the logoff page to the Response Buffer. During this process, I would print out the content of the g_userName variable, which could have anything from seeing if HTTPS was enabled, to the actual username (which is why the variable is named that, I just never changed it), to seeing if any variables are holding the information you expect.

Otherwise, the user is given a 302 response and redirected to the logoff page defined in the .ini file.

Then, the login cookie is deleted. The cookie is what is used to log the user in or allow them to be logged in automatically the next time they visit the site. Removing the cookie will not log them out of the server, but will prevent them from automatically logging in next time.

CustomAuth.cpp

These next few posts I’m going to discuss the changes between the original CustomAuth.cpp and the version I modified. I’m only going to talk about the changes I made and talk about 1-2 functions in each post. If a function is in the code but I don’t talk about it, then it wasn’t changed, is fairly simple, and can be figured out while looking at the code. Besides, Microsoft/people who wrote the code did a great job with comments.

HttpExtensionProc

This function is the entry point of the filter where all the commands are given. It is the entry point for IIS and decides what to do with each request.

First, the function checks to see if authentication has already taken place and passes the request along. It also grabs the url for use later on. Then it checks to see if it is a Logon or Logoff request and passes to request to each appropriate function for handling, ProcessLogon or ProcessLogoff. If we are using the built-in login page, then it checks for that and passes the request to the SendBuiltinLogonPage function where the login page will be returned.

Now, if nothing else has been done, then we check for the login cookie. If the cookie is found, then an attempt is made to log out the user from the server. If that was successful, then the credentials are pulled from the cookie with the GetUserInfoAndUpdateCookie function. The user is then logged into the server, the cookie and user information is cleared, and the request is passed along. If a cookie is found, the user is logged off of the server to make sure their credentials are correct.

After any processing, the request is then passed along for IIS to handle like any other request.