Single Sign-On (SAML)
Connect your identity provider so staff sign in to Muin with their work account. Import IdP metadata, test the connection with your own account, then enable it for everyone.
Single sign-on (Settings → Security → Single sign-on) connects Muin to your identity provider, so your team signs in with the work account they already have. Muin is the service provider; your IdP stays the authority on who exists and who has left.
Single sign-on is an Enterprise capability. On any other plan the screen explains what it does and how to get it: it is never hidden.
What you need from your IdP
Your identity provider gives you one of two things, and either is enough:
- the metadata XML (Okta calls it “View SAML setup instructions”; Entra ID calls it “Federation Metadata XML”), or
- a metadata URL we can fetch: worth using, because a re-import later picks up a rotated certificate without you re-pasting anything.
What your IdP needs from Muin
The three values your IdP asks for are shown at the top of the screen, ready to copy, before you have configured anything:
| Your IdP calls it | Muin shows it as |
|---|---|
| Audience / Entity ID | SP Entity ID |
| ACS / Reply URL / Single sign-on URL | ACS URL |
| Single logout URL | SLO URL |
Setting it up
The screen walks four steps and ticks each one from live data, not from a button press.
- Paste your IdP metadata (XML or URL). Muin fills in the entity ID, the sign-on URL, and the signing certificate, and reads the certificate’s expiry date.
- Map attributes: email, first name, last name, and (with directory sync) groups.
- Test the connection with your own account. This runs a real round trip to your IdP and reports five checks: metadata, certificate, signature, email, and account. You cannot enable SSO until a test has passed: an untested configuration locks your whole team out.
- Enable for everyone. Staff can then sign in from the login page with Sign in with your organization.
Claiming your email domains
A configuration claims one or more email domains (for example example.org). That claim is what
lets the login page recognize a work address and send it to your IdP, so a domain belongs to
one workspace only, if another workspace has already claimed it, the save is refused and says
so.
How staff sign in
On the login page they choose Sign in with your organization and enter their work email. Muin looks up the domain and redirects to your IdP. An address with no single sign-on gets a plain inline message and can still sign in with a password: the page never becomes a way to find out whether an account exists.
Certificate rotation
The screen warns you when your IdP’s signing certificate is within 30 days of expiry. You can store a next certificate alongside the current one, so a rotation does not interrupt sign-in. If you supplied a metadata URL, Re-import refreshes the certificate from your IdP directly.
When something goes wrong
A failed sign-in lands on a page that names the reason and what to do: a mismatched signature, an expired assertion, an address at a domain this workspace does not claim. Nothing is silently retried, and the audit log records each attempt.
SAML is for your staff, not your members
Single sign-on covers the people who work in Muin. The public member portal uses a different set of doors entirely: a 6-digit code by email or text, a one-click sign-in link, Continue with Google and Continue with Apple, and there are no member passwords at all. Which of those doors are open is set at Settings → Organization → Member Portal. See Portals and Community Settings.
A Google or Apple member sign-in only succeeds when that account’s email matches a person you already have on file. An unknown address is told it is not in the system rather than being signed in.
Related
- Directory Sync (SCIM): create, update, and deactivate members automatically from the same IdP.
- Audit Logs: every sign-in and configuration change is recorded.
- Security Overview: how SSO fits with MFA, roles and session controls.