Orbit offers Single Sign-On (SSO) for operator users in Orbit MissionControl and for shipper users in Orbit Hub, enhancing security and streamlining access management.
Orbit offers Single Sign-On (SSO) capabilities for operator users in Orbit MissionControl and for shipper users in Orbit Hub, enhancing security and streamlining access management. This feature allows organisations to integrate their existing identity providers with Orbit, providing a seamless authentication experience for their users.
When a user logs in via SSO for the first time, Orbit automatically creates a user account based on the information provided by your identity provider. This ensures a smooth onboarding process for new users.
Your identity provider may also manage people who should not work in Orbit MissionControl, such as partners or other companies of your group. In that case, Orbit can admit only users whose identity provider sends a given attribute value, for example only users marked as internal staff. If the attribute holds several values, one allowed value is enough.
A user who is not permitted sees this message on the login page, and no account is created for them:
Your account doesn't have access to Mission. Please contact your administrator.
The restriction is checked when a user signs in for the first time. Once an account exists, a later change of the attribute in your identity provider does not remove it. To take access away from such a user, deactivate them in Orbit MissionControl.
An Orbit Hub can also let the people of your shippers sign in with the identity provider of their company. Nobody needs to create their accounts in advance: Orbit creates each ShipperUser on the first sign-in and keeps their team in step with the identity provider.
Below the sign-in form, after Forgot password?, Orbit Hub shows a button Sign in with followed by the name of the identity provider. One click takes the user to their company's sign-in page; they do not enter their email address in Orbit Hub first. After a successful sign-in they return to Orbit Hub, to the page they started from. The password sign-in stays available for users who have a password.
On the first sign-in, Orbit creates the ShipperUser and places them in the ShipperTeam whose team property holds the value the identity provider sends, for example a branch number. The new user gets the default role and language agreed during setup, and their name and email from the identity provider. Orbit sends no welcome email.
If no active team holds the value, several teams hold it, or the user's type is not allowed, Orbit refuses the sign-in and creates no account.
Each time a user signs in through the identity provider, Orbit checks the values again:
The value names the user's team: the user signs in as usual.
The value names another team of the same Shipper: Orbit moves the user to that team, and they work in that one team from then on.
The value names a team of another Shipper, no team holds it, or the user's type is no longer allowed: Orbit refuses this sign-in and leaves the account as it is. Once the identity provider sends a valid value again, the next sign-in works. In the same browser this can take a while: for a short time after a refused sign-in, the button signs in again without visiting the identity provider, and Orbit refuses that sign-in too, because it accepts only the values the identity provider sends with each sign-in. A new browser picks up the change at once. The same holds after a correction in Orbit, such as the team property of the right team.
The identity provider must send the attribute that names the user's team on every sign-in, and also the attribute that decides who may sign in, if you use one. A sign-in without one of them is refused, the same as a sign-in with a value that is not allowed.
A team set by hand in Orbit MissionControl therefore changes again at the user's next sign-in when the identity provider names another team of the same shipper.
Orbit checks the values only when a user signs in, not while they stay signed in. To take access away immediately, deactivate the ShipperUser in Orbit MissionControl.
If you remove a user's Orbit Hub access in Orbit MissionControl, they can no longer sign in through the identity provider, and Orbit does not create their access again. To give such a user access again, contact Orbit support.
Orbit can set how many days a sign-in lasts in your Orbit Hub. The setting applies to every user of that Orbit Hub, users who sign in with a password included. Without it, a sign-in lasts up to ten years. A changed setting applies to sign-ins made after the change; users who are already signed in keep the length their session started with. A shorter session also means that a change in your identity provider reaches Orbit Hub sooner.
Orbit sets up SSO for an Orbit Hub; you cannot switch it on yourself yet. You provide:
The SAML metadata URL of the identity provider
The attributes it sends: email address, first name and last name, the attribute that names the user's team, and optionally an attribute whose values decide who may sign in
The team property in Orbit MissionControl that holds each team's value, filled in for every team whose people should sign in
The default role and language for new users, and optionally the session length in days
Orbit then provides the Identifier (Entity ID) and the Reply URL (Assertion Consumer Service URL) for your identity provider. The identity provider must send a permanent identifier for each person that never changes, not an email address that can change: a new identifier creates a new account.
Choose the default role with care, because every user the identity provider creates gets it. A role that may invite colleagues lets users add people who sign in with a password instead of the identity provider.
ACME Ltd books transports through your Orbit Hub. Each of its branches is a ShipperTeam with a branch number. Julia works at the Paris branch. She clicks Sign in with ACME ID, signs in at her company, and Orbit creates her account in the Paris team. A year later she moves to the Tokyo branch, and her company changes her branch number. At her next sign-in, Orbit moves her to the Tokyo team, and her new bookings belong to that team.
For assistance with SSO configuration or to enable this feature for your organisation, please contact Orbit support. Our team will guide you through the setup process and ensure a smooth integration with your existing identity management system.
Any identity provider that supports SAML 2.0, for example Microsoft Entra ID
or PingOne.
What happens if a user without the required attribute value signs in?
The login page shows that their account doesn't have access, and no account
is created in Orbit. Once the attribute value is set in your identity
provider, the user can sign in again.
Does changing a user's attribute in my identity provider remove their access?
In Orbit MissionControl, no. The restriction is checked on the first sign-in
only. To remove an existing user's access, deactivate the user in Orbit
MissionControl. In Orbit Hub, the next sign-in is refused, but a user who is
still signed in stays signed in until the session ends. Deactivate the
ShipperUser to take access away immediately.
Can Orbit Hub users still sign in with a password when SSO is set up?
Yes. The password sign-in stays on the same page. A person who has a
password account and then signs in through the identity provider gets a
second, separate account.
What happens if a user's team changes in my identity provider?
At the user's next sign-in to Orbit Hub, Orbit moves them to the team the
identity provider now names, as long as it is a team of the same shipper. If
it names a team of another shipper, Orbit refuses the sign-in.
