Use the Cloud to Manage License Key Authentication
January 3, 2011
As Access developers begin thinking in terms of "the Cloud", all sorts of possibilities open up. Things that used to be hard, like managing licenses for your home grown software apps, are simplified by employing online database services.
I was recently asked to create an Access application for managing golf tournaments. The objective was to create a shrink-wrapped product that, once purchased, could not be illegally pirated. What follows is the solution I came up with, which implements a centrally located cloud database for managing license subscriptions.
Before I begin with the code, allow me to admit that my approach is not iron clad. I have no doubt it can be defeated. Since the application targets a small, non-technical audience, the idea was to create a system complex enough to discourage illegal installation while providing useful feedback on where and by whom the application was being used.
The code used for this article (download here) was unit-tested but may present minor glitches and is no doubt subject to improvement. It represents my first pass at the problem but it's a good starting point. However, setting up an environment for the demo to work is not a trivial task. It requires the following:
The Process in Overview
The idea is simple but the process quickly became very involved. Below is a high-level view of what the authentication procedure attempts to perform. When the start-up form (frmSplash) is opened and its Timer() event is triggered, the following steps are taken:
The idea is similar to the way Microsoft implements "Activation" for Office. If you're not connected to the Internet, you can use the product without activation for some weeks. If you go online, you can activate the product once and never need to be connected to the Internet again to use the product.
Additionally, the online license database allows for two valid "uses" of the license key. A single table License contains typical user info plus two sets of columns that describe the registrations: Login, Machine and Date. The first time the registration key is used, the first set of columns are populated. The next time the file is opened on an unfamiliar machine or with the incorrect login, a second registration will be required.
This paradigm allows for only two logins but since the license database is "in the cloud", the registrations may be manually reset, much like what happens when you register too many devices with iTunes or Audible.com. If you, as the developer, want to be more generous with activations, the paradigm may be extended.
When the user opens a properly registered MDB file for the second time, the authentication is made, not with the Internet database, but between the local machine attributes (login and computer name) and the properties saved with the file.
The Access properties window, shown below, reveals the custom properties in their initial state. As registrations are activated, these properties are populated. Few developers know these properties exist and fewer yet actually use them. While that's not deterrent, their hidden nature makes them difficult to hack and if the MDB is compiled into an MDE (as it should be), the code that would reveal them becomes obfuscated as well.
At the risk of sounding stupid, I cannot find this property page when using Access 2010. I had to open the mdb in Access 2003 to generate this screen shot. So while not perfectly hidden, these attributes are well buried.
Run the Demo
What you see below in the screen shot is pretty much the entire user interface. The connection form (shown above) is necessary to initialize the license objects to your cloud database, but the end user should neither know of nor have access to this function. Once set, that form and its methods are no longer needed.
The easiest way to understand and debug the process is to set a breakpoint in the Form_Timer() event of frmSplash and step through the code. Roughly speaking, it follows these steps:
Implement in Your Application
To implement this paradigm you will need to import most all objects from the demo database. If you already have a splash form, then simply copy the code in the form's module to your form. Same with the About form, which displays the registration information as it appears in the database properties window.
The other concern would be duplication of API declarations and other functions, should they already exist in your application but those are simple enough to find by forcing a code compile. As I stated at the beginning, this code was unit tested but it could be possible that some condition was missed in the testing. Still, it's a good start if you want to push registration key maintenance to the cloud.