Single Sign-on (SSO) allows schools to maintain centralised user authentication, and enables staff, students and even parents to login to Boardingware using this centralised system. Boardingware supports the SAML 2.0 protocol which is compatible with most user-directory systems eg. Active Directory or Google Apps.
Identity Provider Specific Setup Guides
The following are links to specific setup guides, with more detailed instructions, created for the most common Identity Providers:
Otherwise, follow the general setup guide below.
General Setup Guide
The process for enabling SSO for users is as follows, refer to the Reference section below for complete documentation.
Set up on Boardingware's end (Authentication Profile)
Set up school's end (IdP Settings)
Back to Boardingware settings
Add new and existing users to the profile through an email-invitation process.
Within the SAML terminology the centralised authentication server is the Identity Provider (IdP) and Boardingware is the Service Provider (SP).
1 - Create a new Authentication Profile
Within the Admin Console > Authentication section of the Boardingware staff web application, create a new Authentication Profile.
2 - Add Boardingware to your Identity Provider Configuration
To allow Boardingware to authenticate against your user directory system use the Profile Values from your newly created Authentication Profile. Either import the settings using the SP Entity ID metadata.xml or enter the values manually.
The NameID for Boardingware must always be an email that the user has inbox access to.
Enable Assertion Signatures.
If you are presented with enable encryption option of some sort, make sure to disable encryption (HTTPS is used instead).
If you don't use metadata.xml, manually fill out:
SP Entity ID
SP Login/Logout URL
[Optionally] SP Signing Certificate
Figure 1. Screenshot of a Microsoft Azure Active Directory configured to working with Boardingware. Note that the metadata.xml file is actually located at the URL given by Entity ID.
3 - Complete Authentication Profile
Copy the Login URL and Public Certificate (required) from your IdP settings into the Boardingware Authentication Profile.
Use the Test Run button to test the configuration by logging in as any user in your user directory. A page indicating success means you can proceed to the next step.
Choose the user types this profile applies to, and disable Boardingware login for any user types you do not wish to have a standard username/password login.
Figure 2. Screenshot of Microsoft Azure Active Directory displaying the fields required to complete configuration. Copy SAML Single Sign-On Service URL and SAML Signing Certificate - Base64 encoded into the Authentication Profile within Boardingware itself.
4 - Invite Users
Both new and existing users can be configured to use a new Authentication Profile.
For new users, select the profile at the time of invitation, the user will have to login successfully to the IdP as part of the signup process.
For existing users choose the Change Login Method, they will receive an email and be required to login successfully during the migration process.
It is also possible to change a user from authenticating using SSO to authenticating using Boardingware. It is possible to have a mix of login types amongst users.
Authentication Profiles Reference
Admin Console > Authentication
The Authentication settings page allows your to setup multiple SSO Profiles and select which are enabled and disabled for the 3 Boardingware user types. This paradigm allows Boardingware to be flexible in supporting any possible school configuration, however we expect most schools to have just one, maybe two, Authentication Profiles. Staff users with the Administrator permission will have access to this settings page.
This section allows the administrator to enable or disable the ability for users to signup and login with a Boardingware username/password. Disabling this option for a particular user group will not break login for existing users, it will however prevent password login from being enabled for further users.
Create New Profile: Add an empty Authentication Profile to the settings page.
Test Run: Initiates a dummy SAML protocol exchange in a new tab. Use this to confirm that everything is set up correctly without having to first connect a SAML user to Boardingware.
Edit Profile: Authentication Profiles can be edited and the new configuration will apply to existing users authenticating against this profile.
Delete Profile: Deleting an Authentication Profile will leave any users tied to that profile in an orphaned state without the ability to login to Boardingware. They must go through an email-invitation process initiated by an administrator, they cannot be attached automatically to a new profile. We recommend editing profiles to maintain existing users.
Save Profile: Please click Save before leaving the page to apply changed settings, else cancel to discard any modifications.
Authentication Profile Details
Choose a friendly name for a profile. This will be displayed to the administrator as a choice when sending invitations.
Applicable User Types:
Select which Boardingware user types can be invited to use this profile. This should simply reflect which users are in that user directory. For any user types that do not authenticate using SSO, enable Boardingware Login and they will use a username + password managed by Boardingware.
eg. A school might have one Active Directory database for Staff, another for Students and no centralised login for parents. For this they would create 2 separate Authentication Profiles, each enabled only for one user type, and enable Boardingware Login only for parents.
These settings point Boardingware to a particular IdP server, particulars should be available to copy from the IdP configuration into these fields.
IdP Login URL: The URL of the IdP SAML 2.0 assertion endpoint. This will process XML <AuthnRequest> payloads during the login process.
IdP Public Certificate: The public certificate that is used by Boardingware to verify XML <AuthnResponse> payloads signed by the IdP. This is mandatory and is the primary security mechanism ensuring logins cannot be spoofed by a malicious party.
These settings point the IdP server to Boardingware. Copy and paste these values into the IdP configuration. Likely only the first two fields will be necessary.
SP Entity ID: A URL representing Boardingware. This is actually an XML file containing the following two fields among others. If your IdP configuration supports it, the correct configuration can be imported from this XML file.
SP Login/Logout URL: The URL of the SAML 2.0 assertion endpoint for Boardingware. This will process XML <AuthnResponse> payloads during the login process. Currently Single Logout (SLO) is not supported, but may be in the future - users will logout from Boardingware independently of the centralised system.
SP Signing Certificate: [Optional] The public certificate that is used by the IdP to verify the XML <AuthnResponse> payloads signed by Boardingware. If the IdP configuration has a field to input it, this certificate should be used. The security of the protocol is actually not degraded by the absence of this signature check, so do not worry if the IdP does not use it.
Can users be automatically imported using SSO? No, SSO integration only does user authentication, user provisioning is left to the Data Integrations that we offer, as well as CSV import.
Can I use ____ SSO technology? We have determined that the vast majority of our customers have systems that are compatible with the SAML 2.0 protocol. Some SIS systems have their own custom SSO protocols, please contact us if you wish Boardingware to integrate with your SIS.
Still having trouble?
If you didn't find the answer you were looking for, please use the blue bubble in the bottom right-hand corner to start a conversation with one of our helpful team members.