Use the Cloud to Manage License Key Authentication

Monday Jan 3rd 2011 by Danny Lesandrini

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.

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:

  1. Download the zip file and extract to a folder
  2. Run the script, BuildLicenseDB.sql on a SQL Server
  3. Holding the SHIFT key, open the file License Demo.mdb
  4. If you are on a 32 Bit Machine, it should run correctly
    If not, you'll need to edit the basAPI declarations as shown below.
  5. Finally, open frmConnect to reset the object connect strings
    (use your own server login credentials)

Comment out the appropriate API declarations
Comment out the appropriate API declarations

Run the connection-refresh form, frmConnect
Run the connection-refresh form, frmConnect

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:

  • Custom database file properties are read (Key, Machine, Login, Date)
  • Properties are validated against the computer name and user login
  • A test is made to see if a Trial period was started and/or is expired
  • Failure of either of these, or a missing key triggers the Product Registration
  • Supplying a valid key updates the file properties for future logins

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.

the online license database allows for two valid

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.

The Access properties window

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 entire user interface

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:

  1. If previous license registration matches Login and Computer, open app
  2. If in TRIAL mode and not expired, open app, otherwise force registration
  3. If not connected to the Internet, registration cannot proceed ... exit app
  4. If user-supplied KEY is supplied
    1. Check against cloud database to verify it's valid
    2. Check to see if Licence 01 location is available
    3. Check to see if License 02 location is available
  1. If a registration is available, open app with SUCCESS. Otherwise, exit app.

Registration Success

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.

Additional Resources

Internet.com Cloud Computing Showcase

» See All Articles by Columnist Danny Lesandrini

Mobile Site | Full Site