Access to SimpleTwo

Applies to: directory 0.35, directory 0.61 · Checked: 10.10.2026

directory is the organisation's directory. It may hold thousands of accounts that do not need SimpleTwo: contractors, service mailboxes, staff who only use company applications through directory's sign-in. Such an account signs in to the portal /me and to third-party applications (OIDC, SAML, LDAP), but reaches the SimpleTwo services only once it is assigned access.

Features

Access is assigned per feature:

Feature	What it gives	Who provisions it
Chat and calls	messenger, calls, meetings	messaging
Calendar and address books	calendars, invitations, personal books	calendar
Mail	a mailbox, addresses, JMAP and SMTP	mail
Drive	files	drive
Telephony	an internal number and outside calls	the coordinator
Secure Access (VPN)	the SimpleTwo Connect tunnel: routing and gateways by the groups' profile	the coordinator

A feature is assigned to a person or to a directory group, dynamic groups included. A person has a feature when at least one assignment gives it: their own, any of their groups', or the "everyone" option (below). Leaving a group keeps a feature that other assignments give.

Guests, bots, rooms and system accounts belong to the coordinator. Nothing is assigned to them: they reach SimpleTwo as before. The exception is a guest invited through directory in identity mode: the invitation carries its features, chat and calls by default (Guests and bots in directory).

Provisioning state

When a person gets a feature, the service prepares what it needs — a mailbox, a calendar, a chat directory — and reports the result to directory. Each of a person's features has a state:

• pending — assigned, the service has not answered yet;
• active — the service has prepared everything; only from now on does the platform token open that service;
• failed — the last attempt failed, the reason is shown beside it;
• deprovisioning — no longer assigned; the service removes the data under its own retention and reports when it is done.

Calendar

Since directory 0.58.0 the calendar neither reads directory's assignments nor reports to it: every person has a calendar and an address book, and they are made by steps of the coordinator's tasks ("Current tasks"), not by the service on its own. Creating a user gives them the default calendar and the personal address book "Contacts" (a room gets its booking calendar); blocking closes their calendars and books (everything is kept), unblocking opens them. Deleting the user or withdrawing the calendar closes access at once, and after 30 days (the calendar role's "Keep withdrawn" parameter, the variable DIR_CAL_DEPROVISION_RETENTION_DAYS) the service deletes their calendars with their entries, their address books, invitations, profile and links; the meetings they organised leave the participants' calendars as cancelled ones. If the person comes back before that, everything opens again as it was.

A person with no calendar yet is refused ("this account has no calendar yet"), and inviting them to a meeting is not saved and names them — the service no longer makes a calendar by itself on a first invitation or sign-in. The coordinator's system reconciliation creates what is missing. The state is in the service's /healthz, under lifecycle: how many people are open, blocked, withdrawn, deleted and purged. The assignment and state of "Calendar and address books" here, in directory, no longer affect the calendar.

Secure Access

Since directory 0.61.0 and coordinator 0.9.x the VPN is a feature too (secure_access). Provisioning it is a step of a coordinator task: "Grant Secure Access" writes a mark in the person's account that Secure Access is granted — and nothing else. The routing and the allowed gateways still come from the routing profile bound to groups and roles; changes to groups and profiles apply at once. A block suspends the mark, an unblock resumes it, withdrawing the feature drops the mark and closes the person's tunnels at once, and deleting the person takes the mark with the account. The coordinator's system reconcile writes missing marks.

Without the mark the app gets neither rules nor a tunnel session: the coordinator answers 403 with the code secure_access_not_provisioned, and the app says "Secure Access is not granted to you — contact your administrator". The coordinator's guests get the mark at creation (their role and groups decide their VPN); bots and rooms need no VPN.

Rollout. The day the directory first knows the feature it gives it once, by itself, to everybody who reaches SimpleTwo: it switches "Everyone gets Secure Access" on (Policies → "Access to SimpleTwo") when provisioning is off or "everyone" already grants something, and with provisioning on and an empty "everyone" it assigns the feature directly to each account that has any feature. So nobody who works loses the VPN. To grant the VPN by groups, clear the box and assign the feature to groups. A coordinator working with a directory older than 0.61.0 (which does not know the feature) treats everybody as having Secure Access.

The personal tunnel profile (uTLS, QUIC, DNS, MTU — the "user" level) is now kept in the account: shown and edited on the person's card in the coordinator console ("Secure Access" in the edit dialog) and deleted with it. The global, group and device profiles stay as before.

Chat and calls

The messaging service reads the assignments of "Chat and calls" the same way, about every half minute. On an assignment it gives the person a chat account (unless the coordinator has passed one already) and seats them in the default conversations of the groups they are in, then reports active, or failed with the reason. When the assignment is withdrawn while provisioning is on, the person is disabled at once: the apps no longer let them into chat and calls, open connections close, their phones stop receiving notifications, and they drop out of expert search. The data is kept. After 30 days (the messaging role's "Keep withdrawn" parameter, the variable MSG_DEPROVISION_RETENTION_DAYS) the service deletes what served only them: personal bots and assistants, phone registrations, contacts, blocks, presence subscriptions, drafts, Saved messages and their seats in groups, channels and meeting chats. Groups and channels they own stay theirs until an administrator hands them over. One-to-one conversations with colleagues and the messages and files they wrote in conversations stay — they are the conversation's history, with its own retention (MSG_RETENTION_DAYS). Only then does the feature leave "deprovisioning". If the assignment comes back before that, the person signs in to chat again and their phone registers for notifications at the next sign-in. While provisioning is off the service disables and deletes nothing; switching it on starts the 30 days afresh. The state is in the service's /healthz, under provisioning.

Where it is in the console

In the console:

• Users → People → a person → "Access to SimpleTwo" — every feature: whether the person has it, through what (directly, a group, everyone), its state, its error. Grant and Withdraw manage the direct assignment. Below: the services this person's platform token opens.
• Users → Groups → "Access to SimpleTwo" — a tick for each feature granted to the group.
• Security → Sign-in requirements → "Access to SimpleTwo" — the switch, the "everyone" option and the counts by state.

Every grant, withdrawal, change of the setting and service report is written to the security event log.

The switch

Provisioning is off by default: every account reaches every service, as before this feature. Assignments and states are kept while it is off, so they can be prepared in advance. While it is off, no service deprovisions anything.

Once it is on:

• the coordinator lists in its directory, and creates, only accounts that are assigned something;
• the platform token opens directory, the coordinator and only the services where the feature is active;
• for people who are assigned nothing, messaging and calendar go to deprovisioning: while provisioning was off, those services served everyone, so they may hold data.

Migration: "everyone gets messaging and calendar"

The "Everyone gets messaging and calendar" option gives every person chat, calls, calendar and address books without separate assignments. The order for a running installation:

1. Tick the option and save, without switching on.
2. Assign mail, drive and telephony to the groups that need them.
3. Switch provisioning on. Nobody loses anything.
4. Later, untick the option and move to group assignments.

What the coordinator does with accounts that have nothing

The coordinator removes an account that has no assignments left from its directory not at once but after a grace period (14 days by default, configurable), and only when the person's data is nowhere:

• they never signed in, hold no roles granted in the coordinator's console, and sponsor no guests;
• no service holds their data: no feature is active, failed or deprovisioning.

Everyone else stays, and the coordinator writes the reason to its log. The account stays in directory in every case.

For service developers

• GET /v1/provisioning/feed?since=&limit=&feature= — rows by cursor, oldest first: seq, feature, username, assigned, state, changed_at, and mode. Any service reads it with its service token.
• POST /v1/provisioning/{feature}/{username}/state with {seq, state, error} — the report of the service that owns the feature: active, failed (with the reason) or deprovisioned. A report on an outdated seq is refused with 409.