服務器端應用程序層的雲認證模式

Question

什麼是一些服務器端的應用層安全模式用於驗證基於角色的會議，特別是在多個虛擬專用網絡和公共網絡？尋找能夠最大限度降低開發人員代碼複雜性並減少IT維護的解決方案

問題：需要的是讓那些在不同的虛擬私有云，託管服務器端應用程序在一個廠商中立的（非AWS /天青）機制委派一個驗證會話。

場景：具有通過身份驗證的會話的應用程序（採用JWT格式）需要跨另一個網絡調用服務器，委派JWT會話但保持其活動狀態而不會使其自己的會話失效。

可能的模式和他們的陷阱：

1. 的OAuth：規格有很多流量，其中沒有一個是具體實現，這樣做是正確的是你。需要一箇中央身份提供者服務。使用到期令牌會讓會話狀態管理變得困難。失敗點是客戶端ID和祕密的泄漏。
2. TLS相互客戶端證書：需要證書生命週期管理（IT部門的痛苦）以及驗證證書的其他代碼（痛苦的開發）。對於公共服務器，您需要一個公共證書頒發機構和DNS，這會增加成本和複雜性，正如爲dns所要求的證書所假定的那樣。故障點泄露私鑰和欺詐證書。

相關問題：OAuth 2.0 Many to Many Delegated Client Credential Flow Scenario

Answer 1

以確保跨供應商無關的數據中心應用中常見的方法是使用一個撮合的認證模式。代理認證的組件可能包括以下組合：

1. 安全令牌服務（STS）驗證憑證並生成令牌。
2. 用戶/密碼或應用密鑰/ ID和密碼。
3. KPI（X.509客戶端證書）。證書比純文本祕密和密碼安全得多。驗證證書可以通過證書頒發機構完成，但它們會引入自己的問題。如果客戶端具有預先存在的信任關係，則證書鎖定可能是CA的解決方案（https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning）。

看到，Web服務安全性：http://download.microsoft.com/download/8/d/6/8d608524-0763-48b5-840b-0ae446996a14/MS_WSS_Dec_05.pdf

公鑰基礎設施：https://sites.google.com/a/ssl4net.com/www/technology/public-key-infrastructure