feat: LTI 1.3 integration (optional module 'lti')

[italovalcy]

What

Integrates the Dashboard as an LTI 1.3 tool (Moodle-first, platform-agnostic), shipped as the optional module lti (OPTIONAL_MODULES=clabs,lti), built on PyLTI1p3 2.x.

New blueprint under /lti:

Endpoint	Purpose
/lti/login/	OIDC third-party-initiated login — logs incoming iss/client_id/target_link_uri and the outgoing redirect (these lines solve most integration failures)
/lti/launch/	Message launch: validates the id_token, provisions/logs in the local user
/lti/jwks/	Public keyset — active keys plus retired keys still in their grace period
/lti/register/	LTI Dynamic Registration (credential-gated)

How it works

• Platform config in the DB: lti_config table keyed by issuer (LMS base URL, exact string, no trailing slash — normalized on write), holding a JSON-encoded per-issuer list of registrations {client_id, auth_login_url, auth_token_url, key_set_url, deployment_ids, private/public key files} (key paths relative to DATA_DIR). A ToolConfDict subclass rebuilds the pylti1p3 config from the DB per request, so every worker sees new registrations without restart.
• Dynamic registration is the onboarding path: gated by one-time tokens (flask lti mint-registration-token, stored hashed, consumed only on successful registration) or static LTI_REGISTRATION_KEY/SECRET; disabled when neither is configured. Each registration gets its own fresh RSA-2048 keypair; orphan keys are removed if the platform rejects the registration.
• Key rollover (publish-then-switch): flask lti rotate-key publishes the new key, switches the registration to it and retires the old pair into DATA_DIR/lti/keys/retired/, whose public halves stay merged into /lti/jwks/ until flask lti purge-retired-keys (cron-friendly) removes them after the grace period.
• User provisioning: launches create/reuse a Users row keyed by (issuer, subject) — later logins inherit the same account; name/e-mail sync from fresh claims; accounts are passwordless (local sign-in already rejects those). Role mapping is promotion-only: Learner→student, Instructor→teacher, never demoting teacher/labcreator/admin. Logins recorded in login_logging with auth_provider=lti.
• Multi-worker ready: OIDC state/nonce/launch data live in Flask-Caching; CACHE_TYPE=RedisCache + CACHE_REDIS_URL are now configurable and required with gunicorn -w N (a startup warning fires on SimpleCache). COOKIES_SECURE=True enables the Secure; SameSite=None cookies needed inside LMS iframes.

Reviewer notes

• pylti1p3 raises plain Exception (not LtiException) for an unknown issuer — the most common misconfiguration — so /login/ and /launch/ catch broadly and return logged 4xx instead of 500s.
• With enable_check_cookies() every launch hits /login/ twice (cookie-check page, then a re-post with lti1p3_new_window=1) — expected, covered by tests.
• Migration 2.0.11 (upgrade + downgrade verified on a fresh SQLite DB).
• Deep linking, AGS grade passback, NRPS roster and account merging are explicitly out of scope (see doc/lti/IMPLEMENTATION_PLAN.md).
• Docs: doc/lti/DASHBOARD.md (setup guide), plus the reference playbook/README used to design this.

Testing

• tests/test_lti.py: 23 tests — key generation/rotation/purge and JWKS merging, DB tool conf, registration gating (disabled/invalid/expired token, static creds, mismatched openid_configuration URL), happy path against a faked platform, token consumption/reuse, launch provisioning + role mapping (incl. admin-never-demoted), OIDC login logging and both login passes.
• Full suite: 465 passed (442 pre-existing + 23 new).
• Not yet done (needs infra): gunicorn -w 2 + Redis smoke test and an end-to-end launch against a real Moodle.

🤖 Generated with Claude Code