Skip to content

UC-12 Deploy to another CSU campus (stretch)
Primary actor ITS at the new campus
Priority Could
Satisfies FR-A5, NFR-4, NFR-2
Precondition The campus has a SAML IdP and can register a service provider.
Trigger A second campus wants to run its own challenge.

Main success scenario

  1. ITS registers the campus IdP with the service provider metadata and maps the IdP's issuer to a campus_id.
  2. ITS deploys the same images with the campus's own configuration: secrets, staff-role map, posture, database.
  3. The campus authors its own challenges (UC-5). Every stored row is scoped by campus_id, so nothing crosses campuses.

Extensions

  • 2a. Configuration incomplete. The API refuses to boot in production on a missing posture, a default or placeholder secret, a template database URL, or a staff-role map that grants a role to a bare affiliation.
  • Same deployment, second campus. Not supported today: one deployment serves one campus's IdP mapping.

Acceptance criteria (Gherkin)

The deployment-path features carry this use case's tag. The rest of its guarantees are operational requirements proved by the boot-validation features under "Operations" in the requirements catalog.

Feature file Test module
deployment_path.feature test_deployment_path_bdd.py (needs docker)
browser_deployment_path.feature test_browser_deployment_path_bdd.py (browser tier)
credential_boot_validation.feature test_credential_boot_validation_bdd.py
staff_role_map_provisioning.feature test_staff_role_map_provisioning_bdd.py
production_env_declaration.feature test_production_env_declaration_bdd.py

Views

Code: backend/app/config.py, backend/app/services/campus.py, infra/lib/campus-idp.ts (derives SAML values from the committed metadata, never transcribed). ADR 0001 is the hosting decision; docs/saml/ holds the integration checklist.