Kiuru License

License File

Each Kiuru MSSP server has the license file in “licenses/kiuru-license.txt” path relative to server’s runtime directory.
File starts and ends with a comment line starting with ‘#’ character. Lines starting with ‘#’ inside the license file are also permitted. All such lines are ignored, as are also empty lines.

# --- The license file begins ---
subject=Licencee Name
id= . . . .
description= . . . . 
issuetime=2019-03-01T00:00:00.000Z
expire=2019-06-01T00:00:00.000Z
. . . . . .
pksignature=MEQCIHi . . . . . jmoA==
# --- The license file ends ---

Updating License
The license file is a small text file that can be delivered as email attachment to you. Updating the running license is as simple as creating the file on some work directory, like /tmp/, and then copying from there over the MSSP’s license file after making a backup:

$ cp /opt/hmssp/licenses/kiuru-license.txt /tmp/kiuru-license.backup
$ cp /tmp/new-license.txt /opt/hmssp/licenses/kiuru-license.txt

Within 60 seconds the MSSP will detect change of the file (change of file modification timestamp), and then read the new license.
The license file auto-reload affects following licensing limits (if defined in file):

• License expiration time
• Cluster size
• ActiveUserLimit (for ME only)
• RestPortLimit (for REST API server only)
• RateLimits
• Applet Report Cron (for ME only)

The license file auto-reload does not affect which modules have been licensed, and a restart is needed to activate new modules.

License Limits

Methics issues a license with agreed modules with defined license limits. These limits are:

1. Expiration time Last validity date of the license.
2. Modules A list of Kiuru modules licensed for use.
3. Cluster size Number of Kiuru instances sharing transaction state database
4. Rate limit Number of requests per second served by the Kiuru MSSP instance
5. Active user limit Number of active users in MobileUser database.

Additionally, the customer may configure protection features on each MSSP to limit permitted request rates and outgoing request rates. (See Configuration Guide, look for “ratelimit”.)

Expiration Time
Date and time of last permitted usage of the Kiuru server. Literal value “never” means the license will never expire.
When expiration datetime has been reached, the Kiuru MSSP does not stop serving requests. Instead the Kiuru MSSP adds 1 second of processing delay for each day past the license end date. Additionally, log records a license expiration note. After 30 days expiration, the delay per request is already 30 seconds.

Modules
The Kiuru MSSP system is built from subsystems, each of which has own identifiers. These identifiers are called “modules” in the license file.
When a module is listed in the license file, its functionality is enabled.

Cluster Size Limit
The Kiuru servers can be operated as service state sharing clusters, any of which can serve subsequent request referring on previous operation.
The size limit defines how many servers can be in a clustered system.
When starting more server instances than the license permits, latest started instance stop themselves when they detect the size limit excess.

Rate Limit
The rate limit parameter consist of two floating point numbers. They are called average rate, and burst rate in the “Token Bucket” algorithm: http://en.wikipedia.org/wiki/Token_bucket
The algorithm works by maintaining a token bucket (per protocol service) from which each request consumes one token from the bucket. When the bucket becomes empty new incoming requests on that service are rejected until the bucket is refilled enough to serve a new request. The token bucket is filled with tokens at an average rate (requests per second), and its maximum size is defined by burst rate.
The MSSP can serve requests at average rate continuously or by short bursts of higher rate until a bucket is empty. When a request is rejected, the MSSP responds with protocol specific error indication, for example with a SOAP Fault: SubCode: LicenseRateLimitReached along with HTTP error code 503 SERVICE UNAVAILABLE.

When Kiuru MSSP servers are clustered, each server instances limit is defined in the license, and total cluster rate limit is close to cluster size times license rate limit. This closeness depends on cluster size and stocastic factors of request duration, request arrival sequence, and how they are distributed to the cluster instances. Rule of thumb is 70 to 90% without one instance getting so much more requests than others that it will trigger the LicenseRateLimitReached fault response.

The license rate limitter accounts requests into specific service types:

• MSSP server: MSS_SignatureReq requests into the rate limit. Other types of MSS requests are not accounted.
• SAML2 server accounts for all types of SAML2 requests.
• DSS server accounts for all types of DSS requests.

The SPML2, ILINK, AMS, OTA7 callback, and GlobalPlatform servers do not enforce any rate limit.
Each of the above servers account requests separately. For example SAML2 requests do not consume MSSP requests limit.

The following table illustrates the correlation between the request rate limit and the system size:

Active User Count Limit
Optional license limit defines maximum number of MobileUser records in ACTIVE states.
If the license does not define “activeuserlimit=nnnnn” record, then this limit is not defined.
The limit affects following MREG operations. If limit is reached (= system has too many active state users) then the operation is rejected with status code 990 LICENSE_LIMIT.

• ActivateAlauda / ReactivateAlauda
• ActivateCPAS8 / ReactivateCPAS8
• ActivateFuturae / ReactivateFuturae
• ActivateMobileUser / ReactivateMobileUser