Decouple SGU authentication from profile pages

docs/architecture.md

@@ -7,8 +7,8 @@ LogonUI
   -> SGU Credential Provider (SecureString)
       -> HTTPS 1.1 + client certificate
           -> SGU Auth Broker
-              -> SGU IIS NTLM endpoint (original password)
-              -> minimum SGU profile metadata (same authenticated response)
+              -> SGU IIS lightweight NTLM root (original password)
+              -> minimum SGU profile metadata (bounded, best effort)
               -> Active Directory (same original password + optional profile)
           <- domain + canonical username; never a password
       -> Windows credential serialization (original SecureString)
@@ -20,12 +20,16 @@ It follows only HTTPS redirects whose host appears in `AllowedRedirectHosts`,
 which prevents credential forwarding to an unexpected redirect target. HTTP/1.1
 is forced because NTLM authentication is connection-bound.
 
-The logical GET is sent directly to the administrative incident overview for
-`AD` identities, the student information page for `AL` identities, or the
-portal menu for `DO` identities. NTLM may still require its normal
-challenge/response round trips on that connection. The broker keeps any
-transient portal cookie in an in-memory per-request container; it is never
-persisted or returned to the client.
+The authoritative logical GET is sent to `/psulsa/`, a lightweight route that
+returns the NTLM challenge without waiting for the slow application pages. A
+`401` or `403` rejects the credential; an allowed `2xx` or `3xx` proves that IIS
+accepted it. The broker then makes a separately bounded, best-effort GET to the
+administrative incident overview for `AD`, the student information page for
+`AL`, or the portal menu for `DO`. A profile timeout does not invalidate an
+already authenticated credential. NTLM may still require its normal
+challenge/response round trips on the connection. Transient portal cookies are
+kept only in an in-memory per-request container and are never persisted or
+returned to the client.
 
 ## Offline authentication
 

docs/broker-operations.md

@@ -47,10 +47,12 @@ Eso es comportamiento esperado, no una caída del servicio.
 ## Timeouts y recuperación
 
 - El Credential Provider espera hasta **35 segundos** por el broker.
-- El broker espera hasta **30 segundos** por SGU. Este margen cubre las
-  degradaciones observadas del portal sin bloquear LogonUI indefinidamente; el
-  cliente conserva cinco segundos adicionales para que el broker cierre la
-  respuesta de manera limpia.
+- El broker permite hasta **20 segundos** para el desafío NTLM ligero de
+  `/psulsa/` y hasta **10 segundos totales** adicionales para enriquecer el
+  perfil. La consulta de perfil es best effort: si la página pesada queda
+  congelada después de que NTLM aceptó la contraseña, el usuario se sincroniza
+  sin metadatos y puede iniciar sesión. El máximo combinado queda por debajo de
+  los 35 segundos del cliente.
 - El instalador configura recuperación del servicio con reinicios a los 5, 15
   y 60 segundos y reinicia el contador de fallos después de 24 horas.
 - Si el broker o SGU no está disponible, el Credential Provider entrega la

docs/security.md

@@ -24,9 +24,9 @@
 - Client private keys are non-exportable and reside in `LocalMachine\My`.
 - The NTLM validator rejects non-HTTPS redirects, URI user information, and hosts
   outside its explicit redirect allow-list.
-- Profile enrichment reads only allow-listed HTTPS pages and caps the response
-  body at 512 KiB by default. Portal cookies are request-scoped and held only in
-  memory.
+- Authentication and profile enrichment read only allow-listed HTTPS pages.
+  Profile bodies are capped at 512 KiB by default; portal cookies are
+  request-scoped and held only in memory.
 
 ## Profile minimization
 
@@ -43,6 +43,9 @@
   before metadata is synchronized.
 - If SGU changes its HTML, authentication and exact-password synchronization
   continue without enrichment; existing AD metadata is not erased.
+- Slow profile pages cannot change an accepted credential into a rejection. The
+  lightweight NTLM root is authoritative; enrichment has its own shorter total
+  timeout.
 
 Lab self-signed certificates are appropriate only for the isolated VM network.
 Use an enterprise CA with revocation checking in production.