Overview – Heirloom Computing

Introduction

The Heirloom Computing Licensing-as-a-Service (LaaS) subsystem is used to manage and control users, products and licenses of those products for the users to applications that are running under public or private clouds. If your are an ISV that is transitioning from traditional deployment of your applications at your customer locations to a Software-as-a-Service (SaaS) model using Heirloom, you can use LaaS to manage your users by product type, CPU cores hours, or micro-transaction licensing models.

You modify your application to make API calls or REST Web services to check licenses, upload transaction (usage) counts on your products or its features. As an administrator, you manage the users, products, and license for your users.

The system consists of Web services issued against a LaaS server. The LaaS server's Administration Interface it the high-level interface to license objects which control products, licenses customers and their restrictions. The Admin Portal, Web services API and command line interface (CLI) together provide a flexible set of ways to interface to the licensing server. Key features:

Server-based license management -- nothing other than a file containing identifying information is present on the client machines
Auditable transaction counts on licensed products; queued to be sent when networks are available
Limit users to specific locations (IP or MAC addresses)
Restrict products to specific numbers of locations
Track transaction counts of each license
Operate in either online (connected to the Internet) or offline (validation through proxy checkers) mode
License "expiration" as well as "grace period"
License management (checking, transaction uploads) through a proxy machine
A Java JAR API to invoke the license checking Web service programmatically
A CLI to create the subscription file for users, carry out proxy operations, or issue license checking commands
Revocation and renewal of licenses are performed on the LaaS server and do not require an "install" or "uninstall" on the client machines

LaaS is available as a subsystem under an Heirloom instance. You Power On and Power Off your LaaS instance from the Heirloom Portal at paas.heirloomcomputing.com. Backups and restores are controlled from this environment as well. This is your "License Server" and accepts requests from your licensed products 24x7. It is server-based licensing, so no "license keys" are distributed to your customers. You "grant" or "revoke" usage rights to your customers from the License Server.

Object Structure

License and transaction management objects are managed by the license server, the Heirloom cloud instance started with the LaaS application. The LaaS application manages the relationship among 4 different object types that come together to define the licensing criteria:

Customers - defines the e-mail and the unique customer ID, also called a subscription ID, of your customers and administrator accounts used by you to access the system
Products - defines the product (or product feature or subsystem) name and its product ID
Restrictions - defines the restrictions in place for all licenses for this product
Licenses - connects Customers, Products and Restrictions for a particular

Each instance of an object has a globally-unique identifier (GUID) associated with it. When licenses are checked the transaction logs are kept as a 5th object:

LogLicense - audit trail of license checks over time

The relationship is this: Customers are defined as are Products (which may be interpreted as product features, subsystems, or any item for which individual transaction records must be recognized). Restrictions may be defined with a name and several attributes which will be checked against the license by the user.

Customer Attributes

This defines primarily your customers of your products, or at least the "contact person" within your customer's organization. There is also defined at least on user with superadmin authority. This is not shared with your customers (and probably has no licenses granted to it) but is able to carry out any operation on the Admin Portal. You may optionally define a user in your organization who is has admin authority over a particular group of customers. For example, a salesman or sales administrator in your organization may wish to see reports of all customers and the customer licenses for which they are responsible.

First - First name
Last - Last name of the user
Subsciption ID - Assigned when new users are created, the user or customer ID
Email Address - the email-address for contact and identification
Confirmed - Yes if licenses can be checked against this user
Group - The group name to which this user belongs
Roles - the roles given to this user

superadmin - ability to change any record and add new records
admin - ability to change any record with the same group name and add licenses for customers within the group
deploy - regular user allowed to read records owned by them and check their own licenses
trial - regular user allowed to read records owned by them and check their own licenses, but for a trial period of time

Restriction Attributes

Restrictions define certain checks for an entire class of products. There may be a single, globally defined restriction for all of your products (and, therefore, licenses generated for your products). Or, you may define different restrictions for different products. Or, they may be orthogonal to products: Define a restriction based on the types of contracts you write with your customers. An "enterprise license agreement" with your customers may allow them to install the license on any number of machines with a single registered user (Limit MACs 99999). A "personal license" may grant access of your product to each customer for use on a single machine only (Limit MACs 1). Another customer may need to operate in offline mode, where your software is running on a computer that does not have access to the Internet (Check-Every 2678400, or 31-days).

Restriction ID - A GUID uniquely identifying this restriction record (assigned when the record is created)
Enabled - The restriction is "enabled" and checked with each license check
Limit Hosts - The number of unique host names or local IP addresses that a licensed user is allowed
Limit IPs - the number of unique gateway IP addresses that a licensed user is allowed
Limit MACs - the number of unique MAC, or "ethernet" or "wi-fi" card addresses that a licensed user is allowed
Limit Concurrency - the maximum number of concurrent license requests by the same user for the same license that a user is allowed
Limit Systems - If supplied, the list of systems (e.g, zOS, AS/400, AIX, Solaris, WIndows 64-bit, Windows 32-bit, Linux 64-bit, Linux-32 bit) licenses with this restriction are tied to
Check-Every - The number of seconds (default 1 hour) between mandatory checks of the license and upload of transaction counts to the server by the client. Because the license checking process through the Java API or CLI will ordinarily not contact the license server until this time has passed, this is effectively a grace period during which the client machine may operate offline without Internet connection and not worry about about a rejected license check.
Relax - By default, all restrictions are checked. To relax the validation checks, which will result in fewer calls to your customer service organization to "reset" licenses, set relax to validationchecks.

License Attributes

Licenses are granted to a particular Customer, for a particular Product, adhering to a specific Restriction. Therefore, a license object has the following identifying elements that tie it to the others.

License ID - A GUID uniquely identifying the license record (assigned when a new record is created)
Subscription ID - A Customer ID to whom this license is issued
Product ID - A Product ID for which this licensed is issued
Restriction ID - A Restriction ID defining the license restrictions

Enabled - Indicates that the license is valid
Start Date - The date the license is issued
End Date - The date the license expires
Delta - Time between Start/End (for defining a new license for a particular duration)
Transactions - A running total of all transactions (license checks with a transaction count) that have occurred to-date, details of which are stored as LogLicense objects

Product Attributes

There are several product attributes that are ignored during Licensing-as-a-Service processing. The ones that are important and should be included in any new product.

Product ID - A GUID uniquely identifying the product record (assigned when a new record is created)
Product Title - the name of the product for descriptive purposes only (the product id is used to identify this record
Available - 1 if this product is available for licensing, 0 if not
Architecture - the machine architecture (e.g., Windows 32-bit) this product is restricted to (normally left blank)
Default Restriction - the default restriction GUID for licenses granted to this product (optional)

History Attributes

Every time the license server is contacted to check or change a license a recording is made to the log license.

Date - The date the check or alteration was performed
Activity - The licensing operation that was performed
MAC Address - The physical machine address from the licensed machine
Plus other identifying information about the license

The REST Web services are used to define or change any of these elements and require that the request be authenticated against a user (e-mail) and password combination of a Customer record. The "superadmin" role is required to modify some of them and "admin" role for others. Generally, individual subscribers can read their own transaction log entries. The Administration Interface provides a graphical view of the data.