Skip to content

6.2.2.1 User

6.2.2.1.1 Purpose

A User is anyone who acts inside an Organization: a person or a service account, a program that calls our API on the Organization's behalf. Both receive roles in the same way, through memberships, and every change they make to data is recorded under their name in a write commit. They are separate from Moonitoring users, who run the platform itself.

6.2.2.1.2 Questions it answers

  • Who is this person or service account, and how do we contact them?
  • In which Organizations can this user operate, and with which roles?
  • Who is responsible for a service account, and when was it last used?
  • Is the account still active, or has it been disabled?

6.2.2.1.3 Fields

Field Type Cardinality Description
id string (uuid) 1..1 Key.
disabled_at datetime 0..1
created_at datetime 1..1
updated_at datetime 1..1

6.2.2.1.4 Subtypes

Discriminator type: every User is exactly one of the subtypes below (disjoint and complete).

Person

Field Type Cardinality Description
name string 1..1
surname string 1..1
email string (regex) 1..1 Unique.
telephone_number Telephone 1..1
identity_subject string 1..1 Unique.
The user id of Identity Platform the Person signs in with. Sign-in matches on it, never on the e-mail, which can change: a verified e-mail that changed at Identity Platform updates email at the next sign-in.
locale enum 1..1 Values: it, en. Default: it.
The language of the apps and of the e-mails sent to the Person.

ServiceAccount

A software client of an Organization that calls our API (e.g. a cooperative's system).

Field Type Cardinality Description
organization Organization 1..1 It belongs to one Organization and can hold roles only there (DirectMembership); it is never delegated.
Its roles hold no admin capability (OrganizationRoleCapabilityEnum): a ServiceAccount reads and writes data but never changes who can act in the Organization or where its data goes. The Sync Client role (sync_client) is given only to the ServiceAccount a farm sync client becomes at enrolment.
description string 1..1
owner Person 1..1 The person responsible for it.
credential_ref string 1..1 Reference to the credential in the secret manager. Secrets and keys never enter the database.
The secret is named access-sa-<id>, after the ServiceAccount: every secret name starts with the system that owns it.
last_used_at datetime 0..1
registered_by string 0..1 The Google service account of the system that registered it through RegisterServiceAccount, e.g. farm for a sync client; empty when it was created through the API. Only that system may disable it.

6.2.2.1.5 Relationships

References

Referenced by

Uses types

Telephone

Subtypes

6.2.2.1.6 Rules & constraints

  • Who acts in an Organization: a person or a service account. Roles are given to both in the same way (OrganizationAccessControlMembership).
  • Fresh sign-in: every token of a Person carries auth_time, the time of their last real sign-in at.
  • Identity Platform, unchanged along the refresh chain. Sensitive actions (closing an Organization, transferring its ownership, rotating a ServiceAccount credential) require it to be at most five minutes old, as Google's "verify it's you" and GitHub's sudo mode do. So does every write that needs an admin capability of OrganizationRoleCapabilityEnum; a read never asks for it, even under an admin capability.
  • Registration: a Person is created only by registering, the first time someone signs in with Identity Platform. The token exchange of an unknown identity_subject answers registration_required; the app then asks for name, surname and telephone, prefilled from the sign-in where it can, and registers them with the same.
  • Identity Platform token and a verified e-mail. Names are never guessed by splitting a display name. Accepting an invitation (OrganizationInvitation) or creating an Organization comes after. Staff are not Persons: they sign in through.
  • Identity-Aware Proxy, hold no refresh token and exchange their identity again every five minutes.
  • Sign-in methods: a Person signs in with e-mail and password or with Google, on the sign-in page of the Account app. Identity Platform handles both, the password reset and the verification of the e-mail of a new account; registration (name, surname, telephone, language) follows as above.
  • A user may belong to no Organization: a person who signed up and was not invited yet, or who left every Organization. They can sign in, manage their own profile and settings, accept an invitation or create an Organization, and nothing else: rights and entitlements always come from an Organization, never from a personal one.
  • To see the Organizations the user can operate in check OrganizationAccessControlMembership.
  • To see the Organizations the user is part of check DirectMembership.
  • Every API call is logged in Cloud Logging with the acting user's id; changes to data are attributed by WriteCommit.