SAML SSO Configuration Guide

Prev Next

App Manager supports SAML-based Single Sign-On (SSO), allowing users to authenticate with your Identity Provider (IdP) to login to App Manager. This guide walks through how to set up SSO using the /saml API, outlines the required SAML response structure, and explains session behavior and troubleshooting steps.

Set Up SSO

Step 1: Provide IdP values to Eleos via API

Use the PUT /saml endpoint to configure the following fields:

  • enabled – Use true to turn SSO on for the relevant environment

  • SSO URL – The redirect/login URL from your IdP

  • Entity ID – Your IdP's unique identifier

  • Certificates – Provide a certificate in PEM format. These are used to validate SAML responses

Full validation rules for these fields are available in the API documentation.

Step 2: Retrieve the App Manager SAML values

After configuring the IdP properties with the API, send a GET /saml request. This will return:

  • ACS URL – Use this as the Assertion Consumer Service URL in your IdP’s configuration page

  • SP Entity ID – Use this as the Service Provider identifier in your IdP configuration page

Step 3: Provide Eleos values to IdP via IdP’s interface:

  1. Create a new SAML application.

  2. Paste in the ACS URL and SP Entity ID returned by the API in Step 2.

  3. Set the NameID format to urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress.

  4. Ensure assertions include:

    • The user’s email in the NameID

    • An AuthnStatement

    • A Conditions element with NotBefore and NotOnOrAfter

    • The correct Issuer matching the Entity ID you submitted

Sign the assertions using the certificates uploaded with the API in Step 1.

Step 4: Test and enable SSO

Before enabling SSO for all users, test your setup using a separate test environment. Once verified, update the /saml API with "enabled": true to enforce SSO for your production environment.

SSO Configuration Requirements

Each App Manager environment supports one SSO provider. The SAML assertion must meet the following requirements:

Required Attributes

  • Email in NameID: The assertion must return the user’s email address in the NameID field. Other identifier formats are not supported

  • AuthnStatement: Most IdPs include this by default. For some providers, you may need to explicitly enable it in the configuration UI

  • Conditions: Must include NotBefore and NotOnOrAfter, as shown below:

<saml:Conditions NotBefore="{ConditionsNotBefore}" NotOnOrAfter="{ConditionsNotOnOrAfter}">
  <saml:AudienceRestriction>
    <saml:Audience>{Audience}</saml:Audience>
  </saml:AudienceRestriction>
</saml:Conditions>
  • Issuer: This must match the IdP’s entity identifier we store via the SAML API

After Enabling SSO

Once SSO is enabled for an environment:

  • All users within that environment must authenticate using SSO

  • Login method is based on environment
    When a user enters their email on the login page, App Manager determines the correct login method based on the environment they were invited to.

    • This distinction is especially relevant for Division Admins who may have access to multiple environments. The login method they are required to login with is based on the environment they are initially invited to.

Session Duration and Timeout

To prevent users from staying authorized indefinitely, App Manager automatically expires sessions and requires reauthentication via the IdP.

Default Behavior

If the SAML response does not include the SessionNotOnOrAfter attribute:

  • The session will expire at midnight Eastern Time on the day after login.
    This helps ensure users are not logged out during active work sessions.

Example

A user logs in at 10:00 AM ET on Monday:

  • Expected expiration: Tuesday at 10:00 AM
    Actual expiration: Midnight ET on Tuesday

Custom Behavior

If your IdP supports it, you may configure a custom session timeout using the SessionNotOnOrAfter attribute. App Manager will honor this value, while still aligning the logout time to midnight ET of the expiration day.

Troubleshooting and Recovery

If your SAML setup fails and prevents all users from logging in:

  1. Contact [email protected]

  2. We will temporarily update the environment to allow username/password login

  3. You can then:

    • Reset your App Manager password

    • Log in to App Manager

    • Fix your SAML configuration

Note: We do not currently support designated recovery accounts. If SSO is enforced and broken, no one will be able to log in without support assistance. You can also perform step 2 yourself by using the PUT /saml API and setting the enabled value to false.