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.

Add and remove people from your directory (SCIM)

Single sign-on decides who can sign in. SCIM decides who is a member at all. With it, Okta or Microsoft Entra ID creates a member in FileMentra when you assign someone the app, and suspends or removes them when you unassign or deactivate them there, ending every session they have open at that moment. Nobody has to remember to remove a leaver in a second place.

Step six of the Single sign-on panel shows the SCIM base URL and lets you create a provisioning token. The token is shown once; paste it into your provider as the secret token and FileMentra keeps only a keyed fingerprint of it. A workspace can hold three tokens, and revoking one stops it at once.

A directory can do less than an administrator can. It can only add addresses on your verified domains, so a leaked token cannot pull an outside account into your workspace. It never changes an owner, so deactivating the wrong person in the directory cannot lock you out. New members get the same default role as a first single sign-on, and they take a seat on your plan like an invitation does.

1. 1

   Verify your email domains in step three.

2. 2

   In step six, create a token and copy it together with the SCIM base URL.

3. 3

   Okta: in the FileMentra app, enable SCIM provisioning, set the connector base URL, choose HTTP Header authentication, paste the token, and turn on Create Users, Update User Attributes and Deactivate Users.

4. 4

   Microsoft Entra ID: in the enterprise application, open Provisioning, choose Automatic, paste the SCIM base URL as the Tenant URL and the token as the Secret Token, test the connection, and start provisioning.

5. 5

   Assign people or groups to the app in your provider.

• Users are matched by email address, so members who already exist are linked rather than duplicated.
• The email address of an existing member cannot be changed from the directory; remove and re-assign the person instead.
• Deactivating a person suspends the membership and ends their sessions; deleting them removes the membership.
• Group push is not supported yet: assign groups to the app and people are provisioned individually.
• Every create, suspension, restore and removal is written to the audit trail with the token that made it.