Authentication overview

Authentications let Finalsite users log in using credentials from another system such as Google or LDAP, while SSOs go the other direction, letting users access external services from within Finalsite. All authentication options are configured in Integrated Services Manager in the Composer module menu.

đź’ˇQuick answers

  • What is the difference between an authentication and an SSO in Finalsite? An authentication lets users log directly into Finalsite using credentials from an external service; an SSO lets users access an external service from within Finalsite while remaining authenticated.
  • Where are authentications configured in Finalsite? In Integrated Services Manager, found in the Composer module menu.
  • Which authentication options does Finalsite support? Apple, Facebook, Google, Microsoft Entra ID (Azure AD), RapidIdentity, Senior Systems, Veracross, LDAP, ADFS, and SAML (general IdP support).
  • What is SAML authentication and when should it be used? A SAML-based option that redirects users to your own identity provider for authentication, supporting 2FA and custom password policies; best for organizations that already manage access centrally via their own IdP.
  • Does SAML authentication work across multiple domains? No; it is limited to a single domain. For multi-domain organizations, LDAP or Google authentication are recommended instead.
  • Are Apple, Facebook, Microsoft Entra ID, and RapidIdentity set up the same way as Google? Each has a client-managed setup guide for schools that want their own IT team to control the connection, plus a Quick Setup with Finalsite alternative for schools that don't need that level of control. See each provider's section below.

In this article


Authentication vs single sign-on 

Not sure which one applies to your situation? 

Ask yourself: are you signing into Finalsite, or clicking through to something else from Finalsite?

  • An authentication is the connection between another service and Finalsite: users log directly into Finalsite using credentials from that other service.
    • For example: a staff member signing into Finalsite with their Microsoft or Google account is using an authentication.
  • An SSO is the connection between Finalsite and another service: once someone is already logged into Finalsite, an SSO lets them open that other service without logging in again.
    • For example: a parent clicking a link inside their Finalsite portal that takes them straight into Veracross or FACTS, already signed in, is using an SSO. Read more in the article, Single sign-on overview.
  Authentication SSO
Direction Into Finalsite Out of Finalsite, to another service
Example Logging into Finalsite with a Google or Microsoft account Clicking from Finalsite into Veracross or FACTS without logging in again
Configured in Both configured in Integrated Services Manager.

Authentications and SSOs are maintained in Integrated Services Manager found in the module menu. 

integrated services manager.png

A full list of the authentication options we provide can be found below:

Finalsite authentication options

Senior Systems

With a Senior Systems integration, we can also configure authentication with Senior Systems so that users can log into Finalsite using the credentials housed and managed in Senior Systems. This is configurable per role.

With the Authentication configured, you can use “deep links” to land users in various sections of MyBackpack in Senior Systems. A full list of these targets is available from Senior Systems.

These deep links will serve to land the user, authenticated, in MyBackpack from a link in the Finalsite portal.

Veracross

We offer an option that will allow your users to log into Finalsite via Veracross. This is a redirect authentication that will send users in roles set to use Veracross Authentication to Veracross to log in, and then redirect back to Finalsite.

To use this option, you will need to configure an OAuth application in Veracross (detailed steps can be provided at time of deployment). We will also need to enable staggered login in Finalsite. “Staggered,” meaning that the username and password fields are on separate screens rather than having both fields displayed together and submitted with a single “log in” button.

For the full step-by-step setup, see Veracross integration and SSO setup guide.

Google

Finalsite offers an Authentication option allowing users to log in with their Google Account.  This is detailed in the article, Google Authentication.

That option is a Finalsite-managed Quick Setup requiring no configuration on the school's side. Schools that want their own IT team to control the connection instead can use the Google Workspace SSO: Client-managed setup guide.

Apple

Finalsite supports signing into Finalsite with an Apple Account (Sign in with Apple), most commonly for community-facing areas such as alumni portals and parent engagement areas. A Quick Setup with Finalsite option requires no configuration on the school's side. Schools that want their own IT team to control the connection instead can use the Apple SSO: Client-managed setup guide.

Facebook

Finalsite supports signing into Finalsite with a Facebook (Meta) account, commonly used alongside Apple and Google for community-facing sign-in. A Quick Setup with Finalsite option requires no configuration on the school's side. Schools that want their own IT team to control the connection instead can use the Meta / Facebook SSO: Client-managed setup guide.

LDAP Authentication

An LDAP (Lightweight Directory Access Protocol) server synchronizes each user’s password across multiple databases, such as your student information server, your campus email system, and your Finalsite website. LDAP integration is an easy, reliable process for allowing some or all of your constituents to log into various school systems, including your Finalsite school website, using the same username and password provided by your domain’s LDAP server.

ADFS Authentication

Finalsite has recently added a way to allow constituents/users to authenticate into Finalsite using your in-house ADFS system as the Identity Provider. This is configurable by admin group or constituent role, so there is some flexibility in how your users will authenticate. This is done using a SAML 2.0 connection.

Microsoft Entra ID (Azure AD) Authentication

Working in tandem with the Azure Integration we offer a SAML-based authentication option that can be configured to allow constituents and/or admins to log into Finalsite via Microsoft Entra ID (formerly Azure Active Directory).

Schools that want their own IT team to configure and control this connection directly can use the Microsoft Entra ID (Azure AD) SSO: Client-managed setup guide.

RapidIdentity

Finalsite supports authenticating into Finalsite via RapidIdentity, commonly used by districts that already manage staff and student access centrally through RapidIdentity. See the RapidIdentity SSO: Client-managed setup guide for the full setup steps.

SAML Authentication (General)

If you prefer to manage access for constituents and/or admin users with your own identity provider (IdP), Finalsite offers a SAML authentication method that can be used for this purpose. Most common IdPs support configuring Finalsite as a service provider in this way.

Using a SAML authentication allows you to redirect users to your own login pages for your IdP, and also allows you to implement any authentication protocols you may enforce, including two-factor authentication and password requirements. This can be configured in Finalsite per admin group or per constituent role.

As a prerequisite for this integration, the usernames in Finalsite need to match an attribute on the IdP side to ensure the connection works reliably.

SAML Authentication also supports Single-Logout that is service provider-initiated and uses the Redirect method.

  • It is important to note that SAML authentication will be limited to sign users into a single domain for your website. If your organization is hoping to have users sign into several domains, we recommend another authentication option that works across multiple domains, such as LDAP Authentication or Google Authentication. 

Related articles

Was this article helpful?
1 out of 3 found this helpful

Comments

0 comments

Please Sign in to leave a comment if you don't see the comment box below.