Welcome to Mainstay!

If you're not sure if you have an account, please contact your system administrator. You can also contact our team at support@mainstay.com.

Invite Email

Your account was likely created by a system administrator - someone who works at your organization. Administrators can add invite new users on the User Management page. (If you are the system administrator, then your account was created by your Partner Success Manager, a Mainstay employee.)

New users will receive an invitation via email:

Signing In with Email & Password

All user accounts use a first name, last name, and email address, generally your work email for your college or company. When you are first invited, an email is sent to this email address with a one-time link to set a password.

Simply use this email address and password to authenticate.

Note: After 5 failed attempts within any 30-minute period, your account will be locked, and you will need to reset your password. (See below.)

Forgot Password

If you don't remember your password, click Forgot Password? and input your email address. A one-time link to reset your password will be sent to your email address, if it is associated with a user account.

The "Forgot Password" email looks like this:

Signing In with Organization ID

If your organization is configured to use Single Sign-On (SSO), you only need to input the email address associated with your account.

If the email domain (@example.edu or @example.com) is linked to a Mainstay organization, you will be redirected to your organization's SSO page. This may include additional steps, such as multi-factor authentication using SMS, email, or an Authenticator app.

Once you have successfully authenticated, you will be redirected back to Mainstay. If your identity corresponds to an existing user account, you will be logged in as that user. Otherwise, you will be taken back to the log in page.

To configure Single Sign-On, message your Partner Success Manager or support@mainstay.com.

SSO with InCommon

If your organization is a member of the InCommon Federation, you will need to provide your domain and InCommon ID.

SSO with Azure

If your organization uses Azure, follow these steps to set up SSO for Mainstay: https://support.admithub.com/hc/en-us/articles/11238503824269

FAQ for Other SSO Configurations

1.  Does the application support federation via SAML 2.0 ?

   • Yes, the application supports SAML 2.0.

2. Do you support SAML 2.0 via EntraID?
   • Mainstay’s platform supports SSO through Azure which has since been rebranded as EntraID. See this article for details.
3. What claims are needed to be passed over?
   • • Email address is the only required claim. Azure typically uses “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress”.

4. What will be used as the primary or unique identifier?

   • Email address is used as the unique identifier. All other attributes are ignored.

5. How will your system handle the UPN being different than email address?
   • Only email address is used as a unique identifier for access to Mainstay’s platform. All other attributes, including UPN, are ignored after the IdP has verified the user’s credentials.
6. How does your system react when a SAML unique identifier changes?
   • If a user’s email changes, they will have to either create a new account in our system or notify Mainstay support.

7. What is the application’s entity ID?

   • https://app.mainstay.com/

8. Will users visit a configurable landing page or will the selected URL instantly redirect users to sign into the institution's Federation page?
   • Faculty/staff/administrators are directed to the institution's Federation page instantly.

9. How are users provisioned and de-provisioned?

   • Users are provisioned and de-provisioned within the application. See Users.

10. Does your system automatically provision users that do not have a match via SAML?
    • Mainstay’s system does not automatically provision any users. Users must be invited by existing users of the platform.
11. Does your system automatically prune out stale/disabled user accounts?
    • User account is removed from Mainstay’s system at that time of deactivation. All user account information is removed from Mainstay’s system 60 days after termination of contract.

12. How are users authorized to perform work in the application? What is the security model for provisioning user access?

    • An admin user may invite other users through email. Roles and permission levels are also assigned to the new users when sending the invite. Users with administrative access may change the roles and permission levels of existing users within the application. Users with administrative access may also limit other users' access to contacts and conversations with User Groups.

13. Does the application have an inactivity timeout function?

    • The inactivity timeout is set to 90 minutes. Once the 90 minutes mark is hit, users see a modal that starts with a 5 minutes countdown and the end of which users are automatically logged out unless they click the cancel button on this modal.

14. Will the application redirect a user’s web browser to the IDP to terminate the session when a user signs out (e.g., a dedicated sign out URL)?

    • No, a user’s web browser is not redirected to the IDP after signing out of the application. Instead, the user is taken to the Mainstay login page.

15. Can the system make authentication information logs available?

    • Mainstay does not provide authentication information logs.

16. Do you support SCIM provisioning?

    • No.

17. What needs to be done when the SAML Signing Certificate expires?

    • Mainstay will need a new certificate if a SAML Signing Certificate expries. If the replacement certificate is provided in advance and the validity period overlaps, Mainstay can perform a zero-downtime switchover to the new certificate.

18. Are you able to test SAML using a single user without affecting other users or does all auth have to be changed at once?

    • Unless otherwise requested, both SAML and username/password login can be active at the same time. In this state, a single user could test out the SAML configuration without disrupting other users. Once deemed satisfactory, username/password logins can be disabled and all users required to use SSO.

19. Do you allow us to disable the ability to sign in using any other method other than SSO once we have it enabled?

    • Yes.