# odoo_mcp_sso — Team-gateway / Microsoft-SSO add-on for `odoo-mcp-guard`

This folder is a **self-contained, extractable package** (`odoo_mcp_sso`) that adds
team-gateway mode (ADR-017) and Microsoft SSO login (ADR-018) on top of the
`odoo-mcp-guard` core. Business users authenticate in their browser with their
usual Odoo login through an OAuth 2.1 authorization-code + PKCE flow (the
MCP-standard client flow); every tool call then executes against Odoo **as that
user** — Odoo ACLs, record rules, and multi-company all apply per user, the
policy file restricts on top, and audit lines are nominative.

## Design: it consumes the MIT core, UNMODIFIED

The dependency is strictly one-directional: **`odoo_mcp_sso` imports the core; the
core never imports `odoo_mcp_sso`** (enforced by an import-linter contract in the
root `pyproject.toml`: "Core never imports the SSO package"). The core stays
gateway-unaware — `build_server` resolves each request through a
`RequestContextResolver`, and this package supplies a `GatewayResolver` for
gateway mode while the core's default `SingleUserResolver` is untouched.

What this package consumes from the core (all public, unmodified):

- **`odoo_mcp_guard.server.context.RequestContextResolver`** — the per-request
  seam. `GatewayResolver` (in `odoo_mcp_sso.users`) implements it structurally.
- **`odoo_mcp_guard.server.identity`** — the identity contract
  (`UserIdentity`, `UserSession`, `CredentialVault`). These live in the **core**,
  not here, so the core can speak the contract without importing this package.
  `odoo_mcp_sso` re-exports them for its own consumers.
- **`odoo_mcp_guard.server.unconnected.UnconnectedClient`** — the fail-closed
  base-profile placeholder. Lives in the **core** (depends only on `errors` +
  `odoo.api`, no gateway logic).
- **`odoo_mcp_guard.odoo.session_client.SessionClient`** — stays in the **core by
  design**. It is a generic `OdooClient` over an Odoo web-session cookie with no
  gateway import; the core wires it via `odoo.detect.make_session_client`, and the
  SSO package consumes it through that core function (Microsoft SSO `odoo_session`
  auth method). It is NOT moved into this package.
- `odoo_mcp_guard.config` (`ProfileConfig`, `load_profile`), `odoo_mcp_guard.errors`,
  `odoo_mcp_guard.audit`, and the `odoo` client/transport layer.

## Package contents

| Module | Role |
|---|---|
| `odoo_mcp_sso/auth.py` | OAuth 2.1 AS + PKCE, `/authorize` browser login, `/token`, RFC 8414/9728 metadata, Microsoft-SSO relay (ADR-018), `make_odoo_validator`, `make_ms_sso`, `mount_gateway`, bearer/vault middleware |
| `odoo_mcp_sso/users.py` | `UserClientPool` (per-user client cache), `GatewayResolver` (the `RequestContextResolver` impl), `GatewaySessionMissingError` |
| `odoo_mcp_sso/vault.py` | `InMemoryVault` (TTL, never persisted — Rule 1 #7) |
| `odoo_mcp_sso/types.py` | `GatewayConfig` (gateway-mode wiring; identity types live in the core) |

## How it is wired today (in-tree)

This package is a **uv workspace member** of the core repo (`[tool.uv.workspace]
members = ["SSO_MICROSOFT"]` in the root `pyproject.toml`). One
`uv sync --all-packages` installs both the core and this add-on editable, so a
single `uv run python -m pytest` from the repo root collects both core and SSO
tests (`SSO_MICROSOFT/tests` is in `testpaths`).

The gateway is activated entirely from the core's `serve.py` on the `--gateway`
path via **function-local** imports of `odoo_mcp_sso` (the only allowed
core→sso edge, whitelisted in the import-linter contract):

```python
# odoo_mcp_guard/server/serve.py (gateway path only)
from odoo_mcp_sso.users import GatewayResolver, UserClientPool
from odoo_mcp_sso.vault import InMemoryVault
from odoo_mcp_sso.auth import GatewayAuthApp, make_ms_sso, make_odoo_validator, mount_gateway
from odoo_mcp_sso.types import GatewayConfig
```

## Extracting this into its own repository later

Because the dependency is one-directional and the core is consumed unmodified,
lifting this out is mechanical:

1. **Move the folder out** of the core repo into a new repository
   (`SSO_MICROSOFT/` → the new repo root; `odoo_mcp_sso/` is the package,
   `tests/` are its tests).
2. **Replace the workspace dependency with a pinned core release.** In the new
   repo's `pyproject.toml`, drop `[tool.uv.sources] odoo-mcp-guard = { workspace
   = true }` and pin a published `odoo-mcp-guard` version (PyPI release or git
   tag). Then `pip install odoo-mcp-guard` (or `uv add`).
3. **Wire `serve` in the new repo.** The core's `serve.py` keeps only its two
   self-host transports (stdio + single-credential bearer HTTP). Move the
   `--gateway` flag and the `_build_gateway_app` / `mount_gateway` wiring into the
   new repo's own entrypoint, which calls `odoo_mcp_guard.server.app.build_server(
   runtime, resolver=GatewayResolver(...))`.
4. **`SessionClient` stays in the core** — do not copy it. The new repo reaches it
   through `odoo_mcp_guard.odoo.detect.make_session_client`, exactly as it does
   in-tree.

Nothing in the core has to change to support the move: the seam, the identity
types, and `SessionClient` are already in their permanent homes.