Skip to main content

Sign-in, password, and security

The page describes how sign-in to the cabinet is organized, what is stored in the browser and on the server, and what security rules a user and an administrator must follow.

How sign-in works​

Assist has no fields for entering a login and password. Sign-in is performed through Keycloak, the company's separate sign-in system.

Browser        Assist              Keycloak
  │  Sign in ──▶│                     │
  │◀── redirect ──────────────────▶│
  │  login and password ──────────▶│
  │◀──────── return to Assist ─────│
  │  session created, “My work” opens
  1. You click Sign in on the Assist page.
  2. The browser goes to the Keycloak page.
  3. You enter the login and password on the Keycloak page. Assist does not receive this data.
  4. Keycloak confirms your identity and returns you to Assist.
  5. Assist creates a session on the server and gives the browser a service cookie thor.sid.

What is stored in the browser​

  • The thor.sid cookie is a signed session identifier. It is not available to scripts on the page (HttpOnly) and is tied to the site (SameSite=Lax). The password is not stored in it.
  • The chosen interface theme and language, and some display settings (for example, a collapsed board panel).

Password​

  • The password is changed only in Keycloak. There is no password field in the Assist profile.
  • The email address in the Assist profile cannot be changed: it comes from Keycloak. To change the address, contact the administrator.

Sessions​

A session is one sign-in from one browser or device. A session is valid while Keycloak considers the sign-in valid.

  • A user sees and ends their own sessions on the “My sessions” page.
  • The administrator sees the sessions of all users on the “Sessions” page and can end any of them.
  • After a session is ended, the browser loses access immediately. To continue, you must sign in again.
  • The Sign out button closes only the session in the current browser.
Warning

If you worked on someone else's computer or lost a device, end the session on the “My sessions” page from any other device and change the password in Keycloak.

Access permissions​

What a person sees and changes is determined by their role. If a role has no permission for a page, the menu item is hidden and a direct link redirects to “My work”. More: “Roles and access” and the permission matrix.

API keys​

An API key is a password for programs. Rules:

  1. A key acts with the permissions of the role chosen at creation, not all of your permissions.
  2. For a key you can choose your own role or a role with lower priority.
  3. The full token is shown once. Save it immediately in a safe place.
  4. A key can be regenerated (the old token stops working) or revoked.
  5. Keys can be created, regenerated, and revoked only through the interface; a key cannot do this itself.
  6. Do not send the token in messengers and do not store it in a source code repository.

More: “API keys”, “Integrations”.

Notification channel secrets​

Mail passwords, bot tokens, and encryption keys are stored encrypted and are not shown after saving. When editing a transport, leave a secret field empty to keep the current value. More: “Notification transports”.

Action log​

All data changes are recorded in the audit log: who did what and when. The changes of a specific task, release, or project are visible on that record's “History” tab.

Rules for a user​

  1. Do not tell your password to other people.
  2. End your work with the Sign out button on other people's computers.
  3. Once a month, look through “My sessions” and end unfamiliar ones.
  4. Do not create an API key without need, and revoke keys that are no longer needed.
  5. If you suspect a foreign sign-in, end the session, change the password in Keycloak, and tell the administrator.

Rules for an administrator​

  1. Give each role the minimum necessary permissions.
  2. When an employee leaves, disable their profile and end their sessions: “Employee offboarding”.
  3. Periodically check the audit log and the list of API keys.
  4. Do not give the permission to create API keys to all roles.