--- title: "Single Sign-On (SSO)" description: "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." url: "https://support.pr-9.orbit.do/en/advanced-features/single-sign-on-sso" locale: "en" apps: ["mission", "hub"] lastReviewed: "2026-10-22" --- # Single Sign-On (SSO) 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. ## Overview 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. ## Key Features * Support for multiple identity providers * Works with SAML 2.0 identity providers such as Microsoft Entra ID (Azure Active Directory) or PingOne * Customisable user attributes and role mapping * Automatic user creation upon first SSO login * Optional access restriction: only users with a given attribute value from your identity provider get access * In Orbit Hub: new users land in their shipper team automatically, and their team follows your identity provider ## How It Works in Orbit MissionControl Orbit's SSO implementation supports the SAML 2.0 protocol. When an operator attempts to log in to Orbit MissionControl: 1. They are presented with an option for Single Sign-On on the login page 2. The user enters their email address 3. Orbit determines the appropriate identity provider based on the email domain 4. The user is redirected to their organisation's SSO login page 5. Upon successful authentication, the user is granted access to Orbit ## Setting Up SSO for Orbit MissionControl To enable SSO for your organisation, you'll need to provide Orbit with the following information: * The SAML metadata URL of your identity provider (in Microsoft Entra ID: the App Federation Metadata URL) * Claim mappings for user attributes (e.g., firstname, lastname, email) * Default user role and team for new users * List of email domains associated with your organisation * Optionally, the attribute and the values that grant access, if only some of your users should use Orbit MissionControl Orbit will then provide you with: * Identifier (Entity ID) for your identity provider to use * Reply URL (Assertion Consumer Service URL) for SAML configuration ## User Management 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. ### Restricting Access to Some 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. ## Single Sign-On in Orbit Hub 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. ### What Users See 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. ### First Sign-In 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. ### Later Sign-Ins 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. ### Messages on the Sign-In Page When Orbit refuses a sign-in, Orbit Hub shows why on its sign-in page. The first two messages name your company, here Spaceport Shipping Co.: | Situation | Orbit Hub shows | | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | The user's type is not allowed | "Your account doesn't have access to this Hub. Please contact Spaceport Shipping Co." | | No team, several teams, or a team of another shipper holds the value | "Your organisation doesn't have access to this Hub yet. Please contact Spaceport Shipping Co." | | Anything else | "Single sign-on failed. Please try again." | ### Session Length 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. ### Setting Up SSO for Orbit Hub 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. ### Example 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. ## Security Considerations SSO integration enhances security by: * Centralising user authentication * Enforcing your organisation's password policies and multi-factor authentication * Simplifying user offboarding by allowing you to revoke access from a single point ## Support and Configuration 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. ## Frequently asked questions **Q: Which identity providers can I use?** Any identity provider that supports SAML 2.0, for example Microsoft Entra ID or PingOne. **Q: 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. **Q: 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. **Q: 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. **Q: 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. **Q: Can I set up SSO for Orbit Hub myself?** Not yet. Orbit support sets it up with you.