Summary
Alta's Security settings give an organization owner two controls that work together: Single Sign-On (Okta) routes everyone's login through your IdP, and Domain Claiming binds an email domain to your workspace so users with that domain are forced into your login requirements. This guide walks through both — what to enter, how the DNS verification works, and the failure modes you'll actually see in the UI.
Who this is for
Workspace Owners and Admins responsible for identity, access, and compliance. Both screens live under Settings → Organization Settings → Security.
Before you start
Your Alta plan includes Single Sign-On. The Create / Save button on the SSO form is disabled with the tooltip "Single Sign-On is not part of your plan" if it isn't. If you see that, contact Alta to enable the feature on your plan.
You have an Okta tenant and admin access there. You'll create an Okta OIDC app and copy three values into Alta: Client ID, Okta Domain, Client Secret.
For Domain Claiming, you have access to the DNS records for the email domain you want to claim (you'll add a TXT record).
Where to find Security settings
Open Settings.
Go to Organization Settings → Security.
The page has two tabs at the top: Single Sign-On and Domain Claiming. SSO is selected by default.
Part 1 — Configure Okta Single Sign-On
Alta currently supports Okta as an OIDC provider. The card on this tab reads Okta Single Sign-On and shows a status badge once configured: Enabled (green) or Disabled (yellow).
Step 1 — Create the Okta OIDC app
In Okta, create a new app integration of type OIDC — OpenID Connect, application type Web Application.
Set the sign-in redirect URI to the value provided by Alta in the SSO setup screen (ask Alta support if it isn't visible to you yet).
Save the app. Okta gives you a Client ID and Client Secret — copy them somewhere safe.
Note your Okta domain (e.g.
mydomain.okta.com) — you'll paste it as-is.
Step 2 — Fill in the Alta form
Client ID (required). Paste the Client ID from your Okta app. If you submit without it, you'll see "Client ID is required".
Okta Domain (required). The full host, e.g.
mydomain.okta.com. This is locked after the connection is created — you can't change the domain later from the UI; you'd have to delete the connection and recreate it. Missing value shows "Domain is required".Client Secret (required). Paste it. Once saved, the field switches to a password input so the secret isn't shown back to you. Missing value shows "Client Secret is required".
Click Create. You'll see the toast "SSO Connection created successfully". The card now shows the Enabled/Disabled badge and an actions menu.
Step 3 — Edit, enable/disable, or delete the connection
After the connection exists, the button label changes from Create to Save. You can update Client ID and Client Secret at any time; Okta Domain stays locked. Saving fires the "SSO Connection updated successfully" toast on success or "Error updating SSO Connection" on failure.
Use the actions menu on the card (top-right) to enable, disable, or remove the connection.
Part 2 — Claim a domain (enforce login requirements)
Switch to the Domain Claiming tab. The intro text on the screen says it best: "Claim a domain and enforce the login requirements for all users with email from that domain." Once a domain is verified, anyone signing up or logging in with an email at that domain gets routed through whatever sign-in policy your workspace requires (e.g. Okta SSO).
Step 1 — Add a domain
On the Domain Claiming tab, click + Claim Domain in the top-right.
Enter the email domain you control (e.g.
acme.com) and submit. The new row appears in the table with three columns: Domain Name, Status, Verification Token. Status starts as Pending.
Step 2 — Add the TXT record at your DNS provider
From the intro: "To complete the process of claiming a domain, you will need to add a TXT record to the domain's DNS records with the provided verification key. Consult your DNS provider for instructions."
Copy the value from the Verification Token column.
In your DNS provider (Cloudflare, Route53, GoDaddy, etc.), add a new TXT record on the apex of the domain with the verification token as the value. Save.
Wait for DNS to propagate (usually minutes; sometimes longer depending on TTL).
Step 3 — Verify
Alta runs a periodic check that will flip the row to Verified on its own once the TXT record is visible. If you don't want to wait, click the refresh icon next to the Pending status to force an immediate verification check.
Success toast: "Domain verified successfully".
Failure toast: "Error verifying domain" — the TXT record isn't visible yet, or the value doesn't match. Re-check the record in your DNS provider, wait a few minutes, then try the refresh button again.
Tips and common pitfalls
The Create / Save button is disabled. Hover it — if the tooltip says "Single Sign-On is not part of your plan", this is an entitlement issue, not a config issue. Reach out to Alta to enable SSO on your plan.
I need to switch IdP tenants. Because Okta Domain is locked after creation, you can't repoint an existing connection at a new Okta tenant from the form. Delete the connection from the actions menu, then create a new one with the new domain.
Client Secret looks empty after I save. Expected — once a connection exists, the Client Secret field is rendered as a password input and the saved value isn't readable back. Type a new one and click Save if you need to rotate it.
Domain stays Pending forever. The TXT record is either at the wrong host (use the apex domain —
acme.com, notwww.acme.com) or its value doesn't match the Verification Token exactly. Usedig TXT acme.comor your provider's preview to confirm what's actually published, fix the record, then click the refresh icon next to Pending.Two different IdPs in two different orgs. SSO is per-workspace. If your company has multiple Alta workspaces, configure SSO and Domain Claiming separately in each.
Removing a claimed domain. Done from the row's actions in the Domain Claiming table — but think before you click. Removing the claim un-binds the email domain from your workspace's login policy.
Related
