alexrg/SGU-CredentialProvider
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases 25 Wiki Activity

Decouple SGU authentication from profile pages

Browse Source
This commit is contained in:
alexrg
2026-09-01 14:43:57 -06:00
parent fd3eb537a1
commit 0391320a3e
8 changed files with 221 additions and 96 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/architecture.md
+12 -8
View File
@@ -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