remoteEaze
Security & Compliance

Licensing and Tenant Control

How licensing controls tenant provisioning, runtime access, and contract integrity.

Last updated

What licensing controls

In remoteEaze, a license is more than a billing record. It is a control object used for:

  • tenant identity
  • contract validity
  • runtime access gating
  • tenant security policy values (for example password and session settings)
  • tenant bootstrap and default setup

Contract terms vs operational settings

The implementation separates license data into two categories.

Contract terms

These are integrity-signed values and are part of tamper verification:

  • slug
  • expiry date
  • module list
  • timezone

Operational settings

These are operational controls that can be updated without changing the signed contract payload:

  • company and contact details
  • logo reference
  • financial year and accounting settings
  • password policy values
  • inactivity timeout and working-hours grace settings

Provisioning role

Creating a license is tenant provisioning, not just record creation.

The create flow provisions key tenant foundations in one transaction, including:

  • license record
  • tenant currency setup (including base currency)
  • head office branch
  • tenant admin role and agent role
  • default reference data
  • default transaction codes
  • boundary products
  • standard sequences

Runtime request gate

For normal tenant users, authenticated requests pass through license validation before business routes continue.

The runtime gate checks whether the tenant license is:

  • active
  • not expired (using tenant timezone)
  • integrity-valid (signed payload matches stored data)

So a user can have role permission and still be blocked if the tenant license is not valid.

Integrity and expiry behavior

Key contract terms are signed and verified with HMAC integrity checks.

If integrity fails, the tenant is treated as tampered and access is blocked.

Expiry is timezone-aware, using the tenant timezone for access validity decisions.

Cache and block behavior

Licensing uses Redis for two different purposes:

  • cached validated license data
  • a short-lived tamper block flag

These states are separate. Cache improves read performance, while block state is an explicit deny signal.

Access model

The system separates true system-scope administration from tenant-scope administration.

  • system-scope admins can manage cross-tenant license inventory and contract-level actions
  • tenant-level admins are restricted to their tenant boundary and allowed config surfaces

Contract updates vs config updates

Contract updates and config updates have different effects.

Contract update

When contract terms change, the system re-signs the license payload and invalidates related caches.

Typical examples:

  • expiry changes
  • module changes
  • timezone changes
  • activation state changes

Config update

Operational config updates change tenant behavior but do not re-sign contract payload.

Typical examples:

  • contact information
  • password/session settings
  • accounting and financial-year settings
  • logo linkage

Where this appears in the product

Licensing is active in the admin application, including:

  • license listing
  • license detail view
  • configuration editing
  • contract editing (where allowed)
  • license PDF export
  • expiry visibility

Common deny states

Operational deny/error states you will see most often are:

  • LICENSE_TAMPERED
  • LICENSE_EXPIRED
  • LICENSE_INACTIVE
  • infrastructure failure during license verification

On this page