This article covers what SSO is, how it works in Full Fabric, and how to set up the sign-in rules that suit each of your populations. đ
Everything described here works alongside your existing setup. If you already use SSO, your configuration has been carried over and continues to behave exactly as before.
What is single sign-on, and how does it work?
Single sign-on is a way of letting people access several websites and services with one set of credentials, rather than defining and remembering different details for each one. Think of it as a trusted doorman: your users identify themselves once, at a place they already trust, and every other door recognises them from then on.
You have almost certainly used it already. Signing in to YouTube, Gmail and Google Analytics with one Google account is single sign-on. So is the "Sign in with LinkedIn" button you see on many sites.
Instead of typing a password into Full Fabric, the user is redirected to an external identity provider, authenticates there, and returns with proof of who they are. Behind the scenes, the identity provider passes across just enough information to identify the person and, for new users, to pre-fill their details. The benefits are hard to argue with:
Fewer passwords: one master credential to remember, and one place to recover it.
Faster access: no reentering a username and password every time.
Easier administration: sign-in policy lives in your directory, alongside everything else you already manage there.
Better adoption: a shorter path into the platform means fewer applicants abandoning it at the door.
How does single sign-on work in Full Fabric?
Full Fabric supports institutional single sign-on with SAML 2.0, the standard protocol for exchanging authentication data between an identity provider (yours) and a service provider (Full Fabric). You can find step-by-step configuration instructions in Setting up Single Sign-on (SSO) with SAML to enable institutional login.
Alongside SAML, Full Fabric supports social sign-in with LinkedIn and Google, including Google One Tap, so returning users can be signed in from a single prompt instead of going through the full Google screen each time. You can read more in Applicant access.
A few things are worth knowing about the sign-in experience itself:
There is one sign-in address for the whole platform,
/login. Every route in resolves there, so your users see the same screen however they arrive. Existing links, bookmarks and embedded sign-in links continue to work.Sign-in is email-first. Users type their email address, and Full Fabric then shows only what applies to them: a password field, a single sign-on button, or the account creation form if they are new. No more guessing which method is theirs.
You are no longer limited to one identity provider. You can configure several, each with its own target URL, certificate, entity ID and attribute mapping, which is useful where different schools, campuses or populations authenticate in different places.
Application and event links keep their context. Someone following a link to a specific programme or event lands exactly where they were headed after signing in.
How do I choose which users sign in with SSO?
Full Fabric can run several sign-in methods side by side within the same institution and route each person to the right one automatically. You set this up under Settings â Access & Security â Authentication.
There are two ways to route a sign-in attempt:
By email domain: anyone signing in with an address at, say,
@students.your-university.educan be sent to your identity provider, while everyone else continues with email and password. Because the domain is read from the address the user types, this works even for people who have never signed in before, so first-time SSO needs no preparation for each individual. Several domains can point at the same provider, which is handy for departmental, campus or legacy addresses.By role: where a profile already exists, routing can be refined by role (prospect, applicant, student, alumnus, staff, lecturer or contact). This lets the same email domain resolve differently for different populations, for example staff going to your identity provider while students keep using email and password.
Each rule can either prioritise a method or enforce it:
A prioritised rule pre-selects the expected method, and the user can still fall back to another enabled method.
An enforced rule makes the routed method the only permitted way for that identity to sign in, which is what allows you to genuinely require SSO for a population rather than simply recommend it.
Rule precedence is predictable: the first matching rule wins, and domain rules are evaluated before role rules.
A tip on rollout: set a new rule to prioritised first, confirm that the expected people are being routed where you intend, and switch it to enforced once you are happy. Administrators keep a bypass throughout. If you would like a hand planning a routing setup, talk to your Full Fabric implementation contact or our support team before enforcing anything. đ
Do SSO users still need two-factor authentication?
No. When someone authenticates through your identity provider, Full Fabric does not ask for a second factor of its own. The multi-factor policy for those users belongs in your identity provider, where you can manage it centrally and consistently with the rest of your systems. If you currently rely on Full Fabric's two-factor authentication for a population that also uses SSO, check that your identity provider's own policy covers them.
For anyone still signing in with email and password, two-factor authentication remains available and recommended. Passkeys are now supported for both staff and applicants, alongside SMS, and are generally the smoother option: the credential lives on the device or password manager the person already uses, unlocked with a fingerprint, face or PIN, with nothing to type and no code to wait for.
If a user loses access to their second factor, your own team can now sort it out. Staff holding the Reset user two-factor authentication permission will find a Reset two-factor authentication action in the Security section of that user's profile, so there is no need to contact us. See Protecting accounts with 2-Factor Authentication and Passkeys for the full detail.
Who can manage these settings?
Two dedicated permissions govern sign-in configuration, both assignable to roles under Settings â Roles:
Manage authentication settings: view and change institution-level authentication configuration, including password policy, single sign-on, two-factor authentication and related sign-in settings.
Reset user two-factor authentication: reset another user's two-factor authentication, including another staff user.
Frequently asked questions
Can we require SSO for staff but let applicants use a password? Yes, that is exactly what domain and role routing are for. Point a rule for your staff email domain at your identity provider and mark it as enforced, then leave email and password enabled for everyone else.
Can we offer more than one sign-in method at once? Yes, and we generally recommend it for applicant-facing populations. The more familiar routes in you offer, the higher adoption tends to be.
A user cannot receive their SMS code any more. What now? A staff member with the Reset user two-factor authentication permission can reset it from the Security section of that user's profile.