Guides

Using the portal

The portal at sigil.enigmahq.sh/portal is where your staff run licensing: applications, policies, licenses, installs and the audit trail.

Sign-in: conFIEL Auth

Sigil doesn't keep passwords for its users. Sign in with conFIEL Auth sends you to conFIEL's identity provider. You come back with a session that lasts eight hours and lives in an HttpOnly cookie. On the first sign-in from your organisation, Sigil creates the account and sets its seat pool from your conFIEL entitlement.

Today conFIEL Auth is a stand-in. The sign-in page at /auth/authorize checks a username and password against a small user directory. It is marked MOCK. When conFIEL Auth ships, only that page and the token check change; the portal and your data stay as they are.

Overview

An account that holds only instance licences sees its licences, instances and the leases its backend minted and had refused over 30 days. Otherwise: seats allocated against your pool, live installs by platform, active licenses, recent denials, activations over 30 days and the latest activity. A new account also gets a getting started checklist that ticks itself off as you register an application, create a policy, issue a license and see the first install.

Licenses

Service tokens

On an application's page, under Service tokens: name the token, tick its scopes (mint leases, revoke licences) and create it. The token is shown once; put it in your backend's secrets. The list shows each token's last four characters, when it was last used, and a Revoke button.

Installs

Every machine that holds or has held a seat, with the label and version its host sent, its platform, when it was last seen, and how long its lease has left. A machine that hasn't renewed shows lease lapsed. A released or revoked one shows released.

Air-gapped activation

For a machine that can never reach Sigil:

  1. On the machine, print its fingerprint (my-engine fingerprint in the quickstart program, or Client::fingerprint()).
  2. On the license's page, under Air-gapped activation, paste it, pick the platform and validity, and issue.
  3. Send the lease to the customer. The program installs it with Client::import_offline_lease.

An offline lease takes a seat like any activation and can't be renewed. Issue a new one before it expires.

The standby key

Your builds trust only the keys in the keyset they embedded. So every application keeps two live keys, shown under Signing keys on its page:

Rotating promotes the standby. Builds already in your users' hands trust it, so nothing breaks, and nothing has to wait for a rebuild or a store review. A new application is created with both keys. One created before standby keys existed shows a warning instead (No standby key) and rotation is blocked until you press Create standby key. A new standby protects only the builds that carry it, so download the keyset, rebuild and ship.

The habit that makes it work: ship every release with the keyset as it is that day.

Key rotation

On an application's page, Rotate key (confirmed as Promote standby) does three things at once. The standby key starts signing every new lease. The active key is retired: it stays in the keyset so leases it signed run until they lapse. A new standby is created. Builds whose keyset was downloaded after the promoted key became standby keep working. Older builds refuse new leases with SIGIL_UNKNOWN_KEY. Afterwards, download the keyset and ship it with your next release, so your builds carry the new standby before you next need it.

If you rotate because a key may have leaked, rotating stops Sigil from using it, but builds that embedded it still trust it until they are replaced. See the protocol.

Activity

An append-only trail of every issuance, activation, renewal, denial (with its reason), revocation, release, rotation and seat change, with the country the request came from.