[backend/frontend] XTM One registration and ping mechanism (PoC)

[SamuelHassine]

Context

OpenCTI instances currently register with XTM Hub for ecosystem connectivity, but there is no equivalent mechanism for XTM One — the unified XTM Suite control plane. This gap prevents XTM One from discovering and managing connected OpenCTI instances, provisioning per-user integrations, and enabling features like the embedded Copilot chat.

Proposed solution (Proof of Concept)

Implement a registration and periodic heartbeat mechanism between OpenCTI and XTM One:

Registration manager

• New xtmOneRegistrationManager that runs as a scheduled manager (every 5 minutes) when both xtm.xtm_one_url and xtm.xtm_one_token are configured.
• Fires once at boot (after a 30s delay) so the platform appears in XTM One immediately, then continues on the regular interval.
• Calls the XTM One /api/v1/platform/register endpoint as an upsert — repeated calls serve as both initial registration and heartbeat/ping.

Registration payload

Each ping sends:

• Platform metadata: identifier, URL, title, version, internal ID
• Enterprise license: PEM and decoded license type (if available)
• Admin API key: for XTM One to call back into the platform
• User list: all users with emails, each with a display name and a dedicated XTM One API token (provisioned once per user, unlimited duration). Subsequent pings send users with an empty api_key — XTM One retains previously stored credentials.

Response handling

• Stores the chat_web_token returned by XTM One (used for Copilot chat integration).
• Logs registration status, EE enablement, and user integration count.

Configuration

New config key xtm.xtm_one_token alongside the existing xtm.xtm_one_url. Both must be set for the manager to activate — xtm_one_url alone is already used by the chatbot proxy and does not imply registration should run.

Additional changes

• Improved logging in authenticateUserFromRequest — token resolution errors now include a token prefix, user-agent, and origin for easier debugging.
• i18n strings for the new manager label across all supported languages.

Status

This is a Proof of Concept (PoC) — the implementation is functional but intended to validate the approach before production hardening. Areas to address before GA:

• Security review of token provisioning and payload contents
• Error handling and retry strategy refinement
• Configuration validation and documentation
• Rate limiting / backoff on registration failures