iT邦幫忙

2022 iThome 鐵人賽

DAY 17
0
自我挑戰組

30天 IIS 面面觀系列 第 17

Day17. 我是誰 - Authentication

  • 分享至 

  • xImage
  •  

https://ithelp.ithome.com.tw/upload/images/20221002/201420570DjQIdpmUK.png
皮卡丘。

這篇要講的是 IIS 中的身分認證,關係到使用者訪問網站、網站與後面服務互動的時候的身分帶入。驗證的主要目的是讓你的 Application 決定怎麼去認識訪問者的方式。這是蠻重要的一個章節,如果要深入到實際應用的案例,可能會是非常複雜的情景,我這篇會就 IIS 上的幾種認證類型做一個介紹,比較他們之間的差異。在實作上你至少能夠考慮這幾種認證方式的優缺,並檢查 IIS 上的設定是否如你預期。

https://ithelp.ithome.com.tw/upload/images/20221002/20142057whFPevRC0E.png

認證模組在 IIS 區塊的劃線位置,點擊後能夠進入。

有些僅在 Home Level 最上層才會看到,如 Active Directory(後文皆簡稱AD) Client Certificate Authentication,其他大多是 Site 也能獨立設定。

https://ithelp.ithome.com.tw/upload/images/20221002/201420576nommhwuGR.png

介面也非常簡單,基本就長這樣,大多數的驗證類型你能選擇的就是在這個網站上你要不要允許開啟。驗證類型之間彼此有優先順序,若高優先和低優先同時開啟,會以高優先的身分去做驗證。

AD Client Certificate Authentication 主要和 Microsoft 的 Active Directory 服務相關,是一種身分驗證管理功能,可以透過該處拿到的認證直接辨別使用者。另外使用此種方式也需要 SSL 的綁定。

這邊一開始你可能只會看到 Anonymous Authentication 和 Windows Authentication ─ 為什麼呢?因為你安裝漏勾了,只有這兩個會是預設勾起的,回去勾選一下就有了。

https://ithelp.ithome.com.tw/upload/images/20221002/20142057FiwiGm1C68.png

我們簡單介紹一下其中幾個比較常見的,就官方文件加上我的認知大概帶過,細部實作可能要再另外去找完整文章。

Anonymous Authentication 是匿名驗證,基本有開的時候都會優先嘗試用匿名去做認證,除非驗證端有要求憑證。匿名驗證的使用情境是你期望所有使用者都能夠同等的看到內容,無須任何帳號密碼。儘管匿名驗證等同無須身分,但仍然至少要保持驗證開啟,否則全數 Disabled 的話仍會遭遇錯誤如下圖的 401.2。

https://ithelp.ithome.com.tw/upload/images/20221002/20142057f2XK8Tsr0j.png

匿名認證在對後面做事的時候實際登陸的身分你可以手動指定為特定的 Service Account,或是預設會是使用 IIS 專門給匿名驗證用的 IUSR,也可以設定為該 Site 依存的 Application pool 的 Application pool identity,就依你整體的驗證流程/權限控管設計而定。

https://ithelp.ithome.com.tw/upload/images/20221002/20142057tYVvTWi2hT.png

Basic Authentication 是使用者會輸入帳號密碼,藉由帳號密碼獲得對應憑證,但因加密方式容易解碼(Base 64),幾乎已經淘汰。Digest Authentication 中文為摘要驗證,算是作為 Basic Authentication 的繼任對象,有更安全的MD5加密方式。可以看到這兩種認證方式失敗都會有回傳 401,且Header 內會包含驗證資訊如 www-authenticate: digest,讓使用者再次輸入登入資訊重新進行驗證。因為是登入帳號密碼,會和 Domain 有關,在輸入帳號密碼的時候也要注意關於 Domain 的輸入。

Forms Authentication 表單驗證通常是服務端有對應表單,在表單畫面輸入使用者的驗證內容,IIS檢查並做驗證。驗證完畢就會在重新導向請求頁面,是個需要實作代碼的驗證方式。能設定的選項有如下圖,包含指定登入的頁面、相關 Cookie 的設置等等。

https://ithelp.ithome.com.tw/upload/images/20221002/201420574qqlO9JsX3.png

ASP.NET Impersonation 是一種身分模仿的驗證方式,會允許 ASP.NET 的應用程式使用 Windows 的憑證(使用者帳號)去作為使用者發出 request 的驗證,是一種也算是常用的驗證方式。有需要的話你也可以指定特定的帳號為模仿對象。

https://ithelp.ithome.com.tw/upload/images/20221002/20142057dutlfoUmkQ.png

Windows Authentication 稍微複雜一點,也是常用的設定之一。他可以接受以 AD 的認證或單純以 Windows 帳號的方式去認至,也因此他並不強求 Server 必須加入 AD Domain。在認證上,細部他提供了不同的協定,也就是 Provider 的方式來做選擇,分別的是 NTLM(NT Lan Manager,NT 是 New Technology 的縮寫,是 Windows 內核的名字,可以簡單理解為 NT 下網域管理協定) 和 Kerberos(Negotiate)。通常允許的情況下會盡量使用 Kerberos,會是更安全的方式。設置 Kerberos 會需要用到 SPN (Service Principle Name),可以當作是一種 service instance 的識別。關於 Kerberos 的情境其實比較複雜,如果要套用可以參考這篇文章 : Setting up Kerberos Authentication for a Website in IIS。NTLM 的文檔則可以參考這篇 NTLM Overview

https://ithelp.ithome.com.tw/upload/images/20221002/20142057DfNQB3ESOb.png

在 Windows Authentication 的 Advanced Settings, Extended Protection 是用於強化驗證中的安全性,更能夠防止中間人攻擊(Man in the middle)的情景,會需要 SPN 來達成,細節的話請見文件 Windows Extended Protection。 Kernel-Mode Authentication 是關於驗證在哪完成的設定,大家還記得我們前面講過 User Mode 和 Kernel Mode 嗎?不記得請去翻 Day7 的地方會有那個圖幫助大家回憶一下。如果能在 Kernel Mode 完成的好處是效能會更好,預設會是開啟的。

https://ithelp.ithome.com.tw/upload/images/20221002/20142057hFzW2HfzOR.png

關於驗證一些其他資訊可以在很多地方找到,想看概述的話如 HTTP基本認證 維基有就 HTTP 認證這一行為本身做更多說明。實際上實務中的驗證角色通常是有好多個,在你的整個流程中都可能不停變動,依據你的服務流而定,這邊大概簡介了幾種 IIS 裡提供的驗證方式,做為一個簡單的概述讓大家有個概念。


上一篇
Day16. 通信交換,但不會進化 - FTP
下一篇
Day18. You should not pass - Request Filtering
系列文
30天 IIS 面面觀30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言