向下遊服務/應用傳播SAML聲明響應/安全上下文

我們在我們的環境中提供多項服務。向下遊服務/應用傳播SAML聲明響應/安全上下文

有些情況下，我們希望用戶在首次成功登錄一個服務後，自動登錄/無提示地登錄一個或多個參與服務，而不會受到身份提供商提供的憑據質疑或與身份提供商通信。

例如，我們有一個前端UI應用程序，我們希望使用Spring Security SAML進行身份驗證。當UI App與後端服務通信時，我們希望安全上下文/斷言響應自動傳播到後續服務調用。

也許，被調用的服務/應用程序可以相應地驗證斷言響應，並允許訪問其服務/應用程序，而無需每個服務/應用程序在每次需要訪問時都直接與身份提供者進行通信。

有沒有一種方法可以將身份驗證服務器成功驗證後獲得的SAML Assertion響應從一個應用程序/服務傳播到正在從SAML驗證的應用程序/服務調用的其他下游應用程序/服務。

我試圖向身份提供商註冊2個應用程序，然後使用IdP成功驗證其中一個，但是無法從第一個應用程序成功訪問其他應用程序。當我使用Spring的RestTemplate命中服務時，我收到一條錯誤消息，如下所示。

我不確定是否所有的下游應用程序/服務都應該使用IdP進行註冊。

在成功通過Idp進行身份驗證並嘗試調用另一個使用Idp進行保護的應用程序後，我在第一個應用程序中收到如下錯誤消息。

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> 
 
    <head> 
 
     </head> 
 
    <body onload="document.forms[0].submit()"> 
 
     <noscript> 
 
      <p> 
 
       <strong>Note:</strong> Since your browser does not support JavaScript, 
 
       you must press the Continue button once to proceed. 
 
      </p> 
 
     </noscript> 
 
     
 
     <form action="https&#x3a;&#x2f;&#x2f;dev-305397.oktapreview.com&#x2f;app&#x2f;mncdev305397_memberapp_1&#x2f;exk6jc1rntqWvSkWD0h7&#x2f;sso&#x2f;saml" method="post"> 
 
      <div> 
 
           
 
       <input type="hidden" name="SAMLRequest" value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbDJwOkF1dGhuUmVxdWVzdCB4bWxuczpzYW1sMnA9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm90b2NvbCIgQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlVVJMPSJodHRwOi8vbG9jYWxob3N0OjQwODAvc2FtbC9TU08iIERlc3RpbmF0aW9uPSJodHRwczovL2Rldi0zMDUzOTcub2t0YXByZXZpZXcuY29tL2FwcC9tbmNkZXYzMDUzOTdfbWVtYmVyYXBwXzEvZXhrNmpjMXJudHFXdlNrV0QwaDcvc3NvL3NhbWwiIEZvcmNlQXV0aG49ImZhbHNlIiBJRD0iYTMzMzI4MjgzNTBmMmlkNDFoM2QxYjhiYjMwOWM2NCIgSXNQYXNzaXZlPSJmYWxzZSIgSXNzdWVJbnN0YW50PSIyMDE2LTA3LTI2VDA2OjI4OjI0LjcxNFoiIFByb3RvY29sQmluZGluZz0idXJuOm9hc2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmJpbmRpbmdzOkhUVFAtUE9TVCIgVmVyc2lvbj0iMi4wIj48c2FtbDI6SXNzdWVyIHhtbG5zOnNhbWwyPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj51cm46dGVzdDptZW1iZXI6cmVhZHl1c2VyPC9zYW1sMjpJc3N1ZXI+PGRzOlNpZ25hdHVyZSB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+PGRzOlNpZ25lZEluZm8+PGRzOkNhbm9uaWNhbGl6YXRpb25NZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiLz48ZHM6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIi8+PGRzOlJlZmVyZW5jZSBVUkk9IiNhMzMzMjgyODM1MGYyaWQ0MWgzZDFiOGJiMzA5YzY0Ij48ZHM6VHJhbnNmb3Jtcz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiLz48ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+PC9kczpUcmFuc2Zvcm1zPjxkczpEaWdlc3RNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjc2hhMSIvPjxkczpEaWdlc3RWYWx1ZT5IZ2ZRcm9pdUpRZFRqWS9uN1VENnJQSythazQ9PC9kczpEaWdlc3RWYWx1ZT48L2RzOlJlZmVyZW5jZT48L2RzOlNpZ25lZEluZm8+PGRzOlNpZ25hdHVyZVZhbHVlPkFGYUxJRDJicnRmQXNBbzY5RzhYcVdXbFVDSzByL3NxZXM1dlMvRThRUnQvL3EvdEZLR21xVm9XdFNmZnBlL3UyY0twZWFqMzNqM0NodzNGc0xkbzBtZ1JQYlU2ZFVGTk9BNkVYVEYyeEgzbXdYY1M4VUNRem10bnZoY0N6QUlDS0pSM3R0ZU83OWZiTisrZU4vYTQ0a1VoN2pydVZINUFBWmtVNTI4RHNCMkwvOTZnYzJKVmFkUlA3bUVEc0ZleTFPUmhmOXpUTWswZHZsSnpIRFNFd3JCOXZuWkhsZlEzSmNmZ05PYmIvNlJNaW9yRXJUK1l1NU5jOW41aC9iRkF1Vyt6SzNWcTg4WWZ1ZzNyeEsxbVZnMjM1U2VGSXJtRXd2aVBJTkkwNmFxNmlUaTVSOHo3MFdoN2l5c1BqUnh3bit5YVpkZ2dEUXhMbFY2NUlVOFI1UT09PC9kczpTaWduYXR1cmVWYWx1ZT48ZHM6S2V5SW5mbz48ZHM6WDUwOURhdGE+PGRzOlg1MDlDZXJ0aWZpY2F0ZT5NSUlEVWpDQ0FqcWdBd0lCQWdJRVVPTElRVEFOQmdrcWhraUc5dzBCQVFVRkFEQnJNUXN3Q1FZRFZRUUdFd0pHU1RFUU1BNEdBMVVFDQpDQk1IVlhWemFXMWhZVEVSTUE4R0ExVUVCeE1JU0dWc2MybHVhMmt4R0RBV0JnTlZCQW9URDFKTk5TQlRiMlowZDJGeVpTQlBlVEVNDQpNQW9HQTFVRUN3d0RVaVpFTVE4d0RRWURWUVFERXdaaGNHOXNiRzh3SGhjTk1UTXdNVEF4TVRFeU9EQXhXaGNOTWpJeE1qTXdNVEV5DQpPREF4V2pCck1Rc3dDUVlEVlFRR0V3SkdTVEVRTUE0R0ExVUVDQk1IVlhWemFXMWhZVEVSTUE4R0ExVUVCeE1JU0dWc2MybHVhMmt4DQpHREFXQmdOVkJBb1REMUpOTlNCVGIyWjBkMkZ5WlNCUGVURU1NQW9HQTFVRUN3d0RVaVpFTVE4d0RRWURWUVFERXdaaGNHOXNiRzh3DQpnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDWHFQMHdxTDJBaTFoYWVUajBhbHdzTGFmaHJEdFV0MDBFDQo1eGM3a2REN1BJU1JBMjcwWm1wWU1CNFcyNFVrMlFrdXdhQnA2ZEkveVJkVXZQZk9UNDVZWnJxSXhNZTI0NTFQQVFXdEVLV0Y1WjEzDQpGMEo0L2xCNzFUdHJ6eUg5NFJucVNIWEZmdlJOOEVZL3J6dUV6cnBackhkdE5zOUxSeUxxY1JUWE1NTzR6N1FnaEJ1eGgzSzVndTdLDQpxeHBIeDZObzgzV05aajRCM2d2V0xSV3YwNW5iWGgvRjlZTWVRQ2xUWDFpQk5BaExReFdod1hNS0I0dTFpUFEvS1NhYWwzUjI2cE9ODQpVVW11MXFWdFUxcXVRb3pTVFBEOEh2c0RxR0cxOXYyKy9OM3VmNWRSWXR2RVBmd1hOM3dJWSsvUjkzdkJBNmxubDVuVGN0WklSc3lnDQowR3Y1QWdNQkFBRXdEUVlKS29aSWh2Y05BUUVGQlFBRGdnRUJBRlF3QUFZVWpzbzFWd2pEYzJreXBLL1JSY0I4Yk1BVVVJRzBoTEdMDQo4Mkl2bktvdUdpeEdxQWNVTHdRS0l2VHM2dUdtbGdiU0c2R241Uk9iMm1sQnp0WHFRNDl6UnZpNXFXTlJ0dGlyNmV5cXdSRkdPTTZBDQo4cnhqM0poeGkyVmIvTUpuN1h6ZVZISEx6QTFzVjVod2wvMlBMbmFMMmg5V3lHOVF3QmJ3dG1rTUVxVXQvZGdpeEtiMVJ2YnkvdEJ1DQpSb2dXZ1BPTk5TQUNpVytaNW84VWRBT3FOTVpRb3pEL2kxZ09qQlhvRjBGNU9rc2pRTjd4b1FaTGo5eFhlZnhDRlE2OUZQY0ZEZUVXDQpiSHdTb0J5NWhMUE5BTGFFVW9hNXpQRHdsaXh3UmpGUVRjNVhYYVJwZ0lqeS8yZ3NMOCtZNVFSaHlYbkxxZ082N0JsTFlXL0d1SEU9PC9kczpYNTA5Q2VydGlmaWNhdGU+PC9kczpYNTA5RGF0YT48L2RzOktleUluZm8+PC9kczpTaWduYXR1cmU+PC9zYW1sMnA6QXV0aG5SZXF1ZXN0Pg=="/>     
 
           
 
      </div> 
 
      <noscript> 
 
       <div> 
 
        <input type="submit" value="Continue"/> 
 
       </div> 
 
      </noscript> 
 
     </form> 
 
      </body> 
 
</html>

我使用1563作爲我的示例應用程序的身份提供商。

從錯誤我看它是要求我們向身份提供商提出一個AuthN請求，因爲它不是直接從瀏覽器，而是通過代碼。

有人可以幫助我以正確的方式解決此問題，以便我可以成功通過一個應用程序（SP）進行身份驗證，並將安全上下文/斷言響應傳遞給涉及該流程的後續應用程序/服務。

謝謝，

的suser

來源

2016-07-26 Hello User

你的應用程序在相同或不同的域名？即app.company.com，app2.company.com或app.com app2.com？你在你的應用中使用無狀態或會話安全嗎？ – blur0224

應用程序將位於同一個域中。我們正在使用基於資源的服務，因此我們希望在應用程序中使用無狀態安全性 –

的一個解決方案爲具有SAML用戶Authn上下文傳播是通過使用IDP-代理。

1563-IDP < --->你的IDP-代理< --->您的SP-應用

IDP-Proxy是一個SAML到SAML網關了IDP之間坐着一個SP（如上所示）。 IdP-Proxy必須具有SP組件（因此它可以與Okta-IdP通話），並且它還必須具有IdP組件（以便它可以與您的SP-Apps進行通話）。

您可以使用Okta IdP配置您的IdP代理，然後將N個SP應用配置到您的IdP代理，並且可以直接與Okta-IdP通信以驗證用戶身份。然後Okta將SAML斷言發送給IdP-Proxy，IdP-Proxy驗證它，爲請求的SP-App生成一個新的SAML斷言，並將斷言發送到請求的SP-App。

檢查this瞭解更多信息。

來源

2016-07-26 19:15:22 Zeigeist

感謝您的建議。但是，就我而言，我只有一個IdP，可以與所有SP應用程序共享。只有將多個IdP連接到多個SP時，IdP-Proxy纔有意義。此外，它是一個IdP不可知論的解決方案，我的意思是它可以與除Okta以外的任何IdP一起使用。您能否提供更多關於我如何使用帶okta的IdP代理的詳細信息。您分享的鏈接更多的是使用F5，但不確定在我的場景中是否需要此功能。 –

是的，IdP-Proxy可以配置多個IdP或單個IdP（如上所述）。此外，SAML是一個協議規範，顯然是不可知的，可以由任何公司實施，無論它可以是Okta還是任何其他X公司。該鏈接僅供參考（現在我已更改爲通用IdP代理示例）。我建議的答案是你可以考慮的一個解決方案。也可能有其他解決方案。 – Zeigeist

我認爲您正在尋找的是一種讓用戶使用Okta IDP登錄任何應用程序並能夠導航到任何其他應用程序而無需再次提示輸入憑據的方式。嘗試將用於一個SP的斷言發送給另一個不起作用。已簽名的SAML請求包括請求來自何處以及它打算去的地方。您必須禁用該部分安全性才能使其正常工作，並且最終會危及應用程序的安全。

您可以使用配置有SAML的單個應用程序作爲入口點。 This project可處理SAML部分，並可將其擴展爲以允許用戶登錄到其他應用程序，而不需要通過將其與JWT and cookies結合提示輸入憑據。

這可以通過對您的域的cookies問題來完成，這些問題將包含在每個後續請求中。 This project是無狀態安全的一個例子，它也使用cookie來允許用戶關閉該選項卡，並導航迴應用程序並仍然登錄。理論上，如果cookie正確發佈，則可以將此行爲擴展到多個應用程序，即* .example.com如果其他應用程序被配置爲使用相同的cookie，則您應該看到的行爲就是我認爲您正在尋找的行爲。

希望這會有所幫助。

來源

2016-07-27 12:45:27 blur0224

向下遊服務/應用傳播SAML聲明響應/安全上下文

回答

相關問題