---
title: Domains and enterprise federation
description: How an organization claims a domain it owns, decides how that
  domain's users authenticate, and federates them to its own corporate identity
  provider.
editUrl: true
head: []
template: doc
sidebar:
  order: 1
  label: Overview
  hidden: false
  attrs: {}
pagefind: true
draft: false
---

import { CardGrid, LinkButton, LinkCard } from "@astrojs/starlight/components";

The developer surface on Sudomimus is **organization-based**. An organization owns its applications and sectors, and an organization is also where the enterprise-grade identity features live: claiming the domains you control, deciding how the users on those domains may sign in, and pointing them at your own corporate identity provider.

This section covers that whole story. It builds up in three steps, each independently useful and each the foundation for the next.

## The three steps

| Step | What it is | Who it is for |
|---|---|---|
| **1. Adopt a domain** | Prove you control a domain (`example.com`) via a DNS `TXT` record; the platform binds it exclusively to your organization. | Any organization that owns a domain. |
| **2. Set a login policy** | For users whose email is on that verified domain, decide platform-wide whether logins are allowed, blocked, or forced through SSO. | Organizations that want to govern how their domain's users authenticate. |
| **3. Federate to your IdP** | Register your organization's OIDC identity provider as a connector, then either offer it as a "Sign in with …" button on an application or force a domain's users through it. | Companies and communities that run their own IdP (Entra ID, Okta, Google Workspace, …). |

Each step stands on its own. Adopting a domain is valuable purely as a verified, organization-owned claim. A login policy needs nothing more than a verified domain. Federation adds the IdP. You only go as far down this path as your needs require.

## A note on organizations

Everything here hangs off an **organization** — the multi-tenant container that owns applications, sectors, domains, and connectors. An account becomes an organization **owner** by creating an organization from the With portal. Membership carries a role (`VIEWER` < `ADMIN` < `OWNER`); the mutations in this section are **owner-only**, and several of them — setting a login policy, disabling an organization's domain federation — require the caller to be the organization's **sole** owner, so one co-owner cannot unilaterally change how everyone on a shared domain signs in.

All of these surfaces live in the With portal at [`with.sudomimus.com`](https://with.sudomimus.com).

## Where to go next

<CardGrid>
<LinkCard
    title="Adopt a domain"
    description="Prove DNS control of a domain and bind it exclusively to your organization."
    href="/en-us/domains-federation/adopt-a-domain/"
/>
<LinkCard
    title="Domain login policy"
    description="Allow, block, or force SSO for every user on a verified domain — platform-wide."
    href="/en-us/domains-federation/domain-login-policy/"
/>
<LinkCard
    title="Federation connectors"
    description="Register your organization's OIDC identity provider as a reusable connector."
    href="/en-us/domains-federation/federation-connectors/"
/>
<LinkCard
    title="Sign in with your IdP"
    description="Offer your IdP on an application, or force a domain's users through it."
    href="/en-us/domains-federation/sign-in-with-your-idp/"
/>
</CardGrid>

<LinkButton href="/en-us/domains-federation/adopt-a-domain/" variant="primary" icon="right-arrow">Start by adopting a domain</LinkButton>