The edulogon development blog

This page describes the basics of how eduLogon does its job.  I don’t reveal everything here, but there is a lot more detail than the layman’s descriptions available on the homepage etc. It’s intended for more technical users that want a better idea what this program is doing with their computer.

When you first start eduLogon, it checks for settings stored in the registry (HKCU/Software/eduLogon). If a particular key (“setup”) is not present and set to 1, it fires up the settings dialog, which allows you to enter your log in credentials and specify other settings. When passwords are entered, they are stored using industry-standard encryption.

Once settings are available, the main thread attaches to Windows notifications of network connectivity changes. These can be anything from a network cable getting unplugged, to a VPN connection getting established, to TCP/IP addressing information updating. It then immediately invokes the handler for this event once, since the program is still just starting up and we may need to authenticate now even though no network changes have occurred since the program was started.

The event handler for changed network connectivity polls all installed network adapters for their associated domain names, checking each against the list of supported domains. Domain membership information is usually provided via DHCP at connection time. The first network adapter it finds that claims to provide a connection to a supported domain causes it to a) stop looking for other supported connected networks (so the agent only supports authentication to one network at a time), and b) start up a second thread, which I will call the “primary thread.” If no network interfaces are currently providing connectivity to any supported networks, the logon agent hides itself from the UI, simply listening in the background for more network connection changes.

Upon starting, the primary thread’s first task is to verify that authentication is necessary. Often it is not, for example if the user started the program after manually authenticating, or if the network keeps users authenticated via MAC address for some time after they disconnect. Verification that authentication must occur is accomplished by starting an additional two new threads, which I will call the “test site threads.” Each test site thread attempts an http connection to (different) sites whose content is known. On many campuses, the result of such a connection attempt when the user is not authenticated is an http redirect to the authentication site. On these campuses, the HEAD method is used in testing to conserve bandwidth and improve response time. On other campuses html/javascript based redirection is used, in which case the entire body of the test sites is requested and analyzed. In either case, both of the test threads are tasked first with fetching the content of their respective pages, and then with determining whether the response is the actual site to which they were attempting to reach, or the institution’s logon redirection. The first thread to accomplish both tasks reports back to the “primary thread,” which has been waiting on the test site threads. The primary thread then aborts the remaining test site thread, and then inspects the result of the test site thread that completed. In the event that both test site threads are unable to reach a determination, the primary thread spawns an error dialog indicating that the current authentication status cannot be determined, and allows the user to elect whether or not to proceed with network authentication. (One case in which both test threads fail to determine authentication status is if no response to the http requests is received because of network connectivity problems – though the test site threads themselves will retry their assigned sites at 5 second intervals 3 times while no response is received.)

If the primary thread gets a test thread reporting back that authentication is necessary, it forms an http POST request including your username and decrypted password, and sends it off via SSL/TLS to the access control and authentication server for your campus, just as your web browser does when you manually log on. The response from this server is searched for key phrases indicating whether or not the logon was successful. If it was successful, the UI notifies the user that they are authenticated. If an error message indicating invalid credentials is in the response, the user may elect to enter new credentials, after which the logon sequence is re-run. Other errors are handled in various ways, but generally include at least one retry of the logon request.

Upon successful (or unrecoverably unsuccessful) logon, eduLogon pages itself out of memory and goes back to listening for network connectivity changes. The user can also manually invoke the entire procedure through the UI.

And that’s about it. Specific test site, logon server, and logon server repsonse information for each supported network/campus is stored in an xml file, most of which is dumped from memory.

The current version supports logging on to networks only, and not logging off. In future I may add code that attempts to de-authenticate/log the user off of the network as they power down/sleep their machine, which potentially does have some real security benefits since I’m sure hardly anyone bothers to do this manually, but under vista this is a bit of a crap shoot, as all processes on the machine get signalled only 2 seconds before a low-power state is assumed, and so the network activities involved with logoff would have to complete within this timeframe. Probably I could usually get a notification to a network control server in this time, even if I wasn’t able to get back & process a reply, but its still not screaming reliability so I’ve back-burnered it for now.