toga-ai 1.0.528 → 1.0.529

package/knowledge/1.0/apps/togaview/architecture.md

@@ -108,9 +108,15 @@ divergent shapes (read `emailAddress` with `email` fallback).
 
 **SAML** (rumcsi, towfoundation, newcenturyholdingsllc) is handled in `framework.php`
 (`meta`/`acs`/`sls`); newcenturyholdingsllc and towfoundation **auto-create `people` rows** for
-unknown SAML users. rumcsi additionally accepts a legacy `?hash=<base64 email>` auto-login — **an unauthenticated
-account-takeover path that appears to be the client's actual production login**; do not remove it
-before completing the `acs` handler (see [login flows](features/login-flows.md)).
+unknown SAML users. rumcsi additionally accepts a `?hash=<base64 email>` auto-login — **an unauthenticated
+account-takeover path that is also, per the routing evidence, RUMC's live production SSO login**:
+the block holds the only rumcsi route to `/enterprise_dashboard` (where a real production SSO
+login lands), and togaview has no `?saml=` handling, so the 2.0 SAML gateway is not involved.
+Only rumcsi's `acs` handler fails to populate the session (newcenturyholdingsllc `:819` and
+towfoundation `:1180` do), which is why only rumcsi has a magic link. **Deleting it breaks RUMC
+login into an IdP redirect loop** — sign the token or complete the `acs` handler instead, in
+coordination with the external link generator. A cold-login capture to confirm the inbound
+`?hash=` hop is still outstanding (see [login flows](features/login-flows.md)).
 
 ## Dashboards
 Five dashboards, one per audience/business model, each delegating to a client override or the

package/knowledge/1.0/apps/togaview/features/login-flows.md

@@ -72,26 +72,65 @@ lookup silently found nothing. Removed, and `email LIKE '…'` changed to `=` in
 
 ## Gotchas / known issues
 
-### OPEN SECURITY ITEM — rumcsi `?hash=` unauthenticated account takeover (deliberately left in place)
+### OPEN SECURITY ITEM — rumcsi `?hash=` is the LIVE production SSO login (do not delete it)
 `_/app/framework.php` authenticates a rumcsi user on nothing but
 `base64_decode(urldecode($_GET['hash']))` matching an active `people` row for the rumcsi
 clientid — **no password, signature, nonce, or expiry** — then populates ~18 session keys and
 redirects to `/enterprise_dashboard`. Anyone who can guess a RUMC user's email can log in as
 them.
 
-It was removed during TRUE-80671 and then **deliberately reverted**, because it may BE the
-production login mechanism: the rumcsi SAML `acs` handler does `App_MVC::routeTo('/')` on success
-and **never populates `$_SESSION`** (unchanged since commit 9e7d306, "phase one … make sure
-redirect works"); repo-wide only two places ever build a rumcsi session — this hash block and
-`mvc/login/post.php:462`, and the latter is unreachable because the SAML gate redirects to the
-IdP before a password POST can be processed; and RUMC login is confirmed **working in
-production**. Nothing in togaview/togadesk/library generates such a link, so links are presumably
-generated outside our codebase.
-
-- **Next step:** obtain the post-SSO redirect URL from Jonathan to confirm whether it carries
-  `hash=`.
-- **Proper fix:** complete the rumcsi `acs` handler (mirror newcenturyholdingsllc:
-  `$auth->getNameId()` → `people` lookup → session build) — **not** restoring the bypass.
+It was removed during TRUE-80671 and then **deliberately reverted**. Routing evidence gathered
+afterwards shows this is not a dormant legacy backdoor — it is **how RUMC actually logs in**:
+
+- Jonathan performed a real production SSO login and was returned to
+  `https://rumcsi.togaview.agilantsolutions.com/enterprise_dashboard`.
+- Inside the rumcsi block, **`framework.php:278` is the ONLY path to `/enterprise_dashboard`** —
+  and it sits **inside the hash block**, behind `if ($rumcsiUser)`. The SAML `acs` handler instead
+  does `App_MVC::routeTo('/')`. The only other RUMC route to that page is
+  `mvc/login/post.php:511`, which is the *password* login. **Landing on `/enterprise_dashboard`
+  after an SSO login is the hash block's signature.**
+- The absence of `?hash=` in the final URL is **expected, not exculpatory**: the block consumes
+  the parameter and issues a fresh redirect, so the query string is gone from the address bar.
+- **The modern alternative is ruled out.** The 2.0 SAML gateway (repo `saml`,
+  `Controller/Index.php:456-460`) hands off with `?saml=<base64 JSON whose client and user UUIDs
+  are encrypted via `_String::encryptWithKey`>` — the correct mechanism, which `tools` uses.
+  togaview has **zero** handling for `?saml=` (no `$_GET['saml']` anywhere). RUMC does not come
+  through that gateway, and there is no hidden session-population path.
+- **Had the deletion shipped, RUMC SSO would have broken outright:** authenticate at the IdP →
+  `acs` → `/` → no `contactId` → bounced back to the IdP. A redirect loop, not a login. The
+  revert was correct.
+
+**Still open — who generates the link.** Nothing in togaview/togadesk/library builds a `hash=`
+URL, so the generator is external (likely RUMC's IdP-initiated flow or their own portal).
+**Confirming test:** a **cold** SSO login in a private window with DevTools → Network →
+*Preserve log*, capturing the full redirect chain and checking whether the hop **into** togaview
+carries `?hash=`. Jonathan's test may not have exercised a cold login at all — with a live session
+cookie the `!array_key_exists('contactId', $_SESSION)` gate is skipped entirely and
+`/enterprise_dashboard` is simply where he already was.
+
+**Fix shape — a coordinated change, never a deletion.** Two options, both requiring coordination
+with whoever generates the link:
+- **(a) Keep the handoff but sign it.** Replace the unsigned base64 email with an HMAC-signed
+  token via `App_String::encrypt`/`decrypt` (`library/app/string.php`). Smallest change; kills
+  guessability.
+- **(b) Complete the rumcsi `acs` handler** so it builds the session itself, then retire the
+  handoff.
+
+⚠ **Do NOT delete the block first, under either option.**
+
+### Why rumcsi is the only one of the three SAML clients with a magic-link login
+The real lesson is the contrast between the three `acs` handlers in `_/app/framework.php`:
+
+| Client | `acs` handler | Sets `contactId` / session? |
+|---|---|---|
+| newcenturyholdingsllc | `:819` | **Yes** — completes the login |
+| towfoundation | `:1180` | **Yes** — completes the login |
+| rumcsi | `:399-417` | **No** — only `routeTo('/')` (since 9e7d306, "phase one … make sure redirect works") |
+
+rumcsi's handler was never finished, and the `?hash=` block is what filled the gap. When adding a
+SAML client, the `acs` handler **must** populate the session — an unfinished one invites exactly
+this kind of unsigned side door.
+
 - Note the surviving SAML branch is gated on `!inTestMode()`, so **test mode leaves rumcsi with
   no login path at all**.
 
@@ -106,6 +145,14 @@ generated outside our codebase.
 - The flows are order-dependent: a contact matching an earlier flow never reaches later ones.
 
 ## Change history
+- 2026-08-05 (later, TRUE-80671) — **Upgraded the rumcsi `?hash=` finding from "may be" to
+  evidenced:** `framework.php:278` inside the hash block is the only rumcsi route to
+  `/enterprise_dashboard`, where a real production SSO login landed; togaview has no `?saml=`
+  handling at all, so the 2.0 SAML gateway is ruled out; deleting the block would have produced an
+  IdP redirect loop, not a login. Recorded the three-way `acs` handler contrast (newcentury :819 /
+  towfoundation :1180 populate the session, rumcsi :399-417 never did), both fix shapes (sign the
+  token with `App_String::encrypt`, or finish `acs`), and the outstanding cold-login DevTools test.
+  (mhammontree)
 - 2026-08-05 (TRUE-80671, uncommitted) — Fixed the unguarded `$user_name[1]` session-name build
   that **locked mononym / shared-mailbox users out entirely** (4 sites); removed
   `sqlProtect(sqlEscape())` and switched email lookups to `=`; recorded the rumcsi `?hash=`

package/knowledge/clients/rumcsi/profile.md

@@ -35,13 +35,19 @@ Richmond University Medical Center (**RUMCSI**) is a framework **1.0** client se
 - **TOGa View SAML.** `togaview/_/app/framework.php` has a RUMCSI-specific host branch that selects
   branding (`$_SESSION['stylePath']`) and the SAML login path — an unregistered togaview hostname
   falls through to default branding and skips SAML.
-- **⚠ Portal login is (probably) an unauthenticated `?hash=` link.** The rumcsi SAML `acs`
-  handler never populates `$_SESSION`, and the only working rumcsi session builder is a
-  `_/app/framework.php` block that authenticates on nothing but a base64-encoded email in
-  `?hash=`. RUMC login works in production, so that path may be load-bearing; it was
-  deliberately left in place pending confirmation of the real post-SSO redirect URL. Full
-  analysis and the proper fix: [TOGa View login
-  flows](../../1.0/apps/togaview/features/login-flows.md#open-security-item--rumcsi-hash-unauthenticated-account-takeover-deliberately-left-in-place).
+- **⚠ Portal login IS an unauthenticated `?hash=` magic link — and it is load-bearing.** The
+  rumcsi SAML `acs` handler never populates `$_SESSION`; the only working rumcsi session builder
+  is a `_/app/framework.php` block that authenticates on nothing but a base64-encoded email in
+  `?hash=` (no signature, nonce, or expiry). The routing evidence is firm: `framework.php:278`,
+  inside that block, is the **only** rumcsi route to `/enterprise_dashboard`, which is exactly
+  where a real production SSO login landed
+  (`rumcsi.togaview.agilantsolutions.com/enterprise_dashboard`), and togaview has **no** `?saml=`
+  handling, so the 2.0 SAML gateway is not involved. **Deleting the block breaks RUMC SSO into an
+  IdP redirect loop** — it must be signed or replaced by a completed `acs` handler, in
+  coordination with whoever generates the link (the generator is external to our repos and still
+  unidentified). Full analysis, both fix shapes, and the outstanding cold-login confirmation test:
+  [TOGa View login
+  flows](../../1.0/apps/togaview/features/login-flows.md#open-security-item--rumcsi-hash-is-the-live-production-sso-login-do-not-delete-it).
   Note also that the SAML branch is gated on `!inTestMode()`, so **test mode leaves rumcsi with
   no login path**.
 - **Hardcoded client-ID branching.** RUMCSI appears in TOGa Desk's hardcoded client-ID branching
@@ -49,6 +55,9 @@ Richmond University Medical Center (**RUMCSI**) is a framework **1.0** client se
 
 ## Change history
 
+- 2026-08-05 (later) — routing evidence confirms the `?hash=` path is the live SSO login (only
+  route to `/enterprise_dashboard`; no `?saml=` handling in togaview); deleting it would break
+  RUMC login into a redirect loop. (mhammontree)
 - 2026-08-05 — recorded the `?hash=` portal-login path as an open takeover risk left in place
   pending SSO confirmation, and the test-mode no-login-path gap (TRUE-80671). (mhammontree)
 - 2026-08-04 — Client profile created during the TRUE-80139 read-only review of the RUMCSI branded

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "toga-ai",
-  "version": "1.0.528",
+  "version": "1.0.529",
   "description": "TOGA Technology Team Claude Knowledge System — shared AI coding harness with skills, knowledge base CLI, and project installer for Claude Code.",
   "keywords": [
     "claude",