Heimdall

Signing in

Mon, 01 Jan 0001 00:00:00 +0000

This page covers getting into Heimdall UI. If you cannot sign in because you forgot the password or have not verified your address, see Password and email.

Who can reach it: anyone who is not signed in. The second-factor screen opens only while you hold a challenge from a sign-in that asked for one. Once you are signed in, asking for the sign-in screen sends you to Home. The last section, about how routes are guarded, applies to everyone.

Password and email

Mon, 01 Jan 0001 00:00:00 +0000

These three tasks are reached from links, mostly in emails the API sends. They are public: you do not need to be signed in to recover a password or to open a verification link.

Who can reach it: anyone, signed in or not. These screens stay open when you have a session. Asking for a new verification email needs a signed-in session (see below). A restricted session cannot open them.

Restricted sessions

Mon, 01 Jan 0001 00:00:00 +0000

Under data-protection law (LGPD and GDPR), a person can ask for the processing of their data to be restricted. While a restriction is in place, Heimdall keeps the data as it is and uses it for nothing else. The API enforces this: when someone whose processing is restricted signs in, it issues a token that admits only that person’s own data-protection rights and refuses everything else.

Heimdall UI recognises that situation and gives the person a single screen instead of the usual application, where every request would fail.

Your account

Mon, 01 Jan 0001 00:00:00 +0000

Every signed-in person, whatever the role, has a profile and security settings of their own. Open them with the Profile destination in the navigation, or from the account tiles on Home, each of which opens the screen where that detail is changed.

Who can reach it: System Admin, Scope Admin and User, with a full session. A restricted session cannot open these screens.

UI-08: View and edit own profile

Screen: /profile.

Scopes

Mon, 01 Jan 0001 00:00:00 +0000

A scope is the tenant boundary of one client system. It holds that system’s owners, users, applications, permissions and Google users. Everything else in the administration screens (persons, applications, permissions, Google users) lives inside a scope, and you reach it from the scope’s detail screen.

Who can reach it: System Admin and Scope Admin. A System Admin sees and manages every scope. A Scope Admin sees and manages only the scopes they own, cannot create or delete a scope, and sees a scope’s name and description read-only. A User does not see these screens.

Persons

Mon, 01 Jan 0001 00:00:00 +0000

A person is a human identity with a name, an email, a role and a password. The persons screens work inside one scope. Open a scope (see Scopes) and press Persons.

Who can reach it: System Admin, and Scope Admin for the scopes they own. A Scope Admin who opens a scope they do not own gets the “Not available for your role” panel. A User does not see these screens.

Applications

Mon, 01 Jan 0001 00:00:00 +0000

An application is a non-human identity, usually another system, that uses a scope for its identity. It lives in one scope and has an owner. The applications screens work inside one scope. Open a scope (see Scopes) and press Applications.

Who can reach it: System Admin, and Scope Admin for the scopes they own. A User does not see these screens.

UI-20: Browse applications in a scope

Screen: /scopes/:scopeId/applications.

Open Applications from the scope’s detail.
The UI asks the API for a page of the scope’s applications, using the page, page size, filters and the Include deleted switch.
The page shows each application’s name, its owner and whether it is active or deleted.
Page through the list, search with Search by name, or switch Include deleted.

Other things that can happen:

Scope permissions

Mon, 01 Jan 0001 00:00:00 +0000

A scope can define named permissions, each with an optional description and a flag saying whether it is included in tokens as a claim. When a token is issued, the names of the flagged permissions are added to it, so a client system can read them without asking the API again. The claim is a snapshot, so a change shows up in tokens issued from then on. The permissions screens work inside one scope. Open a scope (see Scopes) and press Permissions.

Google users

Mon, 01 Jan 0001 00:00:00 +0000

A Google user is an identity authenticated by Google instead of a password. It always has the User role and belongs to one scope. It is created the first time someone signs in to the scope with Google, which needs Google Sign-In to be switched on for the scope (see Scopes). The Google users screens work inside one scope. Open a scope and press Google users.

Who can reach it: System Admin, and Scope Admin for the scopes they own. A User does not see these screens. The details of a Google user come from Google, so the UI never lets anyone edit them.