How to Handle TTL and Session Security with Floating Licenses

[r-brown]

One question regarding the use of online Floating licenses.

The current dryRun response contains a TTL of approximately 24 hours. How should a C# client bind a signed validation response to the current customer, application session, and request, while also making sure that a response cannot be reused after it expires or after a Floating Seat has been reassigned?

[r-brown]

The important distinction here is between the TTL of the validation response and the lifetime of a Floating Seat.

The TTL of the validation response is primarily intended for caching a successful validation result. It does not mean that a Floating Seat is reserved for the entire TTL period.

For an online Floating license, we recommend using NetLicensing's Floating license mechanism and binding the checkout to a unique sessionId.

The typical flow is:

checkOut(sessionId)
        ↓
      usage
        ↓
renew before expirationTimestamp
        ↓
   application ends
        ↓
checkIn(sessionId)

The client should generate a unique sessionId for each application session. When the application starts, it performs a validation with the Floating checkOut action and this sessionId.

NetLicensing then assigns an available Seat to that session. The validation response contains an expirationTimestamp, which represents the actual validity of that Floating checkout.

Before the checkout expires, the client should perform another validation using the same sessionId to keep the Seat assigned. When the application exits, the client should release the Seat with a checkIn using the same sessionId.

For the C# client, the recommended approach is to use the regular LicenseeService.validate(...) method together with the appropriate ValidationParameters. For Floating licenses, the relevant parameters include productModuleNumber, sessionId, and action.

A signed request nonce / challenge-response mechanism is currently not supported. In other words, NetLicensing does not currently take a client-generated nonce from the request and include it in the signed response.

The XML signature protects the response against modification or forgery, but it does not cryptographically bind the response to a specific request nonce.

For this reason, the sessionId together with the server-side Floating checkout mechanism should be used as the session-level binding.

One important point regarding replay protection: a client should not simply cache and reuse a successful validation response for the full response TTL when using online Floating licenses.

Instead, the client should respect the expirationTimestamp returned for the specific Floating checkout and renew the checkout before it expires. This ensures that the actual Seat assignment remains controlled by NetLicensing. Once a Floating checkout has expired or the Seat has been released/reassigned, an old cached response should not be treated as proof of a currently valid Seat.

The XML signature should also be verified by the client for every response received from the server, using the configured public RSA key.

In short:

• TTL → controls how long a validation response may be cached
• sessionId → identifies the individual Floating application session
• checkOut → obtains a Floating Seat
• expirationTimestamp → defines the actual lifetime of that checkout
• validate with the same sessionId → renews the checkout
• checkIn → releases the Seat
• XML signature → protects the response against tampering and forgery
• Signed request nonce → currently not supported

This approach keeps the actual Floating Seat state server-side and avoids treating an older cached validation response as an active Seat assignment