LDAP 認證流程

CallIT 透過 django-auth-ldap 接 Windows AD 做無縫登入，認證成功後發 HttpOnly Cookie（JWT 或 Session Token）防 XSS 提取。

流程

sequenceDiagram
    participant U as 前端 (React)
    participant API as 後端 api/
    participant LDAP as AD / LDAP
    participant SVC as service/

    U->>API: POST /login {帳號, 密碼}
    API->>LDAP: bind(帳號, 密碼)
    LDAP-->>API: 認證成功 + AD Group 資訊
    API->>SVC: determineRole(user, AD Groups)
    SVC-->>API: User / 行政 / 主官管 / IT
    API-->>U: Set-Cookie: token=...; HttpOnly; Secure
    U->>API: 後續請求自動帶 cookie

關鍵設計

設計	為什麼
python-ldap 直連通訊協定	避開 COM 元件層級異常（舊系統痛點）
HttpOnly Cookie	JS 拿不到 token → 阻 XSS
Secure flag	強制 HTTPS 傳輸
角色判定在 service/ 層	集中授權邏輯，api 不直接寫角色判斷

角色映射

依 AD Group 或資料庫白名單判定 4 種角色：

角色	來源
User	AD 一般員工 group
行政	DB 白名單 + AD group
主官管	AD 主管 group
IT	AD IT group + DB 白名單

後續權限驗證

每個 API 請求都會：

1. 解析 cookie 拿 token
2. 驗 token 有效性
3. 在 service 層 / api 層重新檢查 request.user 是否具備對應角色（防越權）

刪除/編輯 API 尤其要做這層檢查 — 不能只信前端 UI 把按鈕藏起來。

跟舊系統的差別

	舊（ASP.NET Web Forms）	新（Django + LDAP）
AD 連線方式	透過 COM 元件	python-ldap 直連
Token 存放	LocalStorage / Session（暴露給 JS）	HttpOnly Cookie
角色判定位置	散落各 page	集中在 service/determineRole
穩定性	COM 異常會整個炸	通訊協定層級失敗有錯誤訊息可控

相關概念

強連結（原文明確提及）

• CallIT 系統 — 系統總覽
• 五層式架構 — 角色判定在 service 層

推斷連結（待確認）

• OAuth 流程 ?? — 同為認證流程，但 OAuth 是 Claude/MCP 用、CallIT 用 LDAP，僅做對照不混用

深入閱讀

• CallIT 資訊需求單系統重生計畫 - 方案設計書 §三.1 + §四

← 回到 wiki