ASP.NET七大身份驗證方式及解決方案
在B/S系統開發中,經常需要使用“身份驗證”。因為web應用程式非常特殊,和傳統的C/S程式不同,預設情況下(不採用任何身份驗證方式和許可權控制手段),當你的程式在網際網路/區域網上公開後,任何人都能夠訪問你的web應用程式的資源,這樣很難保障應用程式安全性。通俗點來說:對於大多數的內部系統、業務支撐平臺等而言,使用者必須登入,否則無法訪問和操作任何頁面。而對於網際網路(網站)而言,又有些差異,因為通常網站的大部分頁面和資訊都是對外公開的,只有涉及到註冊使用者個人資訊的操作,或者網站的後臺管理等才需要提示登入。(如果不做嚴格驗證,後果將很嚴重,人家一旦猜出你web目錄下面的頁面名,可以隨意訪問。當然,一般的開發人員是不會犯這種低智商的錯誤的)。
如何實現“身份驗證”
記得N年前我最早接觸Servlet + JSP開發的時候,有一種叫做“過濾器”(Filter)的東西,真是很神奇。有了這件神奇的東西后,我再也不需要去每個頁面判斷什麼“session”或者“cookie”了,就能把未登入使用者給彈出去(水平實現有限)。當然,在傳統webform開發中,也可以寫一個“BasePage的雞肋”,在該類中去做判斷,讓每個頁面對應的類都去實現這個”雞肋”,我看以前很多公司都是這麼幹的。
在asp.net中,其實微軟提供了一整套的完整的機制來實現“成員角色管理”。包含有:”登入控制元件”、“membership”、“個性化資料庫”等等。但是大多數開發人員是從來不用這些的(例如我,用微軟的asp.net三四年,還從來沒見過“登入控制元件”長啥樣)。在asp.net身份驗證中,主要有三四種。因為有些身份驗證的方式是依賴於IIS和windows作業系統的,所以在不同版本的作業系統和IIS上還是有些差異的。由於筆者暫時使用的是windows 7的作業系統,所以就拿IIS 7.5為例子。
首先開啟IIS,然後雙擊右側“身份驗證”,會顯示出當前IIS支援的所有的身份驗證方式(由於我安裝IIS時候,在“安全性”那裡我是全部勾選的)。可以看到如圖:
大致分為如下幾種:
1.活動目錄的客戶端證書(這個很可能是收費的),不常用,不細說。
2.ASP.NET模擬(MSDN:如果要在 ASP.NET 應用程式的非預設安全上下文中執行 ASP.NET 應用程式,請使用 ASP.NET 模擬。),機器人說的我聽不懂。
3.Form身份驗證:這個用的很多,後面會細說。
4.windows身份驗證:基於windows作業系統的使用者或者域使用者的身份驗證。
5.基本身份驗證:其實也是基於windows作業系統的賬戶驗證的。
6.匿名身份驗證:誰都可以訪問,其內部也是通過指定一個特定的windows系統的user賬戶來訪問的。
7.摘要身份驗證:使用 Windows 域控制器對請求訪問 Web 伺服器內容的使用者進行身份驗證。
再來看看經典的 IIS 6的截圖:
先在IIS 7上測試一下基本身份驗證:
首先把其他的身份驗證方式全部禁用掉,然後僅僅啟用“基本身份驗證”。有圖有真相:
然後開啟IE、FireFox、chrome等瀏覽器,敲入localhost,等待開啟IIS上的預設網站。你會發現,瀏覽器端都會彈出提示框資訊,而且在不同瀏覽器上彈出框的樣式和表現形式也有所差異。(長期不用IE,發現360這個老流氓把哥的首頁給改了,還號稱”安全上網“,這明顯是篡改行為嘛。搞不懂。)
FireFox中:
如果你在彈出框中,輸入正確的windows賬戶和密碼,則可以正常的瀏覽你請求的網頁。如果你不輸或者輸錯了,等待你的將是401錯誤(401,你懂得)。
“沒有為網站啟用SSL,將通過電纜以明文的方式…..”,機器人說的話聽起來很彆扭,這裡,我解釋一下。
當你沒有花錢去買SSL證書(安全套接層,你可以簡單的理解為:正常http請求都是明文傳送,使用SSL後可以幫你把http報文自動加密,就算有人在網際網路上截獲了也無法解密。我們偶爾訪問有些網站的時候,看到的“https://www.xxx.com”,就極可能是基於SSL證書的形式)。至於“通過電纜以明文的方式…”,其實這句話說的很不對,首先,電纜只是一種傳輸介質,裡面傳送的只是電脈衝、光訊號等等,而不是網路協議報文(學過計算機網路的都知道)。至於說“採用明文的形式”,也不對,其實“基本身份驗證”中,是將使用者名稱和密碼採用了Base64編碼的,感興趣的讀者,可以用httpwatch或者Fiddler之類的工具去監視一下http請求,我這裡就不做演示了 。只是由於Base 64編碼很容易反編碼,所以和明文沒啥區別。這樣一來,你會發現“基本身份驗證”方式,確實存在很多不安全因素。
在IIS 7上測試一下 windows 身份驗證:
和之前的基本身份驗證差不多,我就不再截圖演示了。如果使用者輸入正確的windows使用者名稱和密碼,則能夠正常訪問網站。如果輸入錯誤的,則返回的401.1(前面基本身份驗證是401.2)。值得一提的就是,記得之前有位asp.net MVP 曾告訴過我,使用windows身份驗證的時候,只能使用者在使用IE瀏覽器時候才能夠正常訪問。因為這種情況下,不是使用http報文傳輸的形式,而是瀏覽器端直接與作業系統內部互動,進行使用者名稱和密碼的驗證。經過證實,發現這話的後半句是對的,確實監視不到http實體內容。但不僅僅侷限於IE瀏覽器,我在firefox中也能夠正常的訪問和使用。
匿名身份驗證:
所謂匿名身份驗證,其實就可以理解為“不驗證”。就是匿名使用者都可以訪問資源,沒有任何限制。通常我們的網站,都要啟用匿名方式驗證,整合windows身份驗證。不難發現,其實匿名身份驗證,也是通過windows使用者組裡面的一個特定的使用者來通過驗證的,如圖所示:
最後一種,Form身份驗證:
前面所講的那些身份驗證方式,其實都和asp.net沒有直接的聯絡,都是IIS 和作業系統級別的驗證方式。而Form 身份驗證,則需要asp.net提供支援。因為通常網站的身份驗證和成員管理都非常複雜,而不是通過單純的某一種驗證方式能夠實現的。對於大部分網際網路的網站而言,使用者可以訪問部分頁面,但部分頁面必須登入後才能訪問和操作,而且不同使用者角色登入,操作許可權也不一樣。這又會涉及到很多方面的知識,而且實現方式也有很多種。
相關文章
- vagrant啟動身份驗證失敗的解決方式
- Asp.Net WEBAPI 增加身份驗證 (OAUTH 2.0方式)ASP.NETWebAPIOAuth
- Asp.Net MVC 身份驗證-FormsASP.NETMVCORM
- ASP.Net WebService 身份驗證 FormsASP.NETWebORM
- Shiro身份驗證丟擲AuthenticationException異常,解決方案Exception
- asp.net 角色身份驗證的使用ASP.NET
- 資料庫的身份驗證方式資料庫
- WebApi身份認證解決方案(1):Basic基礎認證WebAPI
- 也談Asp.net 中的身份驗證ASP.NET
- .NET混合開發解決方案14 WebView2的基本身份驗證WebView
- asp.net core 3.1多種身份驗證方案,cookie和jwt混合認證授權ASP.NETCookieJWT
- javascript 驗證身份證JavaScript
- 防火牆(360天堤)雙因素身份認證解決方案防火牆
- 作業系統(AIX)雙因素身份認證解決方案作業系統AI
- SSL證書七大常見錯誤及解決方法
- 身份證號碼校驗位的計算方式
- WEB身份驗證Web
- 身份證號碼的正規表示式及驗證詳解(JavaScript,Regex)JavaScript
- 身份證驗證工具類
- 【asp.net core 系列】13 Identity 身份驗證入門ASP.NETIDE
- ora-12638 身份證明檢索失敗 解決方式
- Kerberos身份認證方案ROS
- Oracle驗證方式詳解Oracle
- Oracle的身份驗證Oracle
- Volatile不保證原子性及解決方案
- PHP 驗證身份證號碼PHP
- 中國身份證號驗證庫
- C++身份證號驗證C++
- C#驗證身份證號C#
- 解決Python中使用requests庫遇到的身份驗證錯誤Python
- elment UI 表格 item 驗證問題解決方案UI
- 靜態密碼已經”OUT”探索身份驗證新方式密碼
- ASP.NET身份證識別判定ASP.NET
- C++身份核驗介面程式碼、身份證OCR、身份證實名認證APIC++API
- 作業系統身份驗證和口令檔案身份驗證總結作業系統
- js正則驗證身份證號JS
- PHP 身份證精確匹配驗證PHP
- 身份證號碼驗證系統