6

私たちは、IdP がユーザーを認証できるように SAML を有効にしたアプリを持つサービス プロバイダーです。全員が同じページにいることを確認するには

  • ID プロバイダー (IdP) は、ユーザーの認証を行うアプリケーションです。
  • サービス プロバイダー (SP) は、ID と認証を IdP に連携させるエンド アプリケーションです。
  • SAML は、IdP が SP に対して信頼できる ID アサーションを行うことを可能にするプロトコルです。SAML 2.0 を使用しています ( http://en.wikipedia.org/wiki/SAML_2.0 )

フェデレーション ID の詳細については、http: //developer.okta.com/docs/guides/saml_guidance.htmlをご覧ください。

現在 IdP として Okta のみを使用していますが、別の IdP と統合する必要がある状況に遭遇しました。アプリが Okta とのみ通信するようにし、Okta にこの別の IdP との通信とそのアサーションの検証を処理させたいと考えています。私たちの特定のユースケースにより、アプリは基になる IdP を使用する必要があることを認識しているため、IdP ディスカバリーは必要ありません。

認証フローが次のようになるように Okta を構成します。

  1. 私たちのアプリは、ユーザーを Okta のエンドポイントにリダイレクトし、認証に基盤となる IdP を使用することを示します。

  2. Okta と基盤となる IdP は、ユーザーを認証し、認証を検証するために必要なことは何でも行います。

  3. このアプリは、Okta によって署名された、ユーザーを認証する ACS エンドポイントへの単一の応答を (HTTP-POST 経由で) 取得します。

エンド ユーザーの観点から見ると、ユーザーは service-provider.com に移動し、Okta を介してunderlying-idp.com にリダイレクトされ、必要な認証を実行してから、service-provider.com にリダイレクトされます。リダイレクト中にブラウザのアドレス バーに Okta URL が一時的に表示される可能性があることを除いて、エンド ユーザーは中間の Okta レイヤーに気づきません。

これまでのところ、Okta インスタンスでインバウンド SAML をセットアップして、基礎となる IdP を介して Okta でユーザーを認証できるようにしました。SAMLRequest を使用してインバウンド SAML 構成ページで指定されたエンドポイントにアプリをリダイレクトしますが、リンクは Okta でユーザーを認証するためのものであり、Okta を使用して SP のユーザーを認証するためのものではないため、これによりユーザーが Okta ダッシュボードに移動します。関連する構成を参照してください。

ユースケースが可能になるように Okta を構成するにはどうすればよいでしょうか? 理想的には、Okta が仲介者または仲介者として機能し、SAML 要求/アサーションをチェックして渡すことを望んでいます。具体的には、これらのユーザーが認証された Okta ユーザーである必要はありません。基礎となる IdP のアサーションに基づいて、ユーザーが誰であると主張するかを Okta がアサートする必要があるだけです。

4

2 に答える 2