> For the complete documentation index, see [llms.txt](https://docs.monolithforensics.com/monolith/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.monolithforensics.com/monolith/deployment-and-security/cloud-security/single-sign-on-sso.md). # Single Sign On (SSO) ### What Is Single Sign-On? Single Sign-On, or **SSO**, allows users to authenticate to Monolith using their organization's existing identity provider instead of Monolith's standard email, password, and two-factor authentication workflow. For example, an organization using Microsoft Entra ID may configure users to authenticate with their existing organizational credentials before being redirected back into Monolith. SSO can help organizations align Monolith access with existing identity management, authentication, and account security policies. ### SAML 2.0 Monolith SSO uses the **SAML 2.0** standard to exchange authentication information between Monolith and your organization's identity provider. SAML allows the identity provider to authenticate the user and send Monolith the information needed to identify the corresponding Monolith account. ### Identity Provider and Service Provider Two common terms used during SSO configuration are **Identity Provider** and **Service Provider**. #### Identity Provider The **Identity Provider**, or IdP, is the system your organization uses to authenticate users and manage access to applications. Common identity providers include Microsoft Entra ID, Okta, and other SAML-compatible identity platforms. #### Service Provider The **Service Provider**, or SP, is the application that relies on the Identity Provider for authentication. For this integration: * Your organization's identity platform is the **Identity Provider** * Monolith is the **Service Provider** ### Multi-Factor Authentication When a user authenticates to Monolith through SSO, authentication requirements such as Multi-Factor Authentication are managed by the Identity Provider. Monolith's built-in 2FA workflow is therefore not used as part of an SSO-authenticated login. Your organization can apply its own MFA, conditional access, device, network, or other authentication policies through the Identity Provider. ### SSO Sessions After successful SSO authentication, Monolith creates an application session for the authenticated user. The user can then work in Monolith normally until the session expires or the user signs out. ### SSO Setup and Configuration SSO setup requires coordination between your organization's identity or IT administrator and Monolith Support. Monolith will provide the Service Provider information required to configure the SAML application in your Identity Provider. This generally includes values such as: * **ACS URL / Reply URL:** The Monolith endpoint where the Identity Provider sends the SAML authentication response * **Service Provider Entity ID:** The unique identifier representing Monolith in the SAML configuration These values are specific to your Monolith environment and should be provided by Monolith Support during setup. Your organization will provide the corresponding Identity Provider information needed by Monolith. This commonly includes: * Identity Provider Entity ID / Issuer * Single Sign-On URL * X.509 signing certificate * SAML metadata, when available After both sides are configured, Monolith Support will coordinate testing with your organization's IT team before SSO is used for normal access. ### User Identification Monolith must be able to identify the authenticated user from the SAML response. The user's email address is typically provided through the SAML **NameID** or an email-related SAML attribute. The value returned by the Identity Provider must correspond to the email address associated with the user's Monolith account. If your organization uses aliases or another identifier in its Identity Provider, additional attribute mapping may be required during configuration. ### User Accounts SSO authenticates the user but does not replace the Monolith user record. Users must still have an active Monolith account with an email address that can be matched to the identity returned by the Identity Provider. User accounts and access are managed under **Organization > Team Management**. ### Relay SSO Organizations using Relay can also configure SSO for Relay users. Monolith and Relay are separate applications, so SSO configuration for the main Monolith application does not automatically configure SSO for Relay. If your organization wants to use SSO with both applications, coordinate both configurations with Monolith Support. See **Relay Administration** for additional information about Relay access and authentication. ### Troubleshooting SSO If a user cannot sign in through SSO, confirm that: * The user has an active Monolith account * The email or identifier returned by the Identity Provider matches the Monolith user * The correct Monolith environment is being used * The SAML application contains the correct ACS URL * The Service Provider Entity ID matches the value provided by Monolith * The user is permitted to access the Monolith application through the Identity Provider Authentication errors involving reply URLs, Entity IDs, certificates, or SAML attributes may require coordination between your IT administrator and Monolith Support. ### Support To configure or troubleshoot SSO for Monolith or Relay, contact . ### Related Documentation * [**Cloud Security**](/monolith/deployment-and-security/cloud-security.md) * [**Security Overview**](/monolith/deployment-and-security/cloud-security/security-overview.md) * [**Login & 2FA**](/monolith/start-here/welcome-to-monolith/login-and-2fa.md) * [**Team Management**](/monolith/using-monolith/organization/team-management.md) * [**Relay Administration**](/monolith/relay-request-portal/relay-overview/relay-administration.md)