In this scenario, your software is a classic desktop application, which you sell to your users either on a traditional CD or as a download. Your user receives not only the software itself, but also an activation code in the form of a ticket that you create with CodeMeter License Central. When creating that ticket, you can determine how many devices the software can operate on at the same time and for how long it can be used without a permanent connection to the Internet.
Your user installs the software on a PC. When it is started for the first time, he or she is asked to enter the ticket. The software contacts CodeMeter License Central and sends the ticket and a fingerprint of the computer (in the form of a WibuCmRaC file) up to the cloud. CodeMeter License Central checks whether the ticket is valid and, if it is, creates a temporary license for an offline cache. The license is returned to the user (by WibuCmRaU file) and imported locally into the CodeMeter Runtime. The ticket is also stored locally, e.g. in the license. Your software then launches and works perfectly without any need for a permanent Internet connection.
Shortly before the temporary license expires in the offline cache, the application phones home to CodeMeter License Central and renews the license.
Should the user install the software on another device, he or she would enter the ticket again. Depending on your choices and settings, your software could react to this in three ways:
The license is moved into a local cache as a temporary offline license, and the software is launched.
The user selects the “old” license, which is automatically flagged as “deactivated” in CodeMeter License Central. A temporary offline license is then created, and the software starts.
The user is notified that the number of licenses has been exceeded and that he or she would either have to deactivate the old license manually or wait for the temporary license to end its set duration.
The second option has proven itself as the best practice: It is flexible enough for the user who can continue to work with the software even after reaching the maximum number of devices, and transparent enough for you as the developer to uncover fraudulent use and take the necessary countermeasures.
Cloud Licenses for SaaS Applications
You can offer your users a SaaS application with unrestricted or temporary licenses for different features. CodeMeter Cloud Lite offers you a simple and lean way of reconciling the online and offline worlds, especially when you are already using CodeMeter for on-premise software and have integrated the license creation processes with your SAP, Salesforce, or any other ERP, CRM or e-commerce system.
The licenses for SaaS applications are created in the same manner that is used for on-premise licenses; they only differ in the binding scheme, using CodeMeter Cloud Lite in the place of CodeMeter SmartBind or CmDongles. A license is created and assigned to a user in a process that does not differ from the activation of a local license – you can even combine both forms. You can integrate your user admin processes with Single-Sign-On solutions like OAuth2 or SAML.
CodeMeter Cloud Lite comes with a simple API to check active licenses, which would access the SaaS applications, verify the available licenses, and determine which functions are available for how long.
Authentication for SaaS Applications
On top of its comprehensive licensing and powerful software protection capabilities, CodeMeter comes equipped with a third star trait: The private keys used for authentication can be stored securely on a CmDongle or a computer-bound CmActLicense. This makes CodeMeter the right choice for user authentication in SaaS scenarios.
The solution can be integrated via the CodeMeter API, specifically when you supply your users with a dedicated local application that works in tandem with a SaaS application in the cloud. The SaaS software creates a challenge that the local application responds to by signing it with the private key kept in the local license. Up in the cloud, the SaaS application uses the public key to verify the identity of the user, with the users’ identities managed and recorded in the cloud according to your specific needs.
For browser applications, client certificates have established themselves as the standard solution. A middleware is used to transfer standard x.509 certificates on a CmDongle. Two standardized interfaces (PKCS#11 and Microsoft CSP) are available for applications like Internet Explorer, Firefox, Chrome, Safari, Outlook, or VPN clients to use these certificates. Some applications might only need a valid certificate to allow access to the SaaS application. Others can extract more granular data like user names, organizations, or other attributes to identify named users or user groups. If you wish to control access to your SaaS application with this level of certainty, you need to create, manage, and always keep track of the necessary client certificates, which need to be known to the SaaS application. Vice versa, the certificate with which the SaaS application identifies itself to the user should be a server certificate created by a trusted certification authority (e.g. VersiSign or GlobalSign).
Standard Applications in Private Clouds
A private cloud would typically be a farm of virtual machines operated in a company’s own data center or at a specialized provider on other hardware known neither to you nor to the user. It might not even have USB interfaces to connect to. Again, CodeMeter has the capabilities needed to handle this scenario and protect your rights as the developer of the software. You have several options at your disposal:
USBoverEthernet: Your user is given a license in the form of a CmDongle. Common USBoverEthernet products can now be used to connect that CmDongle to the virtual machine in question – many data centers have this technology as standard practice. You do not have to make any changes to your software or to your established distribution methods.
Network Server: Your user operates a network server in the data center. CodeMeter offers a special lean CodeMeter Runtime for such servers, designed to operate even on Raspberry Pis. The CmDongle is hooked up by USB to that server. Your software only has to support the CodeMeter networking protocol (CmLAN), which implies only a minor change in the configurations for your software. You still deliver your software in the standard manner.
Server in the Cloud: A CmWAN server can be operated by you directly or by your users. The licenses can then be kept in the LAN, WLAN, or the cloud, using CmDongles or CmActLicenses on the CmWAN server. As with the network server, your software needs to support the right protocols, and the distribution processes still remain unchanged.
SmartBind with VM Move: You create a SmartBind license with a “loose” level of tolerance. This makes sure that the license remains intact when the virtual machine it is kept on is relocated in the cloud. It would be invalidated when the virtual machine is copied. Alternatively, you could define the machine SID as the binding property. You do not need to change anything in how you integrate the system in your application; all you need to do is create special licenses for the users who will run your software in their private clouds.
Licensing with CodeMeter Cloud Lite: You can leave the licensing of your software to CodeMeter Cloud Lite. Your application would be given a Protection Only License to prevent reverse engineering and regularly check the Wibu cloud to see whether the license is still valid or whether it is being used elsewhere. This type of licensing requires some changes to your software and a permanent Internet connection between the user’s private cloud and the Wibu cloud. The creation of the license itself is not made more difficult: all it needs is the addition of CodeMeter Cloud Lite as another binding property.