Single Sign-On for Moves+

How Single Sign-On works for Moves+, what we need from your IT team, and how a rollout runs from first conversation to go-live.

Time required: 30 minutes to read; 1 to 2 weeks for a typical rollout

User role: Administrator, IT administrator, project lead

Module: Moves+ admin > Single Sign-On

Overview

With SSO enabled, your members sign in to the Moves+ app with the account they already use for everything else at your organisation. They do not create or remember a separate Moves+ password.

Authentication happens through your own identity provider using SAML 2.0. Moves+ never sees or stores your members' organisation passwords. Your identity provider confirms who the person is, and Moves+ trusts that confirmation.

SSO covers both the Moves+ app for members and the Moves+ admin dashboard for your staff. At the admin dashboard, staff whose email is on your SSO domain are sent to your sign-in page. Staff on any other domain are asked for a password.

Important: in the app, Moves+ is either SSO or email sign-in for your organisation, not both. Once SSO is enabled, the app shows your members only Sign in with SSO. They cannot create an account or sign in with email and password. Plan your communications on that basis.


What SSO does

  • Members sign in with their existing organisation credentials.
  • Access follows your identity provider. Someone you remove there cannot sign in again. A member already signed in to the app stays signed in until their session ends, so to stop access straight away, also deactivate them in Moves+.
  • Each sign-in updates the member's first name, last name and role from your identity provider.
  • Your IT team keeps control of password policy, multi-factor authentication and conditional access.
  • There is no Moves+ password for members to reset, which removes the most common support request we see.

What SSO does not do

  • It does not sync your directory. Member records are created when someone first signs in, not pushed to us in advance. There is no SCIM or directory sync integration.
  • It does not update a member's email address after their first sign-in.
  • It does not run alongside email sign-in in the app. Enabling SSO replaces it.

Before you start

Prerequisite Details
SAML 2.0 identity provider Your organisation's IdP must support SAML 2.0 with signed assertions
A named admin contact One person with authority to change DNS records and configure the IdP. They receive the setup invitation from us
Your email domain The domain your members and staff sign in with, for example organisation.com. Admin dashboard sign-in routes to SSO on one domain per organisation. If your people use more than one domain, tell your Client Success Manager
A decision on which email address your IdP sends See Email addresses and aliases below. This is the most common cause of problems, so settle it before you configure anything
Ability to add a DNS TXT record Needed once, to verify you own the domain
Two test accounts One ordinary member and one member of staff, so both routes can be checked before go-live
Agreement with your Client Success Manager SSO is enabled per client by OpenPlay and is a chargeable addition. Your CSM will confirm the commercial detail

Email addresses and aliases

Read this section before you configure anything. It is the difference between a clean go-live and a set of duplicate accounts.

The first time someone signs in with SSO, we match them to their existing Moves+ account on their email address, matched exactly. After that first match, Moves+ links the account to their identity provider record.

Many organisations issue two addresses for the same person:

  • a primary address based on a student or staff number, for example s1234567@organisation.com
  • a friendlier alias based on their name, for example a.person@organisation.com

Members typically know and use the name-based alias, while the identity provider often sends the number-based primary. When those two differ, the person arrives as a brand new member with no points, badges or history, and ends up with two accounts.

To avoid it:

  1. Decide which address your identity provider will send, and confirm it with us before go-live.
  2. Check that address against the addresses already in Moves+. If your members registered with the alias but your IdP sends the primary, tell us before you enable SSO so we can plan the mapping.
  3. Tell your members which address to expect, so they are not surprised.
  4. Keep the person's identity record stable. Once a member is linked, a change of email address alone does not create a duplicate. A change to the identity record your provider sends for that person can.

If you are not sure which address your members used to register, ask your Client Success Manager for a list before you configure the connection.


Who does what

SSO for Moves+ is a shared job. Your team owns the parts that touch your organisation's identity; OpenPlay owns the configuration inside Moves+.

Step Owner
1. Confirm the domain, IdP, named admin contact and which email address will be sent You
2. Create your organisation and send the setup invitation OpenPlay
3. Verify your domain with a DNS record You
4. Configure your identity provider and attribute mapping You
5. Configure the Moves+ side and set your domain match OpenPlay
6. Test with a member account and a staff account You and OpenPlay together
7. Enable SSO for live members OpenPlay, on your go-ahead

Important: steps 3 and 4 must be finished before step 7. If SSO is switched on before your identity provider is configured, your members cannot sign in. We keep step 7 as the last action, on your explicit go-ahead.


Steps

1. Send us your details

Tell your Client Success Manager:

  1. The full name of your organisation as members should see it in the app
  2. The email domain your members will sign in with
  3. Which email address your identity provider will send, primary or alias
  4. The name and email address of the person who will configure the identity provider
  5. Which identity provider you use

2. Accept the setup invitation

Your named contact receives an emailed invitation to a secure setup portal. This portal is provided by our authentication partner and is branded accordingly, so it will not carry OpenPlay branding. The link is genuine and comes from us.

Opening it presents two tasks, which can be done in either order:

  1. Verify your domain
  2. Configure Single Sign-On

3. Verify your domain

  1. Enter the domain your members sign in with, for example organisation.com
  2. Add the DNS TXT record shown, to that domain
  3. Return to the portal and confirm verification

Verification can take up to an hour to propagate, and occasionally longer depending on your DNS provider's cache settings.

You can verify more than one domain. Admin dashboard sign-in routes to SSO on one domain only, so if your people use more than one email domain, raise it with your Client Success Manager before go-live.

4. Configure Single Sign-On

  1. Select your identity provider from the list
  2. Follow the guided steps for that provider. They differ by provider, and the portal shows the exact values to copy
  3. Complete the attribute mapping described below
  4. Save and confirm the connection shows as active

5. Configure attribute mapping

Your identity provider must send the following with each sign-in. A missing required attribute causes the sign-in to fail rather than partially succeed, so it is worth checking each one.

Attribute Required Description Notes
Email address Yes The member's email address Must be on a domain you have verified. Used to match the person to their existing Moves+ record on first sign-in, so see Email addresses and aliases above
First name Yes The member's first name Sign-in fails if this is empty. Updated at every sign-in
Last name Yes The member's last name Sign-in fails if this is empty. Updated at every sign-in
Role Only for staff Marks someone as Staff Leave unset for ordinary members. Everyone without it becomes a Member, which is the default. Updated at every sign-in
Unique ID No Your own reference for the person, such as a student or staff number Stored as the member's reference in Moves+. Updated at every sign-in if sent

Roles. There are two:

  • Member is the default. Anyone signing in without a role assigned becomes a Member and gets the app.
  • Staff must be assigned in your identity provider, using the role staff. Staff get the Moves+ admin dashboard as well as the app.

You therefore only need to configure the role attribute for the people who administer Moves+ for your organisation. Because the role is applied at every sign-in, removing it in your identity provider makes that person a Member at their next sign-in.

6. Test before go-live

We will enable SSO for testing and check, with you:

  1. A member signs in successfully and lands in the app
  2. A member of staff signs in successfully and can reach the admin dashboard
  3. An existing member is matched to their existing account, with their points and history intact
  4. A member whose email is on an unverified domain is refused
  5. The attributes arriving from your identity provider are complete and correct

Step 3 is the one worth spending time on. Test it with a real member who already has points and history, not a fresh test account.

7. Go live

On your go-ahead, we enable SSO for all members. From that point, the app shows your members only Sign in with SSO, and they sign in through your identity provider.


What your members will see

In the Moves+ app, members select your organisation from the list and tap Sign in with SSO. Your own sign-in page opens inside the app, they authenticate there including any multi-factor step you require, and they return to the app signed in.

There is a separate article you can share with them: Signing in to Moves+ with your organisation account.


Troubleshooting

An existing member has signed in but their points and history have gone.
Their identity provider address does not match the address on their Moves+ account, usually because of a primary address and alias mismatch. Contact your Client Success Manager. Do not ask them to create a new account.

A member sees your sign-in page but gets "Authentication failed" in the app afterwards.
The attributes arriving from your identity provider are incomplete. Check that email address, first name and last name are all being sent and are not empty.

A member of staff is asked for a password at the admin dashboard.
Their email is not on your SSO domain. Dashboard sign-in routes to SSO on one domain only. Raise it with your Client Success Manager so we can advise on the options.

Someone has left but can still use the app.
They are still signed in from before. Removing them in your identity provider stops new sign-ins only. Deactivate them in Moves+ to stop access straight away.

Domain verification is not completing.
Confirm the TXT record is on the exact domain shown, with no typing errors, and allow up to an hour for propagation. Some DNS providers append the domain automatically, which can produce a doubled record.

A member of staff can sign in to the app but not the admin dashboard.
The Staff role is not assigned to them in your identity provider. Members without a role become ordinary Members by default.

Can we let some members use email sign-in and others use SSO?
No. In the app, Moves+ is one or the other for the whole organisation.

We need to turn SSO off.
Contact your Client Success Manager. We can disable it, and members return to signing in with email and password. Members who joined through SSO have never had a Moves+ password, so they set one with I have forgotten my password.


Security and data

Authentication uses SAML 2.0 with signed assertions. Moves+ does not receive, store or process your members' organisation passwords at any point. Your identity provider authenticates the person and returns a signed assertion confirming their identity and the attributes above.

We use a specialist authentication provider to broker the SAML connection between Moves+ and your identity provider. If your information security or procurement team needs the provider named, along with their compliance certifications and the data processed, your Client Success Manager will supply it.

Failed sign-in attempts are logged so that our technical team can support you.


What's next?

Was this article helpful?
0 out of 0 found this helpful