How SAML Identity Providers Connect Your Team's Apps

A new teammate needs access to several apps. An identity provider lets your organization manage that access from its existing sign-in system, instead of setting up a separate password for every service. SAML is one way the apps and identity provider exchange the information needed for single sign-on (SSO).

MailSlurp enterprise accounts support SAML SSO, so your team can sign in through its identity provider and use the roles configured for your MailSlurp organization.

What is an IdP identity provider

An identity provider, or IdP, authenticates users and supplies identity information to connected applications. Microsoft Entra ID, Okta, OneLogin and Auth0 are examples. The application receiving that information is the service provider, or SP; MailSlurp takes that role in a MailSlurp SSO connection.

What is SAML

SAML stands for Security Assertion Markup Language. It uses XML assertions to exchange authentication, attribute and authorization information. In a browser SSO flow, the service provider uses the assertion to identify the signed-in user. The OASIS SAML technical overview explains the standard and its participants.

For a MailSlurp connection, an administrator creates a SAML 2.0 application in the IdP, configures the organization's SAML settings and assigns users through the IdP. The SSO setup guide walks through the required values, including the issuer, entrypoint and X.509 certificate.

Connect the identity provider your team uses

Start with the IdP that already manages your team's accounts. Check how it assigns users to applications and which attributes it sends in the SAML assertion. Those values determine how you can map its users and groups to application roles.

For Okta, follow the MailSlurp SAML setup walkthrough. It covers the application connection, email address mapping, certificate and organization login.

Microsoft Entra ID roles and groups

MailSlurp can map Microsoft Entra app-role values or group IDs from SAML claims to MailSlurp roles. The role-mapping guide explains the claim names and exact-value matching. Check the values actually sent by your IdP before adding a mapping.

Check the account and permissions after sign-in

Use a designated test user assigned to the MailSlurp application in your IdP. Sign in through the organization's SAML login page and confirm that the user reaches the expected organization with the intended role.

Try an action that role should allow and one it should deny. Also check the default-role behavior for a new user whose claims do not match a configured mapping. A successful login alone doesn't tell you whether the user has the right access.

If your own application sends an invitation or recovery email around this process, test that message separately: receive it in a MailSlurp inbox, follow the link and check the resulting account. Keep that email check alongside the SSO test so failures point to the part of the sign-in flow that needs attention.