2013-04-06 63 views
3

我有它使用許多不同的技術,如Java的,.NET等因此,我的用戶憑據存儲在一個單獨的數據庫客戶應用的Web API Web服務如何爲我的Web API Web服務實現身份驗證和授權?

我的Web服務託管內IIS我已經配置並啓用服務器端SSL這可以確保請求/響應消息進行加密和簽名。

我還配置了IIS的IP地址限制功能,以允許來自少數幾個已知IP地址的請求。

我不喜歡使用基本身份驗證因爲它以純文本格式發送憑證,但每封郵件都使用SSL加密。

我不能使用集成Windows身份驗證顯然是因爲我的用戶與我的服務器不在同一個域中。

我不能使用表單身份驗證因爲我的客戶端不是基於瀏覽器的。

那麼爲我的web服務實現身份驗證和授權的最佳方式是什麼?

我在想一個辦法是提供一個進行身份驗證(用戶名,密碼)Web方法其行爲類似於身份提供商/安全性令牌服務,併產生特定於該用戶的令牌,該令牌後,某些到期時間。然後,客戶端必須發送帶有每個Web方法請求的身份驗證令牌,並通過爲我的控制器創建自定義授權過濾器來確保它。

這種方法的優點是用戶不必爲每個請求發送用戶名/密碼,而只需要一個臨時令牌。顯然,管理令牌生活的缺點是;它應該何時到期?例如如果一小時內沒有提出請求。

什麼是爲我的web服務實現身份驗證和授權的最佳方式?

+0

如果會話使用SSL進行保護,那麼數據並不是以明文形式發送的,對嗎? :-) – Craig 2013-06-24 15:20:37

回答

0

在Facebook中,它們嚮應用程序提供訪問令牌,只有在密碼發生更改或用戶特別取消授權應用程序時纔會更改。你很多人考慮這種方法。這在Google的Map API中也是如此。我能想到的唯一安全方法是檢查請求來自哪裏(請求的IP地址),然後檢查apikey然後迴應。

+0

謝謝Tariq。是的訪問令牌非常相似。 – 2013-04-06 18:30:13

+0

更改用戶密碼更改令牌聽起來很不錯。不過,依靠遠程IP地址不應該被認爲是非常安全的。 – jszobody 2013-04-06 18:30:57

1

IP地址可能很容易被欺騙,所以不要依靠它們來保護您的服務。

我建議您只允許通過HTTPS進行訪問,併爲了進一步加強安全性,請驗證請求已簽署的證書。更好的是,擁有自己的證書服務器併爲此發佈自己的證書。

4

我將在我的評論中討論有關SOAP服務的認證選項。授權在服務器應用程序中實現,並且與所選的認證類型無關。 有三(3)的Web服務分類: -Private - 社區 - 公共

這聽起來像您所提供的網絡服務是社區服務,因爲它僅適用於可信賴的合作伙伴。我知道這是因爲你解釋過在IIS中配置了IP地址限制。包括IP地址限制是實施安全Web服務的很多好方法之一。安全不是一回事。它是許多防禦的積累。 IP地址限制是一個好的開始。

Web服務本質上是無狀態的。因此,在調用Web服務時,通常必須在每個請求中包含憑證(用戶名和密碼)。所以,這不是問題或擔心。

HTTP基本認證不是一個不錯的選擇。它受到所有客戶端和服務器應用程序的支持,並且易於實施。我喜歡將HTTP基本認證作爲最低公分母。我不排除它。 HTTP基本身份驗證在純文本中包含http標頭中的憑證,因此始終建議使用SSL(HTTPS)來加密傳輸通道。

WS-Security是一個非常常見的Web服務授權標準。它是Web服務的行業標準,規範由結構化信息標準促進組織(OASIS)組織發佈。 WS-Security包含一個用於包含用戶名/密碼的UsernameToken配置文件。 WS-Security塊被添加到SOAP消息的頭部。相比之下,HTTP基本認證被添加到HTTP標頭。 HTTP基本認證附加到傳輸協議。相比之下,WS-Security附加到SOAP消息。 WS-Security UsernameToken採用純文本格式,因此始終建議使用SSL(HTTPS)。

另一個選項是客戶端證書認證。此選項使用數字證書作爲身份驗證令牌來代替用戶名/密碼。此方法運行良好,但要求Web服務團隊成員和客戶端應用程序團隊成員都必須熟悉SSL數字證書作爲先決條件。這種方法的學習曲線比其他方法高。

您所描述的定製的解決方案是沒有必要的,因爲有很多的行業標準存在的實現和解決你所尋求的解決方案。例如,如果在Web服務中實現WS-Security,則不必爲客戶端應用程序團隊提供文檔,並解釋如何在客戶端應用程序中實現它。 WS-Security是一個行業標準,已被大多數現代SOAP服務器和SOAP客戶端記錄和支持。這同樣適用於HTTP基本認證。

我希望這會有所幫助。乾杯,DCova

+0

+1優秀的答案 – 2013-04-07 20:24:40

0

我的Web服務託管在IIS中,我已在服務器端配置並啓用SSL,以確保請求/響應消息已加密並簽名。

SSL是傳輸安全,而不是郵件的安全性。它不會爲你簽名。它加密了頻道。

我覺得預共享密鑰或API密鑰將工作最適合你的情況的方法。由於用戶有用戶名和密碼,我假設他們在某處註冊。作爲該過程的一部分,生成一個密鑰,該密鑰可以是共享對稱密鑰,即雙方(客戶端和服務器)具有相同的密鑰。客戶端在某些自定義方案的Authentication標頭中發送用戶標識,並在請求消息的特定部分中發送SHA256散列標識。服務器獲取用戶ID,檢索密鑰,計算消息的相同部分的哈希值,如果哈希匹配,則客戶端處於。

查看我的書Pro ASP.NET Web API Security