SAMLアサーション応答/セキュリティコンテキストをダウンストリームサービス/アプリケーションに伝播する

私たちの環境には複数のサービスがあります。SAMLアサーション応答/セキュリティコンテキストをダウンストリームサービス/アプリケーションに伝播する

1つのサービスから最初に正常にログインした後で、アイデンティティプロバイダがアイデンティティプロバイダに挑戦することなく、アイデンティティプロバイダと通信することなく、1つ以上の参加サービスに自動ログイン/サイレントログインするシナリオがあります。

たとえば、Spring Security SAMLを使用して認証されるフロントエンドUIアプリケーションがあります。また、UI Appがバックエンドサービスと通信するときに、セキュリティコンテキスト/アサーション応答を自動的に後続のサービス呼び出しに伝播させたいとします。

おそらく、呼び出されたサービス/アプリケーションは、それに応じてアサーション応答を検証し、すべてのサービス/アプリケーションがIDプロバイダと直接通信する必要なく、そのサービス/アプリケーションへのアクセスを許可できます。

IDプロバイダによる認証後に取得されたSAMLアサーション応答を、あるアプリケーション/サービスから、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>

私は私のサンプルアプリケーションのIDプロバイダとしてoktaを使用しています。

私は、ブラウザから直接ではなくコードを使って行われるため、IDプロバイダに対してAuthN要求を行うように要求しています。

私はこの問題に近づくための正しい方法で私を助けて、1つのアプリケーション（SP）で正常に認証し、そのフローに関連する後続のアプリケーション/サービスにセキュリティコンテキスト/アサーション応答を渡すことができます。

おかげで、SAMLユーザーAuthnコンテキストの伝播を持っている

suserの

出典

2016-07-26 Hello User

あなたのアプリは同じドメインか異なるドメインにありますか？ app.company.com、app2.company.com、またはapp.com app2.comのいずれかですか？アプリケーションでステートレスまたはセッションベースのセキュリティを使用していますか？ – blur0224

アプリは同じドメインにあります。私たちはリソースベースのサービスを利用しているので、アプリケーションでステートレスなセキュリティが必要です。 –

一つの解決策は、IdPのプロキシを使用することです。

Okta-のIdP < --->あなたのIdPプロキシ< --->あなたのSP-アプリ

IdPがプロキシのIdPとの間に位置SAMLツーSAMLゲートウェイでありますSP（上記のとおり）。 IdP-ProxyにはSPコンポーネントが必要です（Okta-IdPと話すことができます）。また、IdPコンポーネントも必要です（SP-Appsと話すことができます）。

Okta IdPでIdP-Proxyを設定し、IdP-ProxyにN個のSP-appsを設定し、Okta-IdPと直接通信してユーザを認証することができます。 OktaはIdP-ProxyにSAMLアサーションを送信し、IdP-Proxyはそれを検証し、要求されたSP-Appに固有の新しいSAMLアサーションを生成し、そのアサーションを要求されたSP-Appに送信します。

詳細はthisを確認してください。

出典

2016-07-26 19:15:22 Zeigeist

あなたの提案をありがとう。しかし、私の場合、すべてのSP-Appsと共有されるIdPは1つしかありません。 IdPプロキシは、複数のSPと複数のIdPを接続する場合にのみ意味をなさないでしょうか。さらに、それはIdPの無関係な解決策です。つまり、Okta以外のIdPで使用することができます。 oktaでIdPプロキシをどのように使用することができるかについての詳細を教えてください。あなたが共有しているリンクは、F5を使用したほうが多いですが、私のシナリオでこれが必要なのかどうかはわかりません。 –

はい、IdP-Proxyは、複数のIdPまたは単一のIdP（上記のように）で構成できます。また、SAMLはプロトコル仕様であり、Oktaやその他のX社のいずれの企業であっても、明らかに無関係で、どの企業でも実装できます。そのリンクは参照用です（今は一般的なIdP-proxyの例に変更しました）。私が提案した答えは、あなたが考えることができる1つの解決策です。他にも解決策があるかもしれません。 – Zeigeist

あなたが探していると思うのは、Okta IDPを使っているすべてのアプリケーションにユーザーがログインし、資格情報の入力を求めずに他のアプリケーションにナビゲートできる方法です。あるSPを対象としたアサーションを別のSPに送信しようとすると、動作しません。署名されたSAML要求には、要求がどこから来たのか、どこに行くのかが含まれます。セキュリティを有効にするには、その部分を無効にする必要があり、最終的にはアプリケーションのセキュリティが損なわれます。

エントリポイントとして機能することができるSAMLで設定された1つのアプリを持つことができます。 This projectはSAML部分を処理し、を拡張して、ユーザがJWT and cookiesと組み合わせて資格情報の入力を求めずに他のアプリケーションにログインできるようにすることができます。

これは、各後続のリクエストに含まれる、ドメインに対するCookieの問題によって実行できます。 This projectは、Cookieを使用してタブを閉じて、アプリに戻ってまだログインしていないステートレスセキュリティの例です。理論的には、クッキーが正しく発行されていれば、 ie * .example.com他のアプリが同じCookieを使用するように設定されている場合は、あなたが探していると思われる動作が表示されます。

これが役に立ちます。

出典

2016-07-27 12:45:27 blur0224

SAMLアサーション応答/セキュリティコンテキストをダウンストリームサービス/アプリケーションに伝播する

答えて

関連する問題