# Parity — keycloak

Phase-2 P2 mapping table. The Adversary cold-verifies parity by reading the source
`recipe-info/keycloak/tests/<file>` and the cc-ci file side-by-side.

| recipe-maintainer file | cc-ci file | what's verified | status |
|---|---|---|---|
| `recipe-info/keycloak/tests/health_check.py` | `tests/keycloak/functional/test_health_check.py` | The keycloak master realm endpoint (`/realms/master`) returns HTTP 200 — the original's assertion shape, preserved. The cc-ci port adapts to the ephemeral per-run domain via the `live_app` fixture. | **ported** |
| `recipe-info/keycloak/tests/oidc_integration.py` | (deferred to Q3 lasuite-docs) | The original is a **cross-recipe** integration test: it expects both keycloak AND lasuite-docs deployed, with a pre-seeded credentials TOML, and proves a keycloak-issued token is accepted by lasuite-docs. This requires the Phase-2 dependency resolver (Q0.4/Q2.3) + lasuite-docs Phase-2 enrollment. Will land as `tests/lasuite-docs/functional/test_oidc_with_keycloak.py` in Q3, sharing the SSO-setup harness. | **deferred to Q3** (logged in DECISIONS.md) |

## Recipe-specific tests (Phase-2 P3, ≥2 beyond parity)

keycloak's characteristic behavior is **realm/client management + OIDC token issuance**. The
lifecycle overlays already prove the admin API works (`kc_admin.py` creates/queries/deletes a
marker realm across upgrade/backup/restore — Phase 1d/1e). Two new functional tests beyond parity:

| cc-ci file | what's verified | rationale |
|---|---|---|
| `tests/keycloak/functional/test_password_grant_token.py` | Obtains an admin-CLI access token via the password grant (`grant_type=password`) against `/realms/master/protocol/openid-connect/token`, asserts the token is a valid JWT (3 base64url-encoded segments), decodes the payload, and asserts the JWT claims include `iss` matching the live domain, `azp == "admin-cli"`, `typ == "Bearer"`, and a future `exp`. | The defining keycloak behavior is issuing JWTs; this test does the canonical password-grant flow against the real running keycloak (real admin user, real password from the abra-generated secret) and proves the JWT contract is intact. Non-vacuous: a wrongly-configured realm, broken signing key, or wrong issuer would fail the claim assertions. |
| `tests/keycloak/functional/test_create_client_and_use.py` | Authenticates as admin → creates a confidential client in the master realm via admin API with a known `clientId` + a known client secret → obtains a token via `grant_type=client_credentials` for that client → asserts the token's `azp` (authorized party) matches the new client's clientId → deletes the client (idempotent cleanup). | Proves the full lifecycle of admin-API client creation + service-account token issuance, the canonical "real app integrating with keycloak" flow. Non-vacuous: tests TWO grant types (password + client-credentials) and the admin-API CRUD on clients. |

Both tests run in the **custom** tier against the same `live_app` shared deployment as the
lifecycle overlays — no extra deploy, no extra teardown.

## Backup data-integrity (P4)

Already exercised by the lifecycle overlays: `kc_admin.create_marker_realm` (mariadb data) before
backup, mutated by deletion before restore, asserted present after restore. See
`tests/keycloak/{ops.py,test_upgrade.py,test_backup.py,test_restore.py}` + `kc_admin.py`.

## Playwright (P6)

The keycloak admin console (login form) is loaded by `tests/keycloak/test_install.py::
test_serving_and_admin_console` (lifecycle install overlay). Adequate for P6 — the admin UI is the
recipe's primary browser surface.

## Non-ports

`oidc_integration.py` is deferred to Q3 (cross-recipe test; needs lasuite-docs Phase-2 enrollment +
the dependency-resolver harness primitive). Logged in DECISIONS.md Phase-2 section.