Single sign-on (SSO) lets staff, students and parents log in to PortalHQ using their existing school identity — Microsoft, Google, or your school’s own identity provider — rather than maintaining a separate PortalHQ password.
SSO is one of the highest-leverage integrations: it removes a password to forget, reduces helpdesk calls, and makes provisioning/deprovisioning much simpler when staff or students arrive or leave.
How PortalHQ does SSO
PortalHQ supports SAML 2.0 — the open standard used by every major identity provider. The integration is configured per audience:
- Staff — typically via Microsoft Entra ID (formerly Azure AD) or Google Workspace.
- Students — same provider as staff usually, sometimes a separate student-only realm.
- Parents — separate parent identity, sometimes managed by PortalHQ directly and sometimes via a parent-specific SSO.
You can have different SSO configurations for different audiences.
What SSO provides
- Login — users click Sign in with [your IdP] on the login page and authenticate against the IdP.
- User provisioning — when a user authenticates for the first time, PortalHQ links to their account.
- Single sign-off — logging out of one of the SSO-linked apps logs the user out of others.
What SSO doesn’t do
- Replace SIS sync — SSO authenticates users; SIS sync provisions them with the right roles, classes and contact data. You still need the SIS integration.
- Authorise actions — SSO confirms who the user is. Permission is set by PortalHQ’s permission system, based on user role.
Setting up SSO
The setup is a coordinated task between your IT team and PortalHQ:
- Pick your identity provider.
- Register PortalHQ as an application in your IdP.
- Send the IdP metadata to PortalHQ.
- PortalHQ configures the SP metadata in your environment.
- Test with a few accounts.
- Enable enforcement once tested.
Identity attributes
SSO passes attributes from the IdP to PortalHQ:
- Email — used to match the user to a PortalHQ account.
- First and last name — populates the user’s profile.
- Groups / role — used in some setups to drive permissions.
Matching SSO users to accounts
When a user authenticates, PortalHQ matches them to a local account by email. If no match exists, the login is rejected with an error pointing the user to contact admin. This is the safer default — only users who exist in the SIS-synced database can log in.
Common issues
- User can log into IdP but PortalHQ rejects — email mismatch. Update the PortalHQ user’s email or the IdP claim mapping.
- Some users can log in, others cannot — group restriction in IdP app. Update the SAML app’s allowed-groups setting.
- Logout loops — single sign-off configuration is wrong. Switch to local logout.
- Certificate expired — re-export IdP metadata and update PortalHQ.
Maintenance
The main ongoing task is certificate renewal. When yours rotates:
- Export the new IdP metadata.
- Send it to PortalHQ.
- PortalHQ updates the configuration.
Plan for the cert renewal — an expired cert breaks SSO for everyone.
Bypass for emergencies
PortalHQ retains an emergency local-password option for the school administrator account. Keep the emergency credentials in a secure place.