2 More detail
source | link

Use a local digitally signed license file encoding business rules

I've split my answer to cover generally accepted requirements, a matching business strategy and the technical aspects of the problem.

General requirements

Few things annoy users more than having their work interrupted as a result of a license issue. To that end you want to have a system that:

  • is resilient against network and hardware failure (no single point of failure)
  • scales well (new servers and more users arrive as the business grows)
  • is resilient against forgery of licenses
  • warns administrators when they are approaching the limits of their license
  • doesn't ever present a false positive (if unsure allow access is the rule for customer-friendly licensing behaviour)

to name but a few design requirements.

Business strategy

Your company will want total control over the license, otherwise the customer will manipulate the values to their advantage. However, the customer will not want your company looking over their shoulder and so the system will need to be self-contained on their site.

The customer will not want their entire system to fail if a license is unable to be verified. This obvious demand rules out a networked cental authentication approach because it could fail for a multitude of reasons (network, poor coding, power outage, hardware failure etc). While the central license authenticator is being repaired (could be days to get that done) the customer is unable to do anything - totally unacceptable.

With the above in mind, the strategy to keep your customer happy is to take a bit of a hit in terms of maintenance by using a local license file containing the rules for the given server.

Technical implementation

To achieve that goal, and minimise the hit, I would suggest that you will need to do the following:

  1. Write a license configuration tool for your company. This file defines the user limit, allowed functions, and user types for each product in the form of a digitally signed license file issued by your company using a private key.

  2. The servers must load the license file and verify the digital signature using your public key which is hosted on a well-known public key site (pgp.mit.edu) or embedded directly in the code on startup or after maintenance

  3. Each server verifies it's current user load, type and tasks against the signed license file as traffic occurs. Loading approaching the limit of the license should trigger an email or message to the system administrators.

  4. Servers can update their license file in response to a socket-based PUT request that has a suitable digital signature (again verified by the remote key site). This will allow an automated script to provide license changes when one of your guys is on site providing maintenance.

Use a local digitally signed license file encoding business rules

Few things annoy users more than having their work interrupted as a result of a license issue. To that end you want to have a system that:

  • is resilient against network failure (no single point of failure)
  • scales well (new servers and more users arrive as the business grows)
  • is resilient against forgery of licenses
  • warns administrators when they are approaching the limits of their license
  • doesn't ever present a false positive (if unsure allow access is the rule for customer-friendly licensing behaviour)

to name but a few design requirements.

To achieve that goal I would suggest that you will need to do the following:

  1. Write a license configuration tool for your company. This file defines the user limit, allowed functions, and user types for each product in the form of a digitally signed license file issued by your company using a private key.

  2. The servers must load the license file and verify the digital signature using your public key which is hosted on a well-known public key site (pgp.mit.edu) or embedded directly in the code on startup or after maintenance

  3. Each server verifies it's current user load, type and tasks against the signed license file as traffic occurs. Loading approaching the limit of the license should trigger an email or message to the system administrators.

  4. Servers can update their license file in response to a socket-based PUT request that has a suitable digital signature (again verified by the remote key site). This will allow an automated script to provide license changes when one of your guys is on site providing maintenance.

Use a local digitally signed license file encoding business rules

I've split my answer to cover generally accepted requirements, a matching business strategy and the technical aspects of the problem.

General requirements

Few things annoy users more than having their work interrupted as a result of a license issue. To that end you want to have a system that:

  • is resilient against network and hardware failure (no single point of failure)
  • scales well (new servers and more users arrive as the business grows)
  • is resilient against forgery of licenses
  • warns administrators when they are approaching the limits of their license
  • doesn't ever present a false positive (if unsure allow access is the rule for customer-friendly licensing behaviour)

to name but a few.

Business strategy

Your company will want total control over the license, otherwise the customer will manipulate the values to their advantage. However, the customer will not want your company looking over their shoulder and so the system will need to be self-contained on their site.

The customer will not want their entire system to fail if a license is unable to be verified. This obvious demand rules out a networked cental authentication approach because it could fail for a multitude of reasons (network, poor coding, power outage, hardware failure etc). While the central license authenticator is being repaired (could be days to get that done) the customer is unable to do anything - totally unacceptable.

With the above in mind, the strategy to keep your customer happy is to take a bit of a hit in terms of maintenance by using a local license file containing the rules for the given server.

Technical implementation

To achieve that goal, and minimise the hit, I would suggest that you will need to do the following:

  1. Write a license configuration tool for your company. This file defines the user limit, allowed functions, and user types for each product in the form of a digitally signed license file issued by your company using a private key.

  2. The servers must load the license file and verify the digital signature using your public key which is hosted on a well-known public key site (pgp.mit.edu) or embedded directly in the code on startup or after maintenance

  3. Each server verifies it's current user load, type and tasks against the signed license file as traffic occurs. Loading approaching the limit of the license should trigger an email or message to the system administrators.

  4. Servers can update their license file in response to a socket-based PUT request that has a suitable digital signature (again verified by the remote key site). This will allow an automated script to provide license changes when one of your guys is on site providing maintenance.

1
source | link

Use a local digitally signed license file encoding business rules

Few things annoy users more than having their work interrupted as a result of a license issue. To that end you want to have a system that:

  • is resilient against network failure (no single point of failure)
  • scales well (new servers and more users arrive as the business grows)
  • is resilient against forgery of licenses
  • warns administrators when they are approaching the limits of their license
  • doesn't ever present a false positive (if unsure allow access is the rule for customer-friendly licensing behaviour)

to name but a few design requirements.

To achieve that goal I would suggest that you will need to do the following:

  1. Write a license configuration tool for your company. This file defines the user limit, allowed functions, and user types for each product in the form of a digitally signed license file issued by your company using a private key.

  2. The servers must load the license file and verify the digital signature using your public key which is hosted on a well-known public key site (pgp.mit.edu) or embedded directly in the code on startup or after maintenance

  3. Each server verifies it's current user load, type and tasks against the signed license file as traffic occurs. Loading approaching the limit of the license should trigger an email or message to the system administrators.

  4. Servers can update their license file in response to a socket-based PUT request that has a suitable digital signature (again verified by the remote key site). This will allow an automated script to provide license changes when one of your guys is on site providing maintenance.