Skip to main content

Identity & SSO

Radar action items for authentication, SSO enforcement, and user identity controls. Each item below describes the problem, why it is a risk, a concrete example of what can go wrong, and the step-by-step fix in Willow.

SSO Not Configured​

Problem. Your organization is using the default email/password authentication provider instead of an external identity provider such as Okta, Google Workspace, Azure AD, Auth0, Keycloak, JumpCloud, or ADFS.

Why it is a risk.

  • Identity events (new hire, role change, termination) live in your IdP. Without SSO, every change has to be replayed manually inside Willow.
  • Email/password accounts are easier to phish, harder to enforce MFA on, and rarely covered by your conditional access or device posture policies.
  • There is no central place to disable a user, so a compromised or terminated account may keep access to MCP servers, tools, and audit data.

Example. A contractor leaves the company. IT removes them from Okta on Friday but the Willow-only password account stays active over the weekend. The contractor signs in from a personal device and exfiltrates data through a connected MCP server before the account is manually disabled.

How to solve it.

  1. Open Admin > Settings > Authentication.
  2. Choose your identity provider (Okta, Google, GitHub, Azure, Auth0, Keycloak, JumpCloud, or ADFS).
  3. Paste the client ID, client secret, issuer or tenant ID, and any other required values from your IdP.
  4. Save the configuration and click Test Sign-In with at least one admin account.
  5. Once a successful round trip is confirmed, ask other admins to sign in with SSO before considering the rollout complete.
  6. Continue to the SSO Not Enforced item to remove the local fallback.

SSO Not Enforced​

Problem. SSO is configured but not enforced. Users are still allowed to authenticate with the default provider in addition to SSO.

Why it is a risk.

  • Local accounts can bypass MFA, conditional access, IP allowlists, and device posture rules that are configured in your IdP.
  • Attackers who phish a Willow password do not need to defeat your IdP, the local login is enough.
  • Joiner/leaver automation in your IdP cannot disable accounts that exist outside it.

Example. A user enables MFA in Okta but their Willow password is reused from a breached service. An attacker logs in with the password, never has to face MFA, and accesses sensitive integrations.

How to solve it.

  1. Open Admin > Settings > Authentication.
  2. Confirm at least one admin user can successfully sign in through SSO.
  3. Toggle Enforce SSO on.
  4. Communicate the change to users and document the recovery contact (an owner who still has SSO access).
  5. Optionally, audit the user list and remove any local accounts that should no longer exist.

Approved Clients Disabled​

Problem. Any MCP client that can reach the gateway URL is allowed to connect. There is no allowlist of approved clients.

Why it is a risk.

  • Unknown clients can be used to enumerate tools, attempt prompt injection, or copy data into unmanaged contexts.
  • It is hard to audit who is calling the gateway because client identity is not constrained.
  • Internal users can experiment with random clients that bypass your usability and compliance review.

Example. A developer installs a brand-new community MCP client to try it out. It works against your gateway because nothing prevents it. The client logs the user's prompts to its own backend, leaking customer data.

How to solve it.

  1. Open Admin > Settings > Security (or Monitor > Security depending on your version).
  2. Enable Approved Clients Only.
  3. Review the existing tool list under Manage > AI Tools.
  4. Add the clients your organization wants to support (Cursor, Claude, GitHub Copilot, Codex, etc.).
  5. Inform users that unapproved clients will stop working and tell them how to request a new client.
On this page