FEAT: Security & Azure deployment for CoPyRIT GUI

[adrian-gavrila]

Description

Adds authentication, security middleware, Azure infrastructure-as-code, and a CI/CD pipeline for deploying the CoPyRIT GUI as an
Azure Container App.

Authentication

• Frontend: MSAL PKCE auth via @azure/msal-browser — no client secrets needed. New AuthProvider and msalConfig components;
  Axios interceptor attaches Bearer tokens automatically.
• Backend: FastAPI JWT middleware (pyrit/backend/middleware/auth.py) validates tokens against Entra ID JWKS. Supports multi-group
  authorization via allowedGroupObjectIds. Auth gracefully disables when env vars are unset (local dev).
• Auth info endpoint (/api/auth/me) for the frontend to display the signed-in user.

Security middleware

• SecurityHeadersMiddleware: CSP, HSTS (prod only), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy,
  Cache-Control (no-store on API routes). Swagger disabled in production.

Infrastructure (Bicep)

• infra/main.bicep + ARM template: provisions Container App Environment, ACR (optional), Log Analytics, Application Insights
  (opt-in OTel), User-Assigned Managed Identity, and VNet/Private Endpoint (opt-in).
• Key Vault secret references for .env injection — no secrets baked into the container.
• infra/README.md: full deployment guide covering prerequisites, Entra setup, RBAC grants, and post-deployment steps.

CI/CD

• gui-deploy.yml: ADO pipeline — build → push to ACR → deploy to test → opt-in prod promotion.

Docker

• Updated Dockerfile, start.sh, and docker-compose.yaml for managed identity auth on Azure and service principal auth locally.
• .pyrit_conf_example with operator/operation label examples.

Tests and Documentation

• frontend/src/App.test.tsx and frontend/src/services/api.test.ts updated to cover auth integration.
• infra/README.md serves as the deployment guide with full prerequisites, step-by-step setup, post-deployment checklist, and
  teardown instructions.
• docker/QUICKSTART.md updated with auth configuration and local dev workflow.
• No Jupyter notebooks were added or modified; JupyText not applicable.

[romanlutz]

We should put all the ADO pipelines in a dedicated folder at some point...

[behnam-o]

I'm wondering if we have a way to test if this path gets hit (i.e. too many groups -> call graph to get group memberships) to validate this logic is working as expected (group overage)

I believe in order to call this endpoint, we'd need a token issued for calling graph, (i.e scope must be something like https://graph.microsoft.com/<scope> but the token we send to this backed server is the one we fetch on the front end, and the audience for it is <copyrit-client-id>/access ... so calling graph with with throws a 401.

I think the reason we never see this in tests env is the group claim is always populated with the group that warranted our access to the app. (maybe this happened after we "require assignment" on the app? I remember at some point we did have the _claim_sources somewhere)

[behnam-o]

thinking more about this, I'm wondering if we need to even have a token whose audience is the copyRIT app, if all we're doing is checking group memberships of a user?

and instead, simply get a graph token from the beginning (ie. in the front end, set "loginScope ="https://graph.microsoft.com/User.Read"

and not even expose the access scope on our app and try to get a token with that scope. that scope itself is not used after all. it looks like all we're using it for is, in conjunction with this fact:

Access tokens include the groups claim when the app manifest has groupMembershipClaims: "SecurityGroup" configured.

to get a token that has group memberships included in it

(this could be a follow-up optimization, and will probably make our token usable against graph.microsoft.com if we want to handle group overage)

[behnam-o]

from our chat, I think this might be more optimal and cleaner, and also address my other comment:

1. add back Microsoft Graph's User.Read delegated API permission to the app registration
2. in getApiScopes in the frontend, request a token with this scope ["https://graph.microsoft.com/User.Read"]
3. then group resolution will work okay (because the token that's sent to our backend will have graph as its audience)
4. now you can remove access from "exposed APIs" of the app because it's not used anyways
5. we can also remove the "App Roles" (Copyrit.Dev.All) , and instead assign those 2 groups to the ServicePrincipal (Enterprise Application) with the default role (we can do that even right now, because we don't check this role value in user claims)