Single sign-on (SSO)
How to set up SSO for your Fundraise Up account.
Single sign-on (SSO) is a technology that allows a user to log into multiple applications with a single username and password. This improves the user experience by reducing the need for multiple passwords and increases organizational security through centralized account management.
Fundraise Up's SSO solution uses the SAML 2.0 protocol, which means you can choose from many third-party Identity Providers (IdPs) to manage your SSO options. Some of the most popular IdPs include Okta, Auth0, Microsoft Entra ID, and others.
Prerequisites
ÂBefore you set up the SSO configuration for your Fundraise Up account, make sure you have:
- Access to your organization’s IdP account with a user who has the Administrator role (or equivalent).
- Access to your organization’s Fundraise Up account with a user who has the Organization Administrator role.
Step 1. Set up SSO in the IdP interface
ÂTo set up SSO, first go to your IdP management panel.
- Create a new SSO application. You can give it any name, for example, “Fundraise Up SSO.”
- Configure the application with the following SSO parameters:
- Entity ID (or Audience URL):
https://dashboard.fundraiseup.com/sso/saml
- SSO URL (or ACS URL):
https://dashboard.fundraiseup.com/user/saml/consume
- Name ID format: Select
Email Address
- Entity ID (or Audience URL):
- The IdP will then provide parameters such as Issuer ID, Identity Provider URL, and a Certificate. You should keep these for the next step.
Step 2. Complete SSO configuration in Fundraise Up Dashboard
ÂLog in to your Fundraise Up Dashboard and go to Settings > Security.
- Click Configure under Single sign-on (SSO) configuration.
- Enter the parameters provided by your IdP and click Verify. Note that after verification, the SSO status is set to Off by default. Once all steps are completed, please refer to the “Enabling and disabling SSO" section on the current page to turn it on.
Step 3. Verify domains
ÂTo enable SSO, you must verify the domains of the user email addresses that will log in to the system using SSO.
- On the same Security page in your Dashboard, under Single sign-on (SSO) domains, click Add domain and enter your domain name.
- In the modal window, follow the DNS configuration instructions and click Verify.
Now, if you enable SSO, only users with email addresses from verified domains can log in with SSO.
Once added, domains will be listed in the Single sign-on (SSO) domains section with details such as domain name, date added, and verification status.
If you were unable to verify your domain the first time, you can complete the process later. Go to the three-dot menu next to the domain listed as Not Verified and select See details. This action will open a modal window with DNS configuration instructions. Follow these instructions, and then click Verify to complete the verification.
If you need to delete a domain verification record, you can do so by clicking the three-dot menu next to the domain and selecting Delete.
Enable and disable SSO
ÂOrganization Administrators can choose from three SSO enforcement options on the Security page of their Dashboard.
- Off: Single sign-on is disabled. This is the default state for every account. Users must log in to the Dashboard with a username and password.
- Optional: Users can log in with either SSO or with a username and password.
- Required: All users must log in to the Dashboard using SSO only.
SSO settings are not inherited between parent accounts and subaccounts; they can have different SSO settings, including not using SSO at all.
SSO session duration
ÂEach SSO session last 12 hours, after which users are automatically logged out.
Verified domains are checked automatically every Sunday. If DNS settings are missing, the domain's verification status updates to Not Verified, and users who are logged in with SSO are logged out.
How SSO impacts your users
ÂAfter the initial setup
ÂWhen you first set your SSO enforcement to Required, all current users of your organization's account are automatically logged out and redirected to the login screen (including the Organization Administrator, who sets this up). When they enter their credentials as usual, the login form will immediately prompt them to log in using SSO.
Any new user added after SSO is set to Required will receive an invitation email with an Accept invite button. After successful authorization, an email is sent to the user informing them that they can now log in using SSO.
For Optional SSO, users also receive an invitation email with an Accept invite button. Clicking this will take them to the Dashboard. Users then receive a second email with their login and password, along with information that they can log in using SSO, if their email domain has been verified. If the domain is not verified, users will only receive an email with their login and password.
Dashboard login options
ÂIf SSO is enabled for your organization's account, users have two options for logging in.
- By entering an email address in the login form. When a user enters their email as the login, we check that email for SSO compatibility. If the user is eligible to log in with SSO, the password field will be hidden and the Continue with SSO button will appear.
If SSO is set to Optional in your organization's settings, a user will also be given the option to log in with a password by clicking “Use your password instead” link.
- Direct SSO login. Users who know they can use SSO may click the “Use single sign-on (SSO) instead” link below the login form. They will then need to enter their email and click the Continue with SSO button.
Users who manage multiple accounts
ÂUsers who have access to two or more accounts have certain limitations when using SSO:
- A user can only have SSO access to one account at a time, unless the same IdP with the same Issuer ID is used across accounts. When a user logs in from the login page, the system redirects the user to the last account accessed. A user can still log in with a username and password, but only if the last account they accessed has SSO set to Off or Optional.
- Users with SSO access in one account cannot be added to another account with SSO Required/Optional enabled, unless the same IdP (with the same Issuer ID) is used in both accounts.
2FA and SSO
ÂFor accounts with SSO Required, Two-factor authentication (2FA) is not prompted, even if 2FA is required for that account. Learn more →
To check which of your team members can log in to the dashboard using SSO, navigate to Settings → Team. Users who can use SSO will be listed along with their 2FA configuration.
IdP-initiated login
ÂThe authentication process that is described in this article is handled through the Fundraise Up login form, which is the recommended method for organizations using SSO. However, you can set up an SSO login directly through applications such as Auth0, Microsoft Entra ID, Okta, or any other IdP. This is not recommended due to the high security risk.
If you still want to use IdP-initiated login, you must ensure that the SAML response is signed. This can be configured in the IdP settings or in the IdP admin console. For example:
- In Auth0, go to the SAML2 settings and set
signResponse
totrue
. - In Microsoft Entra ID, configure the response according to Microsoft’s documentation.
- In Okta, go to your application’s General settings, select “Show advanced settings” and make sure that “Response” is set to “Signed” (which is the default.)
Supported features
ÂFeature | Supported by Fundraise Up SSO | Description |
---|---|---|
IdP-initiated SSO | Yes | An SSO operation that was started from the IdP Security Domain. The IdP federation server creates a federation SSO response and redirects the user to the SP with the response message and an optional operational state. |
SP-initiated SSO | Yes | SAML authentication that is initiated by the Service Provider (SP). This is triggered when the end user tries to access a resource in the Service provider or sign in directly to the SP. |
Just-In-Time provisioning | No | A SAML-based method of creating a user’s account the first time that they sign in. |
SP-initiated SLO | Yes | A process where the logout is initiated by the SP. This occurs when a user signs out of the SP, which then triggers the IdP to log the user out of all connected services. |
Force authentication | No | An administrative option that requires users to re-authenticate through their IdP when trying to access an app. Users must re-authenticate even if they have an active session. |
Found a mistake? Is there a missing topic? Hard to read? Let us know