Single sign-on with SAML

What single sign-on changes

With single sign-on your colleagues stop keeping a separate FileMentra password and sign in through the identity provider your organization already runs, such as Okta, Microsoft Entra ID, or Google Workspace. Joiners and leavers are then handled where they should be, in the directory, rather than in a second place that drifts out of step.

The connection is configured in Security Center under Single sign-on. The panel is one column in the order the work actually happens: describe your provider, describe us to your provider, prove the domains are yours, decide what a first sign-in creates, and switch it on. Nothing later is reachable until the step before it is done.

Connect the identity provider

Create a SAML application for FileMentra in your provider, then copy three values back into step one: the provider's entity ID, its sign-on URL, and its signing certificate. The sign-on URL must be an https address, because an assertion travelling in clear proves nothing. Step two gives you the two values your provider needs from us, so you can paste them straight into the SAML application.

The stored certificate is never shown back in full once saved. Rotate it here when your provider issues a new one.

1. 1

   Create a SAML application for FileMentra in your identity provider.

2. 2

   Copy the entity ID, sign-on URL, and signing certificate into step one.

3. 3

   Copy our entity ID and reply URL from step two into your provider.

4. 4

   Save the connection.

Prove your email domains

Only verified domains route to your provider. Add each domain your staff use, publish the TXT record shown for it in your DNS, and verify. Until that record is live and confirmed, the domain does not route and cannot be used to make sign-on mandatory.

A domain belongs to one connection across all of FileMentra, so another workspace cannot claim a domain you have proved. This is what stops a stranger configuring a provider that asserts your staff.

First sign-in and making it mandatory

Step four decides what happens when somebody signs in for the first time. With provisioning on, a colleague who reaches FileMentra through your provider gets an account automatically on the role you choose. Owner cannot be chosen, because configuring an identity provider must not be a way to hand out ownership.

Step five switches the connection on and, separately, makes it mandatory. With enforcement on, password sign-in is refused for addresses on your verified domains, checked before the password is even looked at. This is the control auditors and security questionnaires are really asking about: not whether federated sign-in is supported, but whether your people can go around it.

• Enforcement requires at least one verified domain.
• Removing the last verified domain while enforcement is on is refused.
• A suspended or removed member is refused even with a valid assertion.
• Sign-in attempts, refusals, and provisioning are written to the audit trail.