Open the administration console

The administration console is the web interface from which you drive the gateway: declaring what it serves, writing the policy, reading session records, revoking a session or a user. This page describes how to log in, what you find there, and the situations that look like a failure without being one.

The console is reserved for administrators. It is not an interface for developer workstations, whose only interface is the gateway, and you can restrict it to your administration network. Its traffic is encrypted with TLS, like all flows between components (security white paper V3, section 6.2).

Who logs in to the console

Lemniscate does not manage identities: it relies on yours. The console delegates authentication to your corporate directory (OpenID Connect). It checks no password and holds none. Local accounts exist only for isolated environments, where no directory is reachable (security white paper V3, section 6.1).

Four human roles share the rights (security white paper V3, section 6.1):

Role	What it does
Security administrator	defines global policies and log exports; does not see the code
Project administrator	defines active tools, free or approval-bound commands, budgets, project members
Developer	starts sessions in the projects they belong to; approves diffs and commands
Auditor	reads logs and policies, read-only

The agent has no account and does not log in to the console.

Being authenticated is not enough: each console path requires a named permission, and each permission is carried by a single role. An authenticated subject with no assigned role gets nothing. The exact names of the roles and permissions the console knows are in the administration console reference.

With no directory configured

With no directory declared, nobody logs in: an installation that has not yet declared its directory has no valid identity to check against.

Three environment settings carry this declaration: the directory issuer, the client identifier, and the return address of the login flow. Their exact names and their effect are in the console reference. They are set in the container environment, not from the console.

The return address is that of this console, and the directory must know it: declare it on the directory side as well, otherwise it refuses to send you back to it.

The first opening at a customer site, in three steps

A fresh installation has no unlock screen: everything happens beforehand, in the container environment and through an operations command. The three steps, in this order.

1. Declare the directory, then restart the console

The three settings above are set in the container environment. They are read at startup: a change takes effect only at the next restart.

The second line of the startup log names the issuer the console delegates to. If it says that no directory is configured, or that part of it is missing, the exact reason is written there.

2. Log in a first time, and be refused

Open the console address. It sends you to your directory, which authenticates you and brings you back. You are then refused: the message says that your identity is recognized, but that none of the roles assigned to you carries this right.

This refusal is part of the path: the role table of a fresh installation is empty, and the next step needs the name under which your directory presented you. That name, the identifier your directory carries and not your email address if it distinguishes the two, is what the next command expects.

3. Assign the first role

This step opens the instance, and it does not go through the console: the right to assign roles is itself a right, which nobody carries yet.

From the gateway container, which has the database connection:

node dist/authz/attribuerRole.js <identifiant-annuaire> administrateur-d-instance "<qui attribue>"

Three things to know about this line:

• administrateur-d-instance is the role that opens the console. Assigning another role authenticates without opening anything.
• The third argument is kept with the assignment, in the administration record log. It is declared, not verified: write a person’s name there, not admin.
• The command creates neither an account nor a secret. It writes a name in a table. Your directory must still authenticate that name: assigning it to someone the directory does not know opens nothing.

Reload the console: it opens.

The auditor role

One subject cannot hold both an administration role and the audit role: this separation is what gives the log its meaning, since an administrator must not be able to read it. On a fresh instance, nobody reads the log as long as the auditor role is assigned to nobody, and it cannot be assigned to you.

Assign it to someone else, with the same command.

Reading the three startup lines

When it starts listening, the console writes three lines in its log:

1. the address and port it listens on;
2. what authenticates it: the mechanism, and, if something is missing for anyone to be able to log in, what is missing. This is the only place where the full reason is stated: HTTP responses announce only a class of refusal, so as not to inform an attacker about the state of the deployment;
3. the account repository it has: a local repository, or none.

What you find on screen

The build profile decides which tabs are present. It is a build parameter, not a setting: an artifact does not change it, and the closed profile is the one the build produces with no parameter.

A single page, a sidebar on the left, and up to seven tabs in a fixed order: Users, Plans, Endpoints, Usage, Caps, Policy, Audit. The foot of the sidebar carries the appearance setting (light or dark theme), and nothing else: not the logged-in identity, not a logout button, not a version number.

The tabs of the closed profile

In the closed profile, three tabs exist: Endpoints, Policy and Audit. The four others (Users, Plans, Usage, Caps) are not hidden: their labels, their forms and their calls are not in the delivered package, and the corresponding paths return 404.

These four tabs have no purpose in the reference architecture, where the gateway talks to your own inference engine: all identities come from your directory, and no consumption is to be billed. They are present only in consoles built in the hosted profile.

Endpoints is the only tab an installation needs in order to serve anything at all. See Declare a model served by the gateway.

The amber banner at the top of the page

A banner can appear above the title, on all tabs. It states what the gateway does with agent sessions, and it appears only when there is something to say:

• either the gateway has not announced what it does (it predates this version, or has not been restarted since). The console then cannot say whether agent commands run on the server or on the workstations;
• or the containment guarantee of the security framework does not hold for this deployment, and the banner lists what it does not give you.

This banner describes the gateway, not each workstation: a workstation configured to run locally does not query it.

It is reserved for the instance administration role. An auditor does not see it.

The container

The image exposes port 6002, which is also the default listening port, and runs under an unprivileged user. It contains only what is needed to run: the built package and its production dependencies, without the source code or the development tooling.

With no explicit build parameter, the resulting image is that of the closed profile. An omission produces the restricted artifact, not the other way round.

The composition file

The repository does not ship a composition file that brings up the console with its database for a deployment. The only one that assembles the three containers (database, gateway, console) is the attack bench under scripts/redteam/, with a simulated provider; it is not meant for deploying. So start the two containers and connect them yourself: the console needs a connection string to a database whose migrations are applied. See Apply database migrations.

The forgotten database setting

With no connection string in its environment, the console does not refuse to start: it falls back on a local development database. A deployment that forgets this setting does not blush; it connects elsewhere, and you see an empty console instead of an error.

If the console opens on empty lists while your database contains data, check this setting before anything else.

The interface component demonstration page

The repository contains a second interface, served on port 6003 by a separate command, which displays the console’s graphical components for whoever develops it.

It sets up no authentication. It displays no data from the database and calls no service path. Do not start it on a production host; the package built for production does not contain it.

What the console does not do

• It has no first-configuration screen. Everything is set in the container environment before the first startup.
• It holds no password and has no screen to change one: authentication belongs to your directory.
• It is not reachable from developer workstations when you restrict it to your administration network, and it has no outbound destination (security white paper V3, section 6.2).