Dify 自架實戰 · 架構補充

企業落地:agent 平台的授權架構(AAD / SSO / 分級 RAG)

要把 agent 平台「給全公司幾千、幾萬人用」,馬上撞到授權——誰能問什麼、誰不能看什麼,而且公司通常要求接 Azure AD(Entra ID)。這頁把整套企業授權架構畫清楚:Dify 自己扛不了 AAD、門要加在前面;authN vs authZ;身分只能從 Entra 發;同一個 n8n 同時接「人登入」與「機器 M2M」;授權集中別在 Dify 養第二套;分級 RAG 要分知識庫;MCP 在外、API 在內。通用做法,不含任何機密。

🗺️ 整體:門在外、能力在後

flowchart LR
  EXT(("🤖 呼叫方
人 / 機器")):::c
  GW["🛡️ 對外那道 AAD 門
(gateway / n8n 入口)"]:::gw
  N8N["🔗 n8n
授權決策 + 路由"]:::n8n
  DIFY["🖥️ Dify + 各系統
能力提供(信任邊界後)"]:::d
  EXT ==>|"帶 AAD token"| GW
  GW ==>|"驗身分過"| N8N
  N8N ==>|"內部 token(免 AAD)"| DIFY
  classDef c fill:#dbeafe,stroke:#2563eb,color:#17335e
  classDef gw fill:#fef3c7,stroke:#d97706,color:#78350f
  classDef n8n fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
  classDef d fill:#e0f2fe,stroke:#0284c7,color:#075985

Dify 自己扛不了 AAD(端點只有靜態 token、還是最舊 MCP 協定沒 OAuth)→ AAD 這關一定在前面做,Dify 躲信任邊界後、只提供能力。

🪪 authN ≠ authZ;身分只能從 Entra 發

	是什麼	誰做
authN 認證	證明「你是誰」	Azure AD / Entra
authZ 授權	決定「你能碰什麼」	PEP(n8n)+ 集中政策

身分只能從 Entra 發,n8n 生不出來。n8n 只能「驗」你給的 token,不能「發」→ 呼叫方一定要先自己拿到 token。

🔀 同一個 n8n,兩種入口都接

flowchart LR
  U(("👤 人 / 員工")):::u
  M(("🤖 機器 / service")):::m
  ENTRA[("🔑 Entra")]:::aad
  N8N["🔗 同一個 n8n
兩種入口都接"]:::n8n
  U ==>|"/login → auth-code(員工身分)"| N8N
  M ==>|"M2M token(app 身分)"| N8N
  N8N -.->|"驗身分"| ENTRA
  N8N ==>|"人:per-person 分級路由"| D1["🖥️ 依 level 的 Dify app"]:::d
  N8N ==>|"機器:取被授權的固定那份"| D2["🖥️ 該 service 的 Dify app(固定)"]:::d
  classDef u fill:#dbeafe,stroke:#2563eb,color:#17335e
  classDef m fill:#e0e7ff,stroke:#4338ca,color:#312e81
  classDef aad fill:#ede9fe,stroke:#7c3aed,color:#4c1d95
  classDef n8n fill:#fef3c7,stroke:#d97706,color:#78350f
  classDef d fill:#e0f2fe,stroke:#0284c7,color:#075985

關鍵區別:機器沒有「人」的身分。人登入 → 某員工身分 → 做得到分級;機器 M2M → 只有「app 身分」→ 是「這個系統被授權讀哪一份資料」的固定範圍,不分級。別把 M2M 當成一個人去套職級。

📜 授權集中:別在 Dify 養第二套

flowchart LR
  AG(("🤖 呼叫方
帶 token(身分+roles)")):::c
  ENTRA[("🔑 Entra ID
身分 + App Roles/Groups")]:::aad
  PDP["📜 PDP 中央授權政策
Entra roles / OPA"]:::pdp
  PEP["🛡️ n8n(PEP)
驗身分 + 執行授權"]:::pep
  AG ==>|"token"| PEP
  PEP -.->|"authN 驗簽"| ENTRA
  PEP -.->|"authZ:能碰這份嗎?"| PDP
  PDP -.-> ENTRA
  PEP ==>|"✅ 放行 · 內部 token"| DIFY["🖥️ Dify / API
能力(信任邊界後,不做授權)"]:::dify
  classDef c fill:#dbeafe,stroke:#2563eb,color:#17335e
  classDef aad fill:#ede9fe,stroke:#7c3aed,color:#4c1d95
  classDef pdp fill:#fce7f3,stroke:#db2777,color:#831843
  classDef pep fill:#fde68a,stroke:#b45309,color:#78350f
  classDef dify fill:#e0f2fe,stroke:#0284c7,color:#075985

政策放 Entra(App Roles/Groups)或中央 PDP;n8n 當 PEP 執行;Dify 不做授權。權限只養一套,別在每個 app 重造 AD 已有的。

🗄️ 分級 RAG + MCP 在外、API 在內

原則	做法
分級 RAG	敏感(財務/薪資)跟公開手冊分知識庫(RAG 靠相似度撈、會漏);每庫一個受控端點,依職級放行
MCP 在外	只有給外部 AI client(Claude/Cursor)標準化工具時才用
API 在內	n8n → Dify 用 `/v1/chat-messages` REST,依職級挑對應 API key;Dify 免做 MCP

一句話心法:身分集中在 Entra、授權決策集中在一個 PEP/PDP、能力分散在 Dify 與各系統。門交給前面那層(人 / 機器同一個 n8n 都接)、權限只養一套、敏感分庫、MCP 只在最外層。

▶ 對應影片:企業授權架構 📖 完整版 + 可匯入 n8n sample(手冊 Part 四)

📚 回課綱總表 →