微服務體系結構中的單點登錄

Question

我正試圖設計一個將有多個服務（服務數據）和Web應用程序（服務HTML）的綠色領域項目。我讀過關於微服務的內容，看起來很合適。

我還有的問題是如何實現SSO。我希望用戶進行一次認證，並有權訪問所有不同的服務和應用程序。

我能想到的幾種方法：

1. 添加身份服務和應用。任何具有受保護資源的服務都將與Identity服務通信，以確保其擁有的憑證有效。如果他們不是，它會重定向用戶進行身份驗證。

2. 使用網絡標準，如OpenID，並讓每個服務處理它自己的身份。這意味着用戶將不得不單獨授權每個服務/應用程序，但在此之後它將成爲SSO。

我很樂意聽到其他想法。如果一個特定的PaaS（比如Heroku）擁有一個專有的解決方案，那也是可以接受的。

Answer 1

在我以前的工作中實現微服務架構時，我們決定採用最佳方法與＃1一致，添加身份服務並通過它授權服務訪問權限。在我們的例子中，這是用令牌完成的。如果請求帶有授權令牌，那麼我們可以使用身份服務驗證該令牌，如果它是用戶與服務的會話中的第一個呼叫。一旦令牌被驗證，它就被保存在會話中，以便用戶會話中的後續呼叫不必進行額外的呼叫。如果令牌需要在該會話中刷新，您還可以創建預定作業。

在這種情況下，我們使用OAuth 2.0端點進行身份驗證，並將令牌添加到HTTP標頭以調用我們的域。所有的服務都從該域中路由，所以我們可以從HTTP頭獲取令牌。由於我們都是同一應用程序生態系統的一部分，因此最初的OAuth 2.0授權將列出用戶將爲其帳戶授予的應用程序服務。

此方法的一個補充是身份服務將提供代理客戶端庫，它將被添加到HTTP請求過濾器鏈並處理授權過程到服務。該服務將被配置爲使用來自身份服務的代理客戶端庫。由於我們使用的是Dropwizard，該代理將成爲一個Dropwizard模塊，將過濾器引導到正在運行的服務進程中。這允許對身份服務進行更新，只要接口沒有顯着變化，也可以通過相關服務輕鬆使用免費的客戶端更新。

我們的部署架構遍佈AWS Virtual Private Cloud（VPC）和我們自己公司的數據中心。 OAuth 2.0身份驗證服務位於公司的數據中心，而我們的所有應用程序服務均已部署到AWS VPC。

我希望我們採取的方法有助於您的決定。如果您有任何其他問題，請告訴我。

Answer 2

Chris Sterling解釋了上面的標準認證實踐，這是絕對有道理的。我只是想出於一些實際的原因在這裏再想一想。

我們實施了認證服務和多個其他依賴auth服務器的微服務來授權資源。在某些時候，由於往返認證服務器的次數過多，我們遇到了性能問題，隨着微服務數量的增加，我們對auth服務器也存在可擴展性問題。我們稍微改變了架構以避免過多的往返行程。

Auth服務器將只與證書聯繫一次，它將基於私鑰生成令牌。對應的公鑰將被安裝在每個客戶端（微服務服務器）中，這將能夠驗證身份驗證密鑰與無聯繫身份驗證服務器。密鑰包含生成的時間以及安裝在微服務中的客戶端實用程序也會有效。儘管這不是標準的實現，但是我們對這個模型非常成功，特別是當所有的微服務都在內部託管時。