Administration and sign-in
Roles, MFA, single sign-on, tenant policies and API keys.
Each customer company is a tenant, run by its own admins. They manage members, sign-in, policy and automation; the platform operators who run the service can't read any tenant's files.
Roles
| Role | Who | Can |
|---|---|---|
| Member | Any employee of the customer | Send transfers and create upload requests; see and revoke their own; download files delivered to their own upload requests; see DLP findings on their own files and confirm a warning |
| Tenant admin | IT or security staff at the customer | Manage members, tenant policy and the DLP policy, and name approvers; see and revoke every transfer and upload request in the tenant; search and export the audit log; manage API keys. Sees metadata and DLP finding counts, never file contents. |
| Platform operator | The team running the service | Provision tenants and operate the platform. No access to file contents in normal operation. |
Approver is a designation, not a separate role. A tenant admin names members or admins as DLP approvers, who approve or reject transfers that need approval, never their own (see Data loss prevention).
There is no self-service sign-up. A platform operator creates each tenant and its first admin through an operator API or CLI (FR-34).
Members
A tenant admin invites members, deactivates them and assigns the admin or member role (FR-22).
- Inviting. A member without SSO gets an email invitation, then chooses a password and enrols a second factor at first sign-in. An SSO member gets a one-time link, valid for 7 days, that binds their identity provider account. An address can hold a non-SSO sign-in for one tenant only.
- Deactivating. In one transaction, the member is deactivated, every session of theirs ends and every API key they own is revoked. Their next request from any browser is refused.
- Signing out. An admin can end every session of a member without deactivating them, for example after a lost laptop.
- Lost factor. An admin resets the member's sign-in, which removes old credentials and sends a new invitation.
Deactivations, forced sign-outs and resets are security-critical records, archived in both regions before the change is confirmed.
Sign-in
Multi-factor authentication
Members and admins always sign in with multi-factor authentication (FR-25), through Amazon Cognito (ADR-0016): an authenticator app (TOTP) or a passkey. SMS and email codes are off, because SMS invites SIM-swap attacks and email is already the recovery channel. Passwords are at least 15 characters; breached passwords are refused.
Cognito handles sign-in only. The service then keeps its own session: 30 minutes idle, 12 hours at most. Sensitive operations, such as exporting the audit log or inviting a user, need a sign-in within the last 15 minutes.
Single sign-on
A tenant can sign in through its own identity provider over OIDC or SAML (FR-26), federated through Cognito. The service never parses SAML or sees a password.
- The tenant admin asks for SSO, and the tenant proves each email domain with a DNS TXT record.
- An operator sets up the provider and records the configuration.
- The tenant admin confirms that their identity provider enforces MFA, and that confirmation is audited. Cognito's MFA doesn't apply to federated users, so the tenant's provider carries that duty.
A tenant can then require SSO for all members, and keep up to two fallback admins with a local sign-in for when its identity provider breaks.
Tenant policies
| Policy | Options |
|---|---|
| Longest allowed expiry (FR-23) | Up to 30 days |
| Unscannable files (FR-23) | Blocked by default, or allowed with a warning to whoever downloads them |
| Retention of received files (FR-23) | 1 to 90 days, 30 by default |
| Allowed and blocked recipient domains (FR-24) | Checked when a transfer is created and again when it is sent |
| Trusted recipient domains (FR-45) | The company's own and partners' domains, used by DLP rules |
| DLP policy | Rules, keyword lists and patterns, approvers, approval timeout, monitor or enforce mode |
Every DLP policy change is emailed to the tenant's admins and recorded in the audit log.
API keys
Tenant-scoped API keys let automation create transfers or export the audit log (FR-32).
- Creation by a tenant admin in the web app. The key is shown once; only its hash is stored.
- Scopes are chosen at creation and never changed: read or write transfers, read or write upload requests, and read the audit log.
- Expiry is 90 days by default, at most 365. The owner and admins are emailed 14 and 3 days before. A tenant holds at most 25 active keys.
- Restrictions. A key can never read file contents, manage users, policy or keys, or make a DLP decision, so every confirmation and approval on record belongs to a person.
- Audit. Every call is audited. Deactivating or demoting a key's owner revokes it.
Operators and break-glass
Platform operators can't read file contents during normal operation (FR-35). This is enforced by policy, not procedure: storage and key policies allow reads only by the service's own workloads and the break-glass role, operators have no shell into application pods, and the operator API never returns file names, messages or contents.
For emergencies, break-glass access works like this:
- The operator states the incident, the reason and the tenants concerned.
- A second operator approves. The grant is removed automatically after 1 hour, and each session lasts at most 1 hour.
- On-call is paged and every operator emailed within 5 minutes. Each affected tenant's audit log records the access.
- An after-action review within 2 business days compares what was read with the approved scope.
The reference run has a single operator, so self-approval is allowed; it still alerts and is an accepted risk.
Languages
Recipient and uploader pages and all emails are available in English and Japanese in v1 (FR-33). The managed sign-in page is offered in both languages too.
Source: PRD, ADR-0016, Authentication and authorization, Architecture