2014-01-09 130 views
1

我們有一箇中央RESTful webservices應用程序,它將數據公開給許多不同的客戶端(解析器,Web應用程序,觸摸應用程序等)。客戶端對用戶進行身份驗證的方式不同,有些LDAP,其他則不是。無論如何,RESTful應用程序會將最終用戶的身份驗證留給客戶端,並簡單地對發出請求的客戶端進行身份驗證。客戶端將在LDAP中具有用戶名和密碼,以及客戶端可以從中訪問RESTful應用程序的可接受IP地址列表。RESTful服務的兩種身份驗證

以下是棘手的部分:RESTful應用程序必須使用最終用戶的用戶名審覈每個請求。此外,在某些情況下(取決於客戶端),RESTful應用程序需要最終用戶的用戶名和密碼才能訪問第三方應用程序。因此,來自客戶端的每個請求都將擁有客戶端本身和訪問客戶端的最終用戶的身份驗證憑據。

問題出在這裏。最好是將客戶端的憑證放在基本身份驗證中,並通過加密的SALT請求參數傳遞最終用戶的憑據?或者,客戶端應該將兩組憑證放入基本身份驗證(即system〜username:systempwd〜userpwd)中,並將其解析爲兩組令牌,然後再對其進行身份驗證。或者,另一種解決方案比這兩種解決方案都好?

回答

1

這聽起來非常像OAuth2的「資源所有者密碼憑據授予」 - 請參閱http://tools.ietf.org/html/rfc6749#section-4.3。您將使用x-www-url-encoded編碼的身份驗證標頭中的應用程序/客戶端憑證和身份中的客戶端信息。之後在會話開始時進行一次,然後在授權標頭中依賴不記名令牌。所有這些都在RFC中描述。請記住使用SSL/TLS來加密憑證。

+0

感謝您的幫助信息。這裏有幾點注意事項。其中,我們需要對每個請求進行身份驗證,沒有狀態存儲在RESTful Web服務應用程序中。二,內容類型通常需要是包含JSON數據更新資源的POST/PUT有效載荷的「application/json」。所以,我不確定OAuth2解決方案非常適合用例。任何其他想法?再次感謝您的幫助。 – Jimmy

+1

那麼,如果你真的不會在中間web服務應用程序中存儲任何狀態,那麼,是的,你將不得不在每個請求上都傳遞客戶和用戶證書。在這種情況下,我會在Authorization標頭中粘貼客戶端憑證(模擬OAuth2),併爲每個請求中的用戶憑證保留一個JSON屬性。就像這樣:{user_credentials:{name:「John」,pwd:「abcde」},...其他有效負載...}。玩得開心:-) –

+0

嗯,這不是我們的選擇。 RESTful Web服務經常調用的第三方應用程序需要最終用戶的任何更新(創建,更新,刪除)的用戶名/密碼。因此,對於OAuth2,訪問令牌不會有用,因爲我們需要最終用戶的確切用戶名和密碼來通過第三方軟件的驗證。我昨天聽說第三方軟件可能正在計劃轉移到OAuth。希望能夠早日來臨,而不是晚點:)謝謝Jorn。 – Jimmy