Single Sign-On

Sign in to Bedrock GRC through your firm's identity provider: set up Microsoft Entra ID or Google Workspace, link accounts, require single sign-on, and fix common problems.

Each firm that signs in to Bedrock GRC (Foxx Cyber itself, or a partner assessment firm) can sign its people in through its own identity provider: Microsoft Entra ID, Google Workspace, or any other provider that speaks OpenID Connect, such as Okta or Keycloak.

Single sign-on changes how people sign in, not who has an account:

• Accounts still come from the Team page. Signing in through a provider never creates an account.
• Nobody is matched or linked by email address. Each person links their own account once, while signed in (below).

Who sets it up

Admins set single sign-on up on the Single sign-on page (under Practice in the sidebar), one firm at a time. When there are partner firms, pick the firm at the top of the page and choose Switch.

For a partner firm, the firm's own identity administrator registers Bedrock GRC with their provider and gives the resulting values to their Foxx Cyber contact, who enters them. Agree with Foxx Cyber on a safe way to pass the client secret; not plain email. Questions go to support@foxxcyber.com.

Before you start

You need the redirect URI. The Single sign-on page shows it at the top with a Copy button: it is your Bedrock GRC address followed by /login/sso/callback. Register it with the provider exactly as shown, character for character.

Set up Microsoft Entra ID

In the Microsoft Entra admin center (as an Application Administrator or higher):

1. Go to Entra ID → App registrations → New registration.
2. Name it Bedrock GRC. Under Supported account types, choose Accounts in this organizational directory only (single tenant).
3. Under Redirect URI, choose the Web platform and paste the redirect URI. Select Register.
4. On the app's Overview, copy the Application (client) ID and the Directory (tenant) ID.
5. Under Certificates & secrets → Client secrets → New client secret, add a secret with an expiry, and copy its Value straight away (not the Secret ID; the value is shown once). Put a reminder in your calendar before it expires.
6. Recommended: under Enterprise applications → Bedrock GRC → Properties, set Assignment required? to Yes and assign the people or groups who may use it. Put multi-factor sign-in on it with a Conditional Access policy.

Then, on the Single sign-on page in Bedrock GRC:

Leave Trust the provider's multi-factor sign-in off for Entra ID: its sign-in tokens don't say whether multi-factor sign-in happened, so Bedrock GRC keeps asking for its own two-step code.

Set up Google Workspace

In the Google Cloud console, in a project that belongs to your Workspace organization:

1. Open Google Auth Platform (called OAuth consent screen in older consoles). Under Branding, enter the app name Bedrock GRC and a support email. Under Audience, set the user type to Internal, so only your organization's accounts can sign in.
2. Under Clients, choose Create client, then Web application. Name it and add the redirect URI under Authorized redirect URIs. Choose Create and copy the Client ID and Client secret.
3. Bedrock GRC asks only for the openid and email scopes, which need no review.

Then, on the Single sign-on page:

Leave Trust the provider's multi-factor sign-in off for Google; it does not report multi-factor sign-in reliably.

Other providers

Enter the issuer exactly as the provider's discovery document states it, with or without a trailing slash as it does. Register the redirect URI as a confidential web application that uses the authorization code flow.

Save and test

1. Choose Save. The client secret is stored encrypted and is never shown again; leave the field blank later to keep it.
2. Under Check the provider, choose Test the connection. It checks that the provider answers and publishes its signing keys. It cannot check the client ID and secret: the first real sign-in does that.
3. Link your own account (below) to prove the whole setup.

An email domain belongs to one firm only. On the sign-in page, the domain of the email a person types decides which firm's provider they are sent to.

Link an account

Each person links their own account once:

1. Sign in as usual, with your password (and two-step code, if it is on).
2. Open Account → Single sign-on.
3. Type your password again, and a two-step code if two-step sign-in is on. Choose Continue to your provider.
4. Sign in at the provider with the account your firm gave you. You come back to Bedrock GRC with the account linked.

From then on, choose Sign in with single sign-on on the sign-in page, type your work email, choose Continue, then continue to your provider.

The People in firm table on the Single sign-on page shows who has linked, who has not, and who is still linked to a provider the firm no longer uses. Unlink removes someone's link and signs them out; they sign in with their password until they link again. People can also unlink themselves from Account → Single sign-on, unless the firm requires single sign-on.

Rules

Require single sign-on

With Require single sign-on on, people in the firm who have linked their account can no longer sign in with their password. When one of them types it, the password is refused and the sign-in page comes back with the message "Your firm signs in with single sign-on" and the Sign in with single sign-on button first, so there is no dead end.

• Admins keep their password, so a provider outage or a wrong setting never locks the practice out.
• People who have not linked yet keep using their password until they link.
• Only an admin can unlink someone. People cannot unlink themselves from Account while the rule is on.

Turn it on only after the people concerned have linked.

When single sign-on cannot run

Single sign-on needs the deployment's file encryption key (FILES_KEY), which protects the client secret. Without it, nobody can sign in through the provider, but the rule still holds: a missing key never turns Require single sign-on off and never lets people unlink themselves.

• A linked person's password is refused with a message saying single sign-on is not available right now and that an admin can unlink their account. There is no single sign-on button to offer.
• An admin unlinks them from the People in firm table; they then sign in with their password. Admins keep their own password throughout.
• The Single sign-on page says the key is missing and cannot be saved until it is configured. When the key comes back, the rule applies again as before.

Trust the provider's multi-factor sign-in

By default, Bedrock GRC's own two-step sign-in still applies after single sign-on: people with a code are asked for it, and anyone the team policy covers who has none is sent to set it up.

With Trust the provider's multi-factor sign-in on, the code is skipped when the provider reports that multi-factor sign-in happened (its token says so). That session then counts as two-step for the team policy and for assessors. It keeps counting only while the person stays linked to the firm's current provider and the firm keeps trusting it. Assessors always need either this or the app's own code. The audit log records these sign-ins as mfa:idp, so it never claims the app's own code was used.

Use it only with a provider that reports multi-factor sign-in, such as Okta or Keycloak configured to. Microsoft Entra ID and Google do not.

Changes sign people out

• Changing the issuer, the client ID or either rule, or removing single sign-on, signs out everyone in that firm who has linked (except the session the change is made from), so the new setting applies at once. Changing only the email domains or the client secret signs nobody out.
• A new client ID also unlinks everyone in the firm, because some providers, Microsoft Entra ID among them, give each app registration its own user IDs. People sign in with their password and link again. Rotating only the client secret keeps every link.
• Remove single sign-on, at the foot of the Check the provider card, turns single sign-on off for the firm after a confirmation: everyone signs in with their password again.

Every setup change, link, unlink and single sign-on sign-in is written to the audit log, under Single sign-on (all): Single sign-on settings saved, Single sign-on removed, Account linked to single sign-on, Account unlinked from single sign-on and Signed in with single sign-on. So are refused sign-ins:

• Single sign-on sign-in failed (sso.failed): the provider turned the sign-in down, the exchange with it did not complete, a Google account was outside the firm's Workspace domains, the provider account is not linked to anyone here, or single sign-on was removed while the person was at the provider. The person is not known yet, so the entry names the firm (firm:N) and shows System as who.
• Single sign-on refused: account disabled or locked (sso.refused): the linked account is disabled, or locked after failed sign-ins. It is recorded under the person (user:N).

A password refused because the firm requires single sign-on is recorded as Password refused: the firm requires single sign-on, and a two-step code refused while linking as Two-step code refused on Account. Linking spends the same password and code tries as the rest of Account. Attempts turned away as too many, and returns from the provider that carry no sign-in started here, are not recorded, so nobody can fill the log by sending them.

Locked accounts

A lockout after failed sign-ins holds here too. While an account is locked, single sign-on refuses it with "Too many failed attempts: this account is locked for a few minutes", unless the person is using a browser they have signed in from before. A refused single sign-on never ends the lock; it ends when it runs out, when an admin chooses Unlock now, or when the person signs in from that known browser. See Lockout after failed attempts.

Troubleshooting