MCM-07 — Subscription Activation and Secure Credential Delivery

← Back to MCM Nexus overview

As a Nexus Admin,
I want approving a request to automatically activate the subscription and issue MCM App credentials to the customer,
so that the customer can connect their MCM instance without any further manual steps from me.

Acceptance Criteria

• On approval, the Organization's License is activated (or updated) with the correct status, validity window, and role/mode (Enterprise-demo, MSP-demo, or paid).
• An MCM App User (Keycloak identity under a dedicated MCM_APP realm role, distinct from ADMIN/CUSTOMER, one per Organization) is created or reissued for that Organization if one does not already exist.
• The MCM App username follows a fixed convention for every customer: mcm@<customer's domain> (e.g. mcm@acme.com for a customer at acme.com).
• For self-hosted activations (Self-Hosted MSP Demo, Purchase, Extension of a self-hosted license), the customer receives an email containing: the MCM App username and password/token directly in the body (plaintext — there is no one-time reveal link or set-password flow), deployment guide links, and support/documentation links. See Email Template below for the exact content.
• For Hosted Enterprise Demo activations, the email is adapted — see MCM-03 for how it differs.
• The Nexus Admin can regenerate or revoke an Organization's MCM App credentials at any time (lost credentials, suspected compromise, routine rotation); regenerating invalidates the previous password immediately.
• The Nexus Admin has visibility into the last time each Organization's MCM instance successfully validated its subscription (see MCM-08), so a healthy connected customer is distinguishable from one that has gone quiet.

Technical Design

Approving a request triggers mcm-nexus/backend to activate the Organization's License (status, validity window, role/mode) and issue or reissue a per-Organization MCM App Credential under a new MCM_APP Keycloak/UserRole value, with the username fixed as mcm@<customer-domain>. It then calls the shared send-email API (see MCM-11 — Shared Email API) to deliver the credentials to the customer in plaintext — there is no one-time reveal link or set-password flow. The Nexus Admin can regenerate or revoke an Organization's MCM App Credential at any time, which immediately invalidates the previous password; a failed email send is retried with backoff and logged rather than silently dropped.

Email Template

Exact content of the activation email for self-hosted activations (Self-Hosted MSP Demo, Purchase, Extension of a self-hosted license):

Subject: Your MCM Subscription is Ready

Dear <Customer>,

Greetings from the MCM Team!

Your MCM subscription is now ready. Please find the information below to begin deploying the MCM platform in your environment.

## Deployment Guides

Please refer to the following documentation for step-by-step deployment instructions:

Single Tier Deployment: https://mcm.revdau.ai/docs/v1.1/single-vm-deployment/deployment-guide/
Three Tier Deployment: https://mcm.revdau.ai/docs/v1.1/3-tier-deployment/deployment-guide/
User Guide: https://mcm.revdau.ai/docs/v1.1/user-guide-msp/overview/

## Subscription Details

Please use the following details to activate the subscription and download the installation file

Username: mcm@<customer-domain>
Password/Token: <generated password/token>

If you encounter any issues during deployment or require assistance, our support team is available to help.

Support Email: mcm@revdau.ai
Documentation Portal: https://mcm.revdau.ai/docs/

Thank you for choosing MCM.

Best Regards,
MCM Team

The Username/Password shown here are the MCM App credentials from MCM-06/this story — the same credentials used to authenticate the wget download in MCM-09 and the instance-side calls in MCM-08 and MCM-10.

UI / Frontend Changes

• (admin)/admin/customers: add MCM App credential management per organization — issue, regenerate, and revoke actions, plus the last-validated timestamp.
• Regenerate/revoke actions require a confirmation step, since regenerating immediately invalidates the previous password.
• Customer-facing dashboard/email confirms activation but does not surface the plaintext credential anywhere in the UI itself — delivery is via email only (see Email Template above).
• Nexus Admin request-approval screen (see Nexus Admin Review, Approve, and Reject Requests) shows the resulting license role/mode and validity window once activation completes.
• Organization detail view surfaces "last validated" status so the Nexus Admin can distinguish a healthy connected customer from one that has gone quiet.