Single sign-on

Single sign-on lets you use the firm's Microsoft Entra ID or Google Workspace account at your firm's LFMS address. The firm chooses one provider. Your administrator must already have created and activated your LFMS account; signing in never creates a new person.

Sign in

Choose Sign in with Microsoft or Sign in with Google. Use your firm account at the provider, then return to LFMS. If LFMS asks for a code, enter your authenticator or emailed code, or use a recovery code where offered. An unknown account, an inactive account or somebody on leave cannot sign in.

A verified firm email links your account on the first successful sign-in. After that, the linked provider identity identifies you even if your email at the provider changes. A provider account must not be shared between people.

Set up Microsoft Entra ID

You need access to the firm's Entra application registrations and the LFMS permissions to manage settings and integrations.

1. Open Settings > People and access > Single sign-on. Copy the Redirect URI.
2. In the Microsoft Entra admin centre, register a web application for Accounts in this organizational directory only. Register the copied URI as its Web redirect URI. Use the firm's directory tenant, never common.
3. Note the application client ID and the directory tenant ID. Create a client secret and keep its value securely.
4. In LFMS Settings > Integrations, open Microsoft Entra single sign-on and save the client ID and secret. Credentials are encrypted; the secret is not shown back to you.
5. Return to Single sign-on and choose Edit setup. Select Microsoft Entra ID, enter the tenant ID, and keep the mode Optional. Decide whether to trust provider MFA, give the reason, then Save setup. Confirm your identity when asked.
6. Choose Test sign-in. Complete the provider sign-in as your own LFMS account. It replaces your local session. Return to this settings page to read whether this session has tested the saved setup.

Use Microsoft's application configuration guidance and redirect URI guidance when registering the application.

Set up Google Workspace

1. Copy the Redirect URI from the Single sign-on setup page.
2. In the firm's Google Cloud project, configure the OAuth consent screen for your organisation and create a Web application OAuth client. Register the copied URI as an authorised redirect URI.
3. Save that client's ID and secret in Settings > Integrations > Google Workspace single sign-on.
4. Choose Edit setup, select Google Workspace and enter the firm's lower-case hosted domain, such as firm.com. Keep Optional, give a reason, save and complete Test sign-in.

LFMS checks the verified email and the hosted-domain claim. A personal Gmail account or another Workspace domain is refused. The setup is separate from a Google Calendar connection. Google's OpenID Connect guidance explains web credentials and redirect registration.

Decide who provides the second factor

Trust provider MFA defaults to on. For Microsoft, the sign-in proof must say that MFA was completed; otherwise LFMS asks for its own second factor. For Google, turning trust on means the firm accepts responsibility for enforcing two-step verification in Workspace. This is a security administration choice, not a legal threshold.

With trust off, LFMS always asks for its own second factor. A person without an enrolled authenticator completes an emailed code. Emergency password sign-in always requires LFMS MFA and cannot remember a device to skip it.

Make single sign-on required

Start with Optional. Make sure the managing partner and one other suitable person can use emergency local access and have working passwords and second factors.

1. Successfully complete Test sign-in in the session that will save Required.
2. Open Edit setup, change Mode to Required, give the reason and save. Complete fresh identity proof when asked.
3. Tell staff to use the provider button. The password form now waits behind Sign in with a password (break-glass).

The system refuses Required until this session has successfully signed in through the exact saved provider, tenant or domain and MFA-trust setup, and an active emergency holder exists. Changing that setup needs a new test. Save the changed setup as Optional, test it, then require it.

Keep emergency access ready

The Emergency accounts tab lists the holders. At most two people can hold local bypass. The managing partner always holds it: their row reads "Managing partner, always holds it" and offers no removal. Only the managing partner may appoint or remove the other holder, with fresh proof and a reason.

Choose Add holder, search for an active person with an activated account and a password, give the reason and confirm. To change the second holder when both slots are full, remove that holder first. A refusal names the people occupying the slots and links to their records.

During a provider outage, a holder opens the password disclosure and signs in with their password and LFMS MFA. Each successful emergency sign-in is audited and tells every other holder and the firm administrators through in-app and email notices. Bypass permits local sign-in only; it grants no extra permissions and does not lift an ethical wall.

Read and unlink a sign-in identity

Your own Security page shows your linked identity. A person's record has Sign-in methods in the rail and an identity-history tab, searchable by provider, issuer or subject and by linked date.

An administrator with Manage people may Unlink a live identity, giving a reason and confirming their identity. This retires the link, preserves its dated history, and signs out sessions linked to it. If it is your own current SSO session, you return to sign-in. Before unlinking, check how the person will regain access; required mode still refuses an ordinary password account.

Confirm identity, unlock and sign out

Sensitive actions and unlocking an SSO session ask you to sign in again through the provider. A sign-in window keeps the original page and its pending work open. Allow that window in your browser. Use the same provider account you used for this session; a different identity cannot confirm it. If you cancel or the request times out, try again. Local password sessions continue to use their password and enrolled LFMS second factor. If the firm has changed or disabled the provider used by a locked session, sign out and sign in again through the current setup.

Signing out always ends the local LFMS session. Where Microsoft publishes its sign-out address, the sign-in page also offers Sign out of Microsoft too. Ending the provider session does not replace local sign-out. Provider-initiated back-channel logout and SAML are outside this release.

If sign-in cannot be completed, try again or ask an administrator to check the saved provider, tenant or domain, credentials and exact redirect URI. Keep the provider's own errors and credentials private.