Organizations and SSO
Everything on the hosted service belongs to an organization: calibration profiles, monitors, provider connections, API keys, telemetry, data settings and alert rules. Each account starts with a personal organization; teams create shared ones and invite people into them. Switch between your organizations with the switcher in the dashboard sidebar.
Roles and permissions
| Permission | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
evaluate: call evaluate, read jobs | Yes | Yes | Yes | |
profiles:read: read profiles, monitors, alerts, audits | Yes | Yes | Yes | Yes |
profiles:write: create and change profiles, examples, outcomes, audits, monitors | Yes | Yes | Yes | |
telemetry:read: Observability pages and the events read API | Yes | Yes | Yes | Yes |
events:write: guard events and OTLP ingest | Yes | Yes | Yes | |
backends:read: list providers and access levels | Yes | Yes | Yes | Yes |
connections:read: see provider connections | Yes | Yes | Yes | Yes |
connections:manage: add, test and delete connections | Yes | Yes | ||
telemetry:manage: data settings, alert rules and channels, OTLP destinations | Yes | Yes |
Beyond the table:
- Owners and admins invite people, change roles and remove members; only an owner can make someone an owner, and an organization always keeps at least one owner. Anyone can leave an organization.
- Only an owner can delete the organization’s telemetry.
- Owners and admins configure single sign-on, and only they can switch a zero-retention profile back to standard retention.
- Viewers are read-only everywhere.
A dashboard action your role does not allow fails with 403 forbidden_role.
API key scopes
An API key works in the organization it was created in, with the scopes
chosen when it was created: evaluate, profiles:write, telemetry:read
and events:write (what each grants).
New keys default to evaluate profiles:write.
A key can never do more than its creator: its effective scopes are its own
scopes intersected with what the creator’s role allows right now. A
viewer can create only telemetry:read keys; demoting a member to viewer
reduces their existing keys to telemetry:read on the next request; and
removing a person from the organization disables every key they created
(401 key_owner_removed). Rotate keys owned by people who leave before
you remove them, so your services keep running.
Invitations
Owners and admins invite people from Members. An invitation is a link, valid for 7 days, that grants one role; optionally it is restricted to one email address. Copy the link and send it yourself: the service does not send email. Pending invitations can be revoked, and accepted, created and revoked invitations are recorded in the audit log.
Single sign-on
Single sign-on uses OpenID Connect (the authorization code flow with PKCE) and is configured per organization, by an owner or admin, under Members > Single sign-on. It is available for team organizations, not personal ones. SAML identity providers work through an OIDC bridge in the IdP; SCIM provisioning is not supported.
| Setting | Meaning |
|---|---|
| Issuer | The identity provider’s https issuer URL. The service reads its /.well-known/openid-configuration and checks that ID tokens come from this issuer |
| Client id, client secret | From the application you register in the IdP (the secret is optional if the application has none). The secret is encrypted and never shown again |
| Redirect URI | Register https://cci.gitdate.ink/api/auth/sso/callback in the IdP |
| Enabled | Turns SSO sign-in on or off for the organization |
| Enforce SSO | Members other than owners whose email is at one of the organization’s verified domains must sign in through SSO; their password sign-in is refused. Owners keep password sign-in, so the organization cannot be locked out, and members with other email domains are not affected |
| Provisioning domains (JIT) | Up to 20 email domains, each verified with a DNS TXT record (below). A person from a verified domain who signs in through SSO for the first time gets an account and a membership. Shared mailbox providers cannot be used, and a domain can be claimed by one organization only |
| Default role | The role given to people provisioned this way: admin, member (the default) or viewer |
Verifying a domain
When you save a new provisioning domain, the service asks you to publish a TXT record proving that your organization controls it:
| Type | Name | Value |
|---|---|---|
| TXT | _cci-verification.<your domain> | cci-verification=<token shown when you save> |
Add the record at your DNS provider, wait for it to propagate, and save again. The token is specific to your organization and domain.
Signing in and linking accounts
People sign in with Sign in with SSO on the login page, using their work email. An existing account is linked to an SSO identity only when its email is at one of the organization’s verified domains, or when the person is signed in with their password at that moment and chooses Sign in with SSO themselves. It is never linked on membership or on the email address the identity provider reports alone, because an organization’s admins control which identity provider it trusts. Someone whose domain is not a verified provisioning domain, and who has not linked their account, is refused.
Okta
Create the application
In the Okta admin console: Applications > Create App Integration, choose OIDC - OpenID Connect and Web Application.
Set the redirect URI
Add https://cci.gitdate.ink/api/auth/sso/callback as a sign-in redirect
URI, keep the Authorization Code grant, and assign the people or
groups who should have access.
Copy the values
The issuer is your Okta domain, for example https://acme.okta.com (or
https://acme.okta.com/oauth2/default for a custom authorization server).
Copy the client id and client secret into Members > Single sign-on.
Microsoft Entra ID
Register the application
In the Entra admin center: App registrations > New registration. Add a
Web redirect URI: https://cci.gitdate.ink/api/auth/sso/callback.
Create a secret
Under Certificates & secrets, create a client secret and copy its value. The client id is the Application (client) ID.
Set the issuer
The issuer is https://login.microsoftonline.com/<tenant id>/v2.0. Make
sure ID tokens carry the user’s email (add the email optional claim if
your tenant does not include it).
Google Workspace
Create the OAuth client
In the Google Cloud console for your Workspace’s project: APIs & Services > Credentials > Create credentials > OAuth client ID, type Web application. Configure the OAuth consent screen as Internal so only your Workspace accounts can use it.
Set the redirect URI
Add https://cci.gitdate.ink/api/auth/sso/callback as an authorized
redirect URI.
Copy the values
The issuer is https://accounts.google.com. Copy the client id and client
secret into Members > Single sign-on, and add your Workspace domain as a
provisioning domain if new colleagues should get accounts on first sign-in.
Turn on Enforce SSO only after one non-owner account has signed in through SSO successfully. Enforcement refuses password sign-in at once for every admin, member and viewer whose email is at a verified domain.
Audit log
Observability > Audit log lists actions taken in the dashboard, with the person, the time and the details of each change:
| Area | Actions |
|---|---|
| Sign-in | auth.login, auth.login_failed, auth.sso_login, auth.logout, auth.register, auth.password_changed, auth.password_change_failed |
| API keys | api_key.created, api_key.revoked |
| Provider connections | connection.created, connection.updated, connection.tested, connection.default_set, connection.deleted |
| Members | invitation.created, invitation.accepted, invitation.revoked, member.role_changed, member.removed, member.left |
| Organization | org.created, org.renamed, sso.config_updated, sso.config_deleted |
| Data | settings.observability_updated, telemetry.purged |
| Alerts and export | alert_rule.*, alert_channel.* (created, updated, deleted; channels also tested), otlp_destination.* (created, updated, tested, deleted) |
| Views | saved_view.created, saved_view.updated, saved_view.deleted |
API calls themselves are not audit-log entries: each one is a request record in Observability, with the API key that made it.