SSO is available on the Mountain plan. If you don’t see the SSO tab under Settings, your resort isn’t on the Mountain plan.
How it works
1
A staff member starts sign-in
From your resort’s MtnManager sign-in page, the user chooses Sign in with SSO and is redirected to your identity provider.
2
They authenticate with your IdP
The user signs in with your organization’s credentials (and any multi-factor authentication your IdP enforces).
3
MtnManager creates or links their account
On return, MtnManager looks the user up and, if needed, creates their account automatically with a role based on their identity-provider groups. The user lands in the dashboard, signed in.
Before you begin
You’ll need:- A MtnManager role with permission to manage account settings (Owner and Administrator roles have this by default).
- Your resort on the Mountain plan (see the note above).
- An identity provider that supports OpenID Connect with the authorization code flow.
- Permission, within your IdP, to register a new application.
- The ability to add a DNS record for your email domain — you’ll verify the domain before SSO can be turned on.
Step 1 — Register an application in your identity provider
In your IdP, create a new OpenID Connect / Web application using the authorization code flow. When prompted for the redirect URI (sometimes called the callback URL or sign-in redirect URI), use:Redirect URI
Issuer URL
Your IdP’s base URL, e.g.
https://your-resort.okta.comClient ID
The public identifier for the application you just created.
Client secret
The confidential secret for the application.
Provider-specific notes
- Okta
- Microsoft Entra
- Google Workspace
- In the Okta Admin Console, go to Applications → Create App Integration.
- Choose OIDC – OpenID Connect and Web Application.
- Add the redirect URI above as the Sign-in redirect URI.
- Assign the people or groups who should have access.
- Your Issuer URL looks like
https://your-org.okta.com(or a custom domain). - To let staff launch MtnManager from the Okta tile, also set an Initiate login URI — see Signing in from your identity provider.
- For group-to-role mapping, add a groups claim to the ID token (Sign On → OpenID Connect ID Token) — it isn’t included by default.
Step 2 — Verify your email domain
Before you can turn SSO on, MtnManager needs proof that your resort controls the email domain your staff sign in with. This is what lets SSO safely match a person’s identity-provider email to their MtnManager account. Without it, another organization’s identity provider could assert an email address at your domain and take over an account — so SSO can’t be enabled until at least one domain is verified. You prove ownership by publishing a DNS record we give you.1
Add your domain
Go to Settings → SSO and find the Verified Domains card. Choose Add a domain and enter your bare email domain —
your-resort.com, not a full email address or URL.2
Publish the DNS record
MtnManager shows a TXT record to create with your DNS provider:
Add it at your DNS provider exactly as shown.
3
Verify
Back in MtnManager, choose Verify. Once we can see the record, the domain flips to Verified. DNS changes can take anywhere from a few minutes to a few hours to propagate, so if the first check doesn’t find the record, wait a little and try again.
You can verify more than one domain. Add every domain your staff sign in with (for example, if some use
your-resort.com and others your-resort.ca). SSO matches a user as long as their email is on any verified domain.Step 3 — Configure SSO in MtnManager
In the MtnManager dashboard, go to Settings → SSO and turn on Enable SSO. (The toggle stays disabled until you’ve verified a domain.) This reveals the configuration fields:
Click Save to store the connection. To turn SSO off later, switch off Enable SSO and save, or use Remove SSO to delete the configuration entirely.
Map groups to roles
MtnManager assigns each new SSO user a role automatically based on the groups they belong to in your identity provider. Rather than a single mapping table, you set an SSO group on each role you want to map. To set up mapping, go to the Roles page (under Users → Roles). When SSO is enabled, each role shows an SSO Group column:1
Open a role's SSO group
Find the role you want to map and choose Set SSO Group.
2
Enter the group identifier
In Group identifier, enter the exact group value your identity provider sends. The value depends on your IdP:
- Okta and most other providers — the group name (for example
ski-patrol). - Microsoft Entra — the group’s object ID (like
a1b2c3d4-...), not its name. - Google Workspace — not supported; Google doesn’t send groups, so mapping has no effect.
3
Save
Repeat for each role you want IdP groups to map to.
Group-to-role mapping only applies when a user account is first created. Changing a user’s groups later won’t automatically change their MtnManager role. You can adjust an existing user’s role at any time on the Users page.
Default role
The default role (set on the SSO settings screen) is assigned to any new SSO user whose groups don’t match a role’s SSO group. We recommend choosing the least-privileged role appropriate for general staff (for example Lift Operator), then granting higher roles via group bindings. Alternatively, choose Deny sign-up (no default role) to block sign-in for anyone whose groups don’t match a mapped role. Use this when you want only explicitly-mapped groups to be able to sign in.Automatic user provisioning
The first time someone signs in via SSO, MtnManager resolves their account in this order:1
Existing SSO user
If they’ve signed in via SSO before, they’re matched to their existing account.
2
Existing email match
If a MtnManager user already exists with the same email address in your resort — including someone you invited ahead of time — that account is linked to their identity-provider identity and activated. Their existing role is kept (group mapping doesn’t override it).
3
New user (just-in-time provisioning)
Otherwise, a new active user is created automatically, with a role from your group mapping (or the default role). If the default role is set to Deny sign-up and no group matches, the user is not provisioned.
Inviting staff ahead of time
Automatic provisioning is convenient, but it only assigns a role when someone first signs in. If you’d rather decide a person’s role in advance — for example, to give an incoming manager elevated access from their very first sign-in instead of relying on group mapping — you can invite them before they join.1
Invite the user
On the Users page, choose Add user, enter their name and email, and assign the role(s) you want them to have. Use the email address they’ll sign in with at your identity provider, on one of your verified domains.
2
They sign in with SSO
The invited person signs in through your identity provider as normal — there’s no password to set.
3
MtnManager links and activates them
On that first sign-in, MtnManager links the invitation to their identity-provider identity, keeps the roles you assigned, and activates their account.
Roles you assign at invite time take precedence over group mapping: the user keeps the roles from their invitation rather than being assigned a role from their groups. You can change them later on the Users page.
The email address on the invitation must be on a verified domain or sign-in won’t link to the invited account. This is the same protection that applies to automatic provisioning.
Signing in with SSO
Once SSO is enabled, your resort’s sign-in page shows a Sign in with SSO button beneath the email/password form. Staff click it to be taken to your identity provider and back, signed in. The button only appears on your resort’s own subdomain.Signing in from your identity provider (IdP-initiated)
As well as starting from MtnManager’s sign-in page, your staff can launch MtnManager directly from your identity provider — for example by clicking the MtnManager tile on their Okta dashboard or Microsoft MyApps page. This is called IdP-initiated sign-in. It uses the same secure OpenID Connect flow under the hood: clicking the tile sends the user to MtnManager, which immediately bounces them to your IdP to authenticate and then back, signed in. No separate setup is required beyond the steps below. To enable it, set the Initiate login URI (sometimes called the app launch URL or initiate login URL) in your IdP application. You can copy the exact value from the Initiate login URI field on the SSO settings screen (Settings → SSO); it looks like:Initiate login URI
- Okta
- Microsoft Entra
- Google Workspace
- Open your MtnManager app integration, then General → Settings → Edit.
- Under Login, set Login initiated by to Either Okta or App.
- Set Initiate login URI to the URL above.
- Under Application visibility, tick Display application icon to users so the tile appears on users’ Okta dashboards.