Single sign-on (SSO)
How to set up SSO for your Fundraise Up account.
Single sign-on (SSO) is a technology that lets users log in to multiple applications with one set of credentials. This reduces the need for multiple passwords and centralizes account management, which improves security and simplifies access control for your organization.
The Fundraise Up 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. Compatible IdPs include Okta, Auth0, Microsoft Entra ID, and others.
Before you begin
Before you set up SSO, make sure that you have:
- Administrator access to your organization’s IdP account.
- Organization Administrator access to your Fundraise Up account.
Step 1. Set up SSO in the IdP interface
- Go to your IdP management panel.
- Create a new SSO application. Give it a descriptive name like Fundraise Up SSO.
- Configure the application with these 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:
Email Address
- Entity ID (or Audience URL):
- Locate and copy these from your IdP:
- Issuer ID (also called Entity ID)
- Identity provider URL (also called Single sign-on URL or SAML endpoint)
- Identity provider certificate (or X.509 certificate)
You'll need these in Step 2.
Step 2. Complete SSO configuration in the Dashboard
- In the Fundraise Up Dashboard, go to Settings > Security.
- Under Single sign-on (SSO) configuration, click Configure.
- Enter the parameters from your IdP:
- Issuer ID
- Identity provider URL
- Identity provider certificate
- Click Verify.
SSO configuration screen for entering IdP parameters
After verification, SSO is set to Off by default. You’ll enable it after verifying your domains in Step 3.
Step 3. Verify domains
SSO requires domain verification to confirm that you control the email domains your team uses. This security measure prevents unauthorized access.
- Go to Settings > Security.
- Locate Single sign-on (SSO) domains and click Add domain.
- Enter your domain name (for example,
example.org). - In the modal window, follow the DNS configuration instructions to add a TXT record to your domain’s DNS settings.
- Click Verify.
Domain verification details
DNS changes can take time to take effect. If verification fails, wait a few hours and try again.
After verification, only users with email addresses from verified domains can log in with SSO. Verified domains appear in the Single sign-on (SSO) domains section with their verification status.
How to retry verification
If verification fails:
- Click the three-dot menu next to the domain marked Not Verified.
- Select See details.
- Confirm your DNS record matches the instructions.
- Click Verify.
To delete a domain, click the three-dot menu next to it and select Delete.
Okta-specific setup instructions
If you use Okta as your IdP, follow these Okta-specific instructions instead of the general steps above.
Okta is one of the most popular Identity Providers. The Fundraise Up SSO app is available in the Okta Integration Network, which simplifies setup.
- Log in to the Okta Admin Console.
- Go to Applications > Applications.
- Click Browse App Catalog.
- Search for Fundraise Up SSO.
- On the Fundraise Up SSO page, click Add.
- Enter the required information under General Settings and click Next.
- Go to the Sign On Options section.
- Under Credentials Details, select Email from Application username format.
- Click Done.
- On the Assignments tab, add the users who need Dashboard access.
- Go to the Sign On tab.
- Under SAML 2.0, click More details in the Metadata details section.
- Copy the Sign on URL, Issuer, and Signing Certificate. You’ll enter these in the Dashboard.
- In Fundraise Up Dashboard, go to Settings > Security.
- Under Single sign-on (SSO) configuration, click Configure.
- Enter the values that you copied in step 13.
- Click Verify.
- Continue with domain verification as described in Step 3 above.
Enable and disable SSO
After completing setup and domain verification, go to Settings > Security to enable SSO.
SSO has three settings:
- Off. SSO is disabled (default). Users log in with username and password.
- Optional. Users can log in with either SSO or username and password.
- Required. All users must log in using SSO only.
To enable SSO, select Optional or Required under SSO enforcement and click Save changes.
Choose the enforcement level that matches your security requirements
SSO session duration
Each SSO session lasts 12 hours, after which users are automatically logged out and must sign in again.
Domains are automatically verified every Sunday. If your DNS settings are removed or modified, the domain's verification status changes to Not verified, and users lose SSO access. To restore access, verify the domain again using the process described in Step 3.
How SSO impacts your users
When you enable SSO, it changes how users log in and what they experience. Here's what happens at each stage.
When you first enable SSO
When you set SSO enforcement to Required, all current users are automatically logged out and redirected to the login screen. This includes the Organization Administrator who configures SSO. When users enter their email address at login, they’re prompted to log in using SSO instead of a password.
New users added after SSO is set to Required receive an invitation email with an Accept invite button. After successful authorization, they receive a confirmation email explaining they can log in using SSO.
Welcome email for new users with SSO login instructions
For Optional SSO, users receive an invitation email with an Accept invite button. Clicking this takes them to the Dashboard. They then receive a second email with their username and password. If their email domain has been verified, the email also mentions they can log in using SSO. If the domain is not verified, users only receive username and password information.
Dashboard login options
If SSO is enabled for your account, users have two ways to log in.
Email-based login
When a user enters their email address in the login form, the system checks whether they’re eligible for SSO. If they are, the password field disappears and the Continue with SSO button appears.
If SSO is set to Optional, users can also log in with a password by clicking the Use your password instead link.
Direct SSO login
Users who know they can use SSO can click the Use single sign-on (SSO) instead link below the login form. They then enter their email and click Continue with SSO.
Users who manage multiple accounts
Some users have access to multiple, unrelated accounts. In these cases:
- Users can only use SSO across accounts if all accounts use the same IdP with the same Issuer ID.
- When logging in from the main login page, users are redirected to the last account they accessed.
- Users can log in with a password only if the last accessed account has SSO set to Off or Optional.
- Users with SSO access in one account cannot be added to another account with Required or Optional SSO unless both accounts use the same IdP and Issuer ID.
If you have users who access multiple accounts, consider using the same IdP configuration across all accounts to simplify their login experience.
This behavior doesn’t apply to parent and subaccount setups. See the section below for how SSO works with parent and subaccounts.
SSO behavior with parent and subaccounts
SSO settings aren't inherited between parent accounts and subaccounts. Each account can have different SSO settings or not use SSO at all. If you have parent and subaccounts, configure SSO separately for each one.
User access is shared: when you add a user to the parent account, they automatically get access to all connected subaccounts.
This means:
- If a user logs in to the parent account using SSO, they stay logged in when switching to subaccounts — even if those subaccounts don't use SSO.
- If a user logs in to a subaccount using a password, they can't switch to a parent account that requires SSO.
- To avoid access issues, users should log in through the parent account when SSO is enabled there.
2FA and SSO
For accounts with SSO set to Required, users don’t need to use two-factor authentication (2FA) when logging in, even if 2FA is enabled for the account. This is because the IdP handles authentication security.
To check which team members can log in to the Dashboard using SSO, go to Settings > Team. Users who can use SSO are listed along with their 2FA configuration.
IdP-initiated login
The setup instructions above describe SP-initiated SSO, where users start at the Fundraise Up login page. There's another way called IdP-initiated login, where users start from their IdP's dashboard and click a link to access Fundraise Up directly.
IdP-initiated authentication creates serious security vulnerabilities, including:
- Man-in-the-middle attacks, where malicious actors intercept authentication data.
- Replay attacks, where stolen credentials are reused for unauthorized access.
These risks can compromise your supporters' data and your organization's security.
If you still want to use IdP-initiated login
You must ensure that your IdP signs the SAML response. Configure this in your IdP settings:
- Auth0. Go to the SAML2 settings and set
signResponsetotrue. - Microsoft Entra ID. Configure the response according to Microsoft’s documentation.How to configure IdP-initiated login in Microsoft Entra ID.
- Okta. Go to your application’s General settings, select Show advanced settings, and make sure Response is set to Signed (the default).
SSO capabilities in Fundraise Up
This table shows which SSO features are available in Fundraise Up and what they mean for your organization.
| Feature | Supported | Description |
|---|---|---|
| IdP-initiated SSO | Yes | Users can start the login process from their IdP’s dashboard and be automatically signed in to Fundraise Up. This method has security risks (see “IdP-initiated login” section above). |
| SP-initiated SSO | Yes | Users start the login process from the Fundraise Up login page and are redirected to your IdP for authentication. This is the recommended method. |
| Just-in-time provisioning | No | User accounts are not automatically created when someone logs in with SSO for the first time. You must add users manually in the Dashboard before they can log in. |
| SP-initiated SLO (Single Logout) | Yes | When users log out of Fundraise Up, they’re also logged out of your IdP and all connected services. |
| Force authentication | No | Users are not required to re-authenticate with the IdP if they already have an active session. |
Troubleshooting
If you run into issues during setup, try these solutions.
- Domain verification fails. If domain verification fails right after you click Verify, your DNS changes likely haven’t taken effect yet. Wait a few hours and try again.
- Users can’t log in after enabling SSO. Make sure that:
- The user’s email domain is verified in Settings > Security > Single sign-on (SSO) domains.
- The user has been added to the Dashboard under Settings > Team.
- The user has been assigned to the SSO application in your IdP.
- Certificate errors. If you see certificate-related errors during setup, verify that:
- You copied the entire certificate.
- No extra spaces or line breaks were added when pasting.
- The certificate hasn’t expired in your IdP.
- Need to disable SSO. If you need to disable SSO temporarily:
- Go to Settings > Security.
- Under SSO enforcement, select Off.
- Click Save changes.
Users will be able to log in with their username and password immediately.
If none of these solutions work, contact Fundraise Up support for help.
Next steps
After completing your SSO configuration:
- Test SSO login with a team member without admin privileges to confirm it works correctly.
- Communicate the change to your team, including when SSO becomes active and how it affects their login process.
- Consider creating internal documentation for your team explaining how to log in with SSO.
- Check which team members have SSO access by going to Settings > Team.
If you’re setting SSO to Required, consider starting with Optional for a few days to give your team time to adapt before enforcing it.