Monitor and fix access from the console

In the reference architecture, Lemniscate does not manage identities: access is monitored and corrected in your directory, and a session or a user is revoked from the console (V3 security white paper, sections 4.5 and 6.1). Local accounts exist only where no directory is available. This page covers consoles whose build profile carries a local account repository: it describes the corrective actions available from the Users tab, and what each one leaves behind.

Creating an account is covered elsewhere: Give an API key to a team. Spending caps are too: Cap a customer’s spending.

The profile that carries this tab

The Users tab, like Plans and Usage, is present only in consoles built with the hosted profile. In the closed profile, the one you get by default, there is no local account repository: identities come from your directory, access is managed there, and the corresponding paths return 404, with a message saying so. A console that does not show this tab is not a misconfigured console.

Read the accounts screen

Column	What it shows
ID	The account identifier. It carries the attribution of billed calls.
Username	The account name.
API Key	A fragment of the account’s most recent key, never the key itself. No live key when no key on the account is valid any more.
Plan	The plan carried, editable in place. An account with no plan carries Blocked.
Active	Active or Inactive.
Created	The creation date.

Accounts are listed from newest to oldest. There is no search, no sorting and no pagination.

The key fragment

An API key is displayed once: on screen, right after a creation, an issuance or a rotation. After that it is no longer readable, by anyone. The database keeps only a digest of it.

The API Key column shows a fragment: the prefix and the last four characters. It lets you tell two keys apart when someone tells you “my key ends in…”. It does not let you recover the key. An account can carry several keys; the column shows the fragment of the most recent one and the count of the others (+1 more).

A lost key cannot be recovered: it is replaced.

The two states Blocked and Inactive

What you see	What is happening	How to get out
Blocked in Plan	The account has no plan. The gateway refuses its calls with 403.	Assign it a plan, in the Plan column.
Inactive in Active	The account has been removed from service. Its keys no longer authenticate.	Reactivate it (see below; there is no button).

Rotate a compromised key

The Rotate key button on the account’s row, then confirmation.

What this produces:

• a new key is issued and displayed once;
• every key the account carried stops authenticating immediately, with no overlap period;
• the account keeps its identity, so the calls already billed stay attributed to its name.

Warn the person or the team beforehand: between the click and the delivery of the new key, their access is cut.

Remove an access

The Delete button, then confirmation. The console picks between two outcomes, depending on the account’s history:

Situation	What happens
No call has ever been logged for it	The account is deleted.
Calls have been logged	The account is deactivated, its row kept.

In the second case, deleting the row would destroy the attribution of calls already billed. In both cases, the key stops authenticating.

Reactivate a deactivated account

There is no button for this. The Active column is a display. The path exists on the service side; the screen does not expose it.

Reactivation is done with a direct call, using the account identifier read from the ID column:

curl -X PATCH "$CONSOLE/api/users/42" \
  -H "Content-Type: application/json" \
  -d '{"active": true}'

Put your console’s address in CONSOLE, over https://, and present the identity you use to open the interface. The response returns the account’s state, key fragment included.

This path does not return the key: if it was lost in the meantime, rotate it.

Change an account’s plan

The selector in the Plan column saves the moment you choose, with no confirmation.

The No plan option removes the account’s plan, which blocks it: the gateway answers 403 to an account with no plan. The refusal the caller receives mentions a missing plan, which points to a billing problem. To cut off an access, use Delete.

Edit or delete a plan

In the Plans tab, each row is edited in place (Edit): its name and its monthly cap. An empty cap field makes the plan unlimited; it is not a cap of zero.

The Users column counts the accounts carrying the plan, including deactivated accounts. A plan that shows holders when nobody works with it any more is carried by deactivated accounts.

Deleting a plan is refused as long as an account carries it, with the reason: Cannot delete plan: users still carry it. Reassign them to another plan first. Reassign those accounts first; removing their plan would block them.

The administration action log

Role assignments, their removals, revocations and their liftings, and any policy change are logged with their author, whose identity comes from your directory. The log is append-only, and each entry seals the previous one (V3 security white paper, sections 7.1 and 7.2).

The log is read through a path reserved for the auditor role; an instance administrator cannot read it, since holding both administration and audit is refused. The exact paths and permissions are in the administration console reference.