Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.metabind.ai/llms.txt

Use this file to discover all available pages before exploring further.

Metabind supports SAML 2.0 single sign-on for organizations on the Enterprise plan. Once connected, your identity provider (IdP) — Okta, Azure AD, Google Workspace, OneLogin, JumpCloud, or any other SAML 2.0–compliant IdP — provisions and manages Metabind organization membership. SSO is configured by the Metabind team on your behalf. There is no self-serve setup screen in MCP App Studio today: Enterprise customers work with their Metabind contact to exchange SAML metadata, define group-to-role mappings, and enable enforcement.

​
What SSO gives you

  • Single sign-on. Members log in to MCP App Studio through your IdP — no separate Metabind passwords.
  • Provisioning. Adding a user to a Metabind group in your IdP automatically grants organization access.
  • Deprovisioning. Removing a user from your IdP automatically revokes their Metabind access on next session check.
  • Group → role mapping. Your IdP’s groups can map to organization roles (Admin, Member).

​
Prerequisites

  • Enterprise plan.
  • Organization Owner role on the Metabind side.
  • Admin access to your IdP.

​
How to request SSO setup

Contact your Metabind account contact (or support@metabind.ai) with:
  • The IdP you use (Okta, Azure AD, Google Workspace, etc.).
  • The Metabind organization slug.
  • The IdP groups you want to map to Metabind roles.
  • Any non-default SAML attribute names for email, display name, or groups.
The Metabind team will then:
  1. Send you the Service Provider (SP) values to add to your IdP — SP Entity ID, ACS (Assertion Consumer Service) URL, and sign-in URL.
  2. Receive your IdP’s Identity Provider (IdP) values back — IdP Entity ID, SSO URL, signing certificate.
  3. Configure attribute mapping and group → role mapping per the spec you provided.
  4. Run a SAML round trip with you to verify the configuration.
  5. Enable SSO for your organization once the round trip passes.
After enablement, every member of your organization logs in via SSO going forward.

​
Attribute mapping

Metabind reads these attributes from the SAML assertion:
Metabind fieldSAML attribute (default)Required
Emailemail or mail or NameIDyes
Namename or displayNamerecommended
Groupsgroups or memberOfrequired for group → role mapping
If your IdP uses different attribute names, mention the mapping when you request SSO setup. The Metabind team configures it server-side.

​
Group → role mapping

When you request SSO, share the IdP groups that should map to each Metabind role. A typical setup:
IdP groupMetabind role
metabind-adminsOrganization Admin
metabind-membersOrganization Member
metabind-billingBilling-only role (if applicable)
A user in multiple mapped groups gets the highest role. Users who don’t match any mapped group don’t get organization access — they’ll see “Not authorized” when they try to log in.

​
Just-in-time (JIT) provisioning

JIT is the only provisioning mode today: when a SAML-authenticated user logs in for the first time, Metabind creates their account using attributes from the assertion. There is no pre-provisioning step — users appear in your organization on their first successful SSO login. Group mappings (above) decide what role the new account gets. If a user logs in but matches no mapped group, the login is rejected.

​
Deprovisioning

When you remove a user from the relevant Metabind groups in your IdP, the next time their session is checked Metabind treats them as no longer authorized. They lose access on next request, not on the spot — there is no real-time push from the IdP today. To force immediate revocation, remove the user from your Metabind organization in Settings → Team.

​
Project access

SSO controls organization membership and the organization role each user lands with. Organization role grants access to every project in the organization, so the SSO group → role mapping above is the access-control surface SSO touches.

​
SAML strict mode

To enforce SAML-only login (disable password fallback for everyone except the recovery account), tell your Metabind contact. Once enforced:
  • Members must log in via SAML.
  • Programmatic access continues to work via API keys (read-only) and JWT-based REST API (see Team management: API keys vs. JWT login).
  • Organization Owners retain a recovery login path so the org isn’t locked out if the IdP becomes unreachable.

​
Logout

SAML logout (SLO) is supported when configured. When a user logs out from any SLO-aware service in your IdP, Metabind sessions are invalidated. Without SLO, Metabind sessions expire on their own clock (24h default for MCP App Studio). Custom session lengths are available on the Enterprise plan — request the change through your Metabind contact.

​
Recovery and break-glass

If the IdP becomes unreachable or misconfigured:
  • Organization Owners retain a recovery login path. The recovery URL and recovery codes are issued by the Metabind team when SSO is enabled — store them in your secret manager.
  • To temporarily disable enforcement while you fix the IdP config, contact your Metabind contact (or support@metabind.ai).

​
Troubleshooting

SymptomLikely cause
”SAML response invalid” on loginClock skew between IdP and Metabind, or signing certificate mismatch
User logs in but sees “Not authorized”No group mapping matched; check attribute names and groups
User created but missing nameAttribute mapping for name is wrong
Logout from IdP doesn’t end Metabind sessionSLO not configured
If something looks wrong, share the timestamp and (where available) the SAML response with your Metabind contact. The Metabind team can replay the assertion server-side and surface mismatches.

Team management

Organization and project roles.

Audit logs

Login events and team changes are audited.

Rate limiting

Per-token and per-project limits.

Schema validation

Server-side gates on tool calls.