Single sign-on

Let people sign in to mTime with your organisation’s own identity provider, and restrict a workspace so that it is the only way in.

Overview

mTime can sign people in with Google, Microsoft or Visma Connect, and a workspace can be restricted to just one of them.

mTime is a client of your identity provider, not an identity provider itself. When someone signs in with Microsoft, the whole of the sign-in — username, password, multi-factor and any conditional access rules you apply — happens in your own tenant, and the sign-in is recorded in your own logs. There is no federation between your tenant and ours, and no user accounts are created on our side.

How it works

1. The person chooses Sign in with Microsoft — or Google, or Visma Connect.
2. mTime sends them to the provider, where they authenticate under your own rules.
3. The provider sends them back, and mTime reads four things: a stable user id, an email address, a full name and a first name. Nothing else — no mail, no calendar, no files, no directory access.
4. mTime looks the person up. If they do not already exist in mTime, the sign-in is refused.
5. mTime issues its own session.

Signing in does not grant access

A valid sign-in at your identity provider gives access to nothing on its own. The person must already exist as a user in mTime, and users are created in only three ways: by SCIM provisioning from your identity provider, automatically from employment data, or by an administrator inviting them. There is no self-service sign-up.

A first sign-in also needs the invitation sent to the provisioned address — a single-use link that expires. mTime never attaches a provider account to an existing user on the strength of an email address alone.

So there are two layers, and they are kept apart. Your identity provider decides who someone is. The user record in mTime decides what they may do: it holds roles and employment, never a credential.

Configuration

An owner or Workspace Administrator restricts a workspace under Admin › Workspace, using two settings together:

• Single sign-on provider — the one provider this workspace accepts
• Allowed email domains — the domains your organisation owns, such as ku.dk

Both are required. A provider on its own is not a restriction, so mTime will not save one without at least one domain.

Once it is on, for that workspace:

• Everyone signs in with that one provider, and their mTime account address must be at one of the listed domains.
• Every other way in is refused: passwords, passkeys, the other providers, mTime support, and any session created before the restriction.
• Invitations tell people which provider to sign in with. You can only invite addresses at the listed domains.

Before you switch it on

You — the administrator making the change — must already have signed in with the chosen provider, and your own mTime address must be in one of the listed domains. Otherwise mTime refuses the change and tells you which half is missing.

It asks this of you rather than of any administrator because saving the change signs you out too. This way, the person who switches the restriction on can always sign back in and switch it off again.

What happens when you switch it on

Everyone in the workspace is signed out, you included, and signs back in with the chosen provider.

The same happens whenever you change the restriction so that it lets fewer people in: switching to a different provider, or removing a domain. Adding a domain signs nobody out.

Switching it off

Clear the Single sign-on provider . The restriction is lifted straight away and nobody is signed out. You can leave the domain list in place, so switching it back on later is a single setting.

It applies to us as well

There is no override inside mTime: mTime support cannot reach a restricted workspace either. If you want our help inside the workspace, an administrator switches the restriction off, and on again afterwards.

Troubleshooting

For your IT and security team