How to Protect a Web Application with Licensing Controls

Web applications are technically different from traditional, desktop applications, in several ways. Consequently, they come with some unique challenges and options for licensing . The first challenge with licensing a web application is determining its license model. In addition to the many license models that apply to all applications, web applications can also have licenses limited by: web server, web site URL, active user accounts, active sessions, features, number of database records (such as tasks, products, licenses, invoices, and more).

Licensing Web Servers: Physical vs. Virtual vs. Cloud Servers

Binding a license to an individual, physical server is straight-forward ; however, there may be more you need to know about licensing software on a virtual or cloud server. This is because cloud servers are basically virtual machines , which can move between physical servers (even while running) without notice.

Licensing by Web Site URL

Licensing by web site URL is a popular and effective way to license a web application for use with a particular web site or organization. If this is the only constraint enforced on the license, it makes for a generous amount of flexibility for use on multiple servers (in high-availability configurations) and cloud servers. However, the added flexibility could enable abuse of a license if this constraint is not paired with something else.

Licensing by Active User Accounts

An active user account can also be identified via a login of a user who is allowed to access the web application. Limiting the number of active user accounts is another popular approach used when licensing web applications. This is especially useful if the goal is to license the software by user . An administrator can temporarily or permanently disable user logins so that other users can be added, keeping the number of active user accounts below the licensed limit . When the limit is reached, the administrator's ability to add more user accounts will be disabled until others are deleted or deactivated.

Licensing by Active Sessions

It is important to note that HTTP is a stateless protocol , meaning the web server has no way to know if the user has closed the browser tab or window. Once a user has logged into the web application, there are many ways to authenticate the user on each web page request as they move from page to page. It is common for web application developers to use the database to track each user's session and pass this session ID around in a temporary cookie.

When using a session table in your database, it is technically possible to leverage this to limit the number of active/concurrent sessions . However, if the users close their browser tab or window without first logging-out of your web application, your session management system would need to track the last time the session accessed a page and automatically close inactive sessions . If the user of a closed session attempts to access the web application, they should be redirected back to the login page, where the active session licensing check can be re-evaluated.

Licensing by Features / Modules

This type of licensing allows you to activate one or more modules, menus, or features within a web application. This concept can also be used to have variations of a single application available in tiered versions. For example, Software Product XYZ can be marketed and sold in Platinum, Gold, and Silver Editions , with each edition, or version, providing the end-user with a different set of features and functions . As the customer’s needs change, the license can be updated on the central licensing server and immediately refreshed by the client to enable the new functionality.

Licensing by Usage Counters and Consumption Based Licensing

One way to charge your customer based upon the value your software is providing is to set fees based upon actual usage (much like how the electric company and other utilities work). Depending on the nature of your web application, this could take many forms such as:

• If your application has some type of batch processing, you could track the number of batch run s .
• If users create database records, you could require the user to upgrade their license once they have reached certain database table sizes (number of records). A good example of this is a Customer Relationship Management system. As your customer list grows, your CRM vendor can gain additional revenue from you since the value to you of the CRM is increasing (and you hopefully have additional revenue from the additional customers to afford the additional licensing fees from your CRM vendor).
• A counter can increment or decrement based upon some other type of process, such as when a report is printed or some type of online process is triggered.

Whether you want the user to pre-pay for certain levels of access or you want to provide utility-like usage billing , there are many ways to approach consumption-based licensing.

Performance Under High Loads

Since web applications have the potential to be used by many users concurrently on a single server, it is extremely important to consider the peak loads you expect your application to encounter, and design and load test accordingly. Here are some things to keep in mind when licensing a web application that has heavy traffic:

• Consider caching the license validation results as a means to control how frequently validation reoccurs. If the web application fully re-validates the license for every web request, a huge amount of overhead will be incurred, which could make the web application slow or even completely unresponsive. This is often exacerbated by the fact that any cryptography used to secure the license requires a significant amount of processor resources . However, if the web application limits license re-validation to either a certain span of time and/or a certain number of requests, this can be leveraged to help avoid such performance issues .

• Related to the point above, frequent file reads and especially frequent file writes can cause performance and file locking problems in web applications. If you have a good reason to frequently update or read the license file, consider storing it in a database instead of a typical file system, as this can improve performance and help avoid locking issues. However, keep in mind that storing the license file in the database may require some extra design considerations if the license needs to also be bound to individual web servers.

Be Mindful of Firewalls

Web servers are often in environments with strict firewall policy that may limit or completely prevent any outbound traffic from making it to its destination. Consequently, this kind of firewall policy can prevent a web application from phoning-home to validate and refresh its license. This is important to consider when enforcing your licensing requirements, especially when the web application provides business or mission critical functionality to its users.

Conclusion

There is never a lack of considerations with regard to licensing applications, and web applications only add to that list. If you’re currently using or considering using the SoftwareKey System, and you have questions about licensing a web application with it, our team is just a click or a call away. Contact us here.

About the Author

Abram Pousada is one of the passionate Software Engineers with SoftwareKey.com. He started his career with SoftwareKey.com when he was in high-school and has been with the company for over a decade. After-hours, the self-proclaimed geek enjoys a variety of engaging hobbies ranging from even more programming to video games and mountain biking.