SP対IdPで開始されるSSO
この記事では、2つのフェデレーション・デプロイメント間でSPとIdPによって開始されたSSOの概念、およびこれらの2つのフローの違いについて説明します。
この記事では、フェデレーションSSO中にIdPとSP間で共有されるユーザー状態または戻りURLの概念についても説明します。
-
WS- Fed 1.1のSAML 1.1
wctx
のSAML 2.0 TARGETの場合はRelayState
-
OpenID 2.0の場合は
openid.return_to
(戻りSSO) -
URLには、SPでのユーザー状態を表す問合せパラメータを含めることができます)
この記事では、SAML 2.0プロトコルを使用した例を紹介していますが、他のプロトコルについても同様です。
フェデレーションSSOフロー
トポロジ
一般的なフェデレーション・デプロイメントは、次のエンティティで構成されます。
-
ユーザーがアカウントを持ち、認証が発生する
IdP
サーバーのセキュリティ・ドメイン -
SPサーバーのセキュリティードメイン
-
SPフェデレーション・サーバー
-
SSOサーバー(SSOサーバーとSPフェデレーション・サーバーが同じエンティティである場合もあります)
-
SSOサーバーと統合されたSSO Webエージェント。リソースを保護し、ユーザーが認証され、リソースにアクセスする権限があることを確認します。そうしないと、認証フローまたは認可失敗が発生する可能性があります
-
リソースまたはWebアプリケーション
-
SPが開始するSSO
SP開始SSOフローは、SPセキュリティ・ドメインから開始されたフェデレーションSSO操作です。SPフェデレーション・サーバーによってフェデレーション認証リクエストが作成され、ユーザーがIdP
にリダイレクトされ、メッセージと操作状態を表す短い文字列が表示されます。
-
フェデレーション認証リクエストは、使用されるプロトコルによって異なります。
-
SAML 2.0: AuthnRequest
-
SAML 1.1: SPを表すパラメータを持つURL
-
WS- Fed: SPおよびその他のオプション・パラメータを表す
wtrealm
パラメータを持つURL -
OpenID 2.0: OpenID 2.0リクエスト
-
-
操作状態(フェデレーションSSO操作の開始前にユーザーが実行していた状態)は、状態全体ではなく、SPサーバーのランタイム・ストレージの状態へのポインタとして、ユーザーとともにIdPに送信されるメッセージで伝達されます。この情報は、プロトコルに応じて異なります。
-
SAML 2.0:
RelayState
パラメータ -
SAML 1.1: TARGETパラメータ
-
WS- Fed:
wctx
パラメータ -
OpenID 2.0:
openid.return_to
パラメータ。SP URLで、IdPでの認証後にユーザーがリダイレクトされます。SPは実行時にSPによって生成されるため、操作状態を参照する問合せパラメータを含めることができます。
-
動作状態に関するノート: 通常、メッセージで共有される状態は長すぎないようにしてください。リダイレクト・フローが、リダイレクトURLの長さが、ブラウザがURLで処理できる最大長を超える可能性があるためです。したがって、SPが開始されたSSOでは常にSPを使用することをお薦めします。
-
SPのメモリー/DBストレージに動作状態を格納します。
-
動作状態へのポインタを
RelayState
/TARGET
/wctx
として送信します
SP開始SSOフローをトリガーするには、次の2つの方法があります。
-
ユーザーは、フェデレーションSSOフローを開始するリソースへのアクセスをリクエストします。フェデレーションSSO操作が実行されると、ユーザーは最初にリクエストされたリソースにリダイレクトされます。
-
または、ユーザーがSPサーバー上のサービスに直接アクセスして、リモートIdPを使用してフェデレーションSSOフローを明示的に開始します。この場合、ユーザーは通常、フェデレーションSSO操作の実行後にユーザーをリダイレクトするURLを指定します。
リソースへのアクセス
これはフェデレーションSSO操作の最も一般的なフローで、ユーザーは保護されたリソースにアクセスしようとし、実行時にSSOシステムがフェデレーションSSOを介してユーザーを認証する必要があると判断します。
このフローを使用するユースケースは次のとおりです。
-
ユーザーは、保護されたリソースを参照するページのリンクをクリックします。
-
ユーザーは、保護されたリソースを参照するポータル・ページのリンクをクリックします
-
ユーザーは保護されたリソースのブックマークを持っています
フローのステップは次のとおりです。
-
ユーザーのブラウザが保護されたリソースへのアクセスをリクエスト
-
SSO Webエージェントはコールをインターセプトし、ユーザーを認証する必要があると判断し、ユーザーのブラウザにリダイレクトを発行します。
-
ユーザーのブラウザはSSOサーバーにアクセスし、SSO Webエージェントによってリダイレクトされます。
-
SSOサーバーは、フェデレーションSSOを介してユーザーを認証し、
IdP
を選択し、SAML 2.0 AuthnRequestメッセージを作成して、操作状態をSSOサーバー・ストアに保存し、SAMLメッセージとSPの操作状態を参照する文字列を使用して、ユーザーのブラウザをIdP
にリダイレクトすることを決定します -
ユーザーのブラウザは、AuthnRequestメッセージを使用して
IdP
SAML 2.0サービスにアクセスします。
図Accessing_Resources_Screen.jpgの説明
IdP
がSAML 2.0 AuthnRequestメッセージを受信すると、サーバーはユーザーにチャレンジする必要があるかどうかを判断します(まだ認証されていない、セッションがタイムアウトしました)。ユーザーを識別できた後、フェデレーションSSOフローが再開されます。
-
IdP
は、ユーザー情報および認証データを含むSAML 2.0アサーションを使用してSSOレスポンスを作成し、メッセージおよびRelayState
パラメータを使用してユーザーのブラウザをSPにリダイレクトします -
ユーザーのブラウザでは、SPサーバーにSSOレスポンスが表示されます。
-
SPはSAML 2.0アサーションを検証し、ユーザーのSSOセッションを作成します。SSOサーバーは、ユーザーのブラウザを最初にリクエストされたリソースにリダイレクトします
-
ユーザーのブラウザがリソースへのアクセスをリクエストします。今回は、SSO Webエージェントがリソースへのアクセス権を付与します
-
Webアプリケーションは、ユーザーのブラウザに応答を返します。
図Accessing_Resources_Response_Screen.jpgの説明
前述のように、フェデレーションSSOは実行時にSSOサーバーによってのみトリガーされるため、このフローが最も一般的に使用されます。SPセキュリティ・ドメイン内の他のコンポーネントはフェデレーションを認識する必要がありません。
フェデレーションSPサービスの呼び出し
このフローは広く使用されていません。SPサーバー上のサービスにアクセスしてフェデレーションSSOをSPで開始し、ユーザーがすでに持つことができる既存の有効なセッションを無視することを意味するためです。そのため、次のものに対するパフォーマンスへの影響が発生するため、これは避ける必要があります。
-
フェデレーションSSOとしてのサーバーは高価です(一部のプロトコルではXML、メッセージを保護するためのデジタル署名、サーバー間の通信)。
-
ブラウザが様々なドメインにリダイレクトされる際のユーザー・エクスペリエンスにより、ターゲットとする保護されたリソースにユーザーがアクセスする前に遅延が発生します。
このフローを使用するユースケースは次のとおりです。
-
ユーザーは、保護されたリソースを参照するページのリンクをクリックする(通常ではない)
-
ユーザーは、保護されたリソースを参照するポータル・ページのリンクをクリックします
このフローを使用するユースケースには、次のステップが含まれます。
-
ユーザーのブラウザはSPにアクセスし、オプションで次を指定してフェデレーションSSOフローを開始します。
-
フェデレーションSSOの完了後にユーザーのブラウザをリダイレクトするURL
-
使用する
IdP
-
-
SSOサーバーは、指定されていない場合は
IdP
を選択し、指定されていない場合はデフォルトの戻りURLを選択し、SAML 2.0 AuthnRequestメッセージを作成して、操作状態をSSOサーバー・ストアに保存し、SAMLメッセージおよびSPの操作状態を参照する文字列を使用して、ユーザーのブラウザをIdP
にリダイレクトします -
ユーザーのブラウザは、AuthnRequestメッセージを使用して
IdP
SAML 2.0サービスにアクセスします。
図IdP_Service_with_AuthnRequest_Screen.jpgの説明
IdP
がSAML 2.0 AuthnRequestメッセージを受信すると、サーバーはユーザーにチャレンジする必要があるかどうかを判断します(まだ認証されていない、セッションがタイムアウトしました)。ユーザーの識別が可能になると、フェデレーションSSOフローが再開されます。
-
IdP
は、ユーザー情報および認証データを含むSAML 2.0アサーションを使用してSSOレスポンスを作成し、メッセージおよびRelayState
パラメータを使用してユーザーのブラウザをSPにリダイレクトします -
ユーザーのブラウザでは、SPサーバーにSSOレスポンスが表示されます。
-
SPはSAML 2.0アサーションを検証し、ユーザーのSSOセッションを作成します。SSOサーバーは、ユーザーのブラウザを最初にリクエストされたリソースにリダイレクトします
-
ユーザーのブラウザがリソースへのアクセスをリクエストします。今回は、SSO Webエージェントがリソースへのアクセス権を付与します
-
Webアプリケーションは、ユーザーのブラウザに応答を返します。
図IdP_Service_with_Response_Screen.jpgの説明
フェデレーションSSOは、ユーザーがすでに有効なSSOセッションを持っている場合でも静的にトリガーされるため、このフローはほとんど使用しないでください。また、SPセキュリティードメインの一部のコンポーネントがSPサービスを認識していることも意味します。
IdP開始されたSSO
IdPによって開始されるSSOフローは、IdP
セキュリティ・ドメインから開始されたフェデレーションSSO操作で、IdPフェデレーション・サーバーによってフェデレーションSSOレスポンスが作成され、レスポンス・メッセージおよびオプションの操作状態を使用してユーザーがSPにリダイレクトされます:
-
フェデレーションSSOレスポンスは、使用されるプロトコルによって異なります:
-
SAML 2.0: アサーション付きSAMLResponse
-
SAML 1.1: アサーション付きレスポンス
-
WS- Fed: アサーション付きレスポンス
-
OpenID 2.0: OpenID 2.0レスポンス
-
-
このフローのオプションの操作状態は、SPでのフェデレーションSSOの完了後にユーザーをリダイレクトするURLを示します。見つからない場合、SPはユーザーをリダイレクトする場所を決定する必要があります。この情報は、プロトコルに応じて異なります。
-
SAML 2.0:
RelayState
パラメータ -
SAML 1.1:
TARGET
パラメータ -
WS- Fed:
wctx
パラメータOpenID 2.0: このプロトコルは、IdP
によって開始されたSSOフローをサポートしていません。
-
前の項で説明したように、メッセージで共有される状態は長すぎないようにしてください。リダイレクトURLの長さがURLに対してブラウザで処理できる最大長を超えると、リダイレクト・フローが中断される可能性があるためです。
このフローは、SPがホストするリソースにIdPユーザーがアクセスする必要がある場合に一般的に使用されますが、フェデレーションSSOの最適なアプローチではありません。これは、ユーザーがすでに持つことができるSPの既存の有効なセッションを無視するためです。そのため、次のものに対するパフォーマンスへの影響が発生するため、これは避ける必要があります。
-
フェデレーションSSOとしてのサーバーは高価です(一部のプロトコルではXML、メッセージを保護するためのデジタル署名、サーバー間の通信)。
-
ブラウザが様々なドメインにリダイレクトされる際のユーザー・エクスペリエンスにより、ターゲットとする保護されたリソースにユーザーがアクセスする前に遅延が発生します。
このフローを使用するユースケースは次のとおりです。
- ユーザーは、SPの保護されたリソースを参照する
IdP
ポータル・ページのリンクをクリックします。
このフローを使用するユースケースには、次のステップが含まれます。
-
ユーザーのブラウザは
IdP
にアクセスし、次を指定してフェデレーションSSOフローを開始します-
使用するSP
-
オプションで、フェデレーションSSOの完了後にユーザーのブラウザをリダイレクトするURL
-
-
ユーザーを識別した後、
IdP
は、ユーザー情報および認証データを含むSAML 2.0アサーションを使用してSSOレスポンスを作成し、メッセージおよびRelayState
パラメータを使用してユーザーのブラウザをSPにリダイレクトします -
ユーザーのブラウザでは、SPサーバーにSSOレスポンスが表示されます。
-
SPはSAML 2.0アサーションを検証し、ユーザーのSSOセッションを作成します。SSOサーバーは、ユーザーのブラウザを最初にリクエストされたリソースにリダイレクトします
-
ユーザーのブラウザがリソースへのアクセスをリクエストします。今回は、SSO Webエージェントがリソースへのアクセス権を付与します
-
Webアプリケーションは、ユーザーのブラウザに応答を返します。
まとめ
様々なフローで見られるように、フェデレーション・デプロイメントの最適なアプローチは、フェデレーションSSOがSSOサーバーで必要であるとみなされる実行時に、フェデレーションSSOがSSOサーバーによってトリガーされるようにすることです。その他のケースでは、静的なアプローチがあり、必要でない場合でも常にフェデレーションSSOフローが実行され(たとえば、ユーザーがすでに有効なセッションがある場合)、不要なフェデレーション操作の実行が影響を受けます。
-
サーバーのパフォーマンス(CPU、LDAP/RDBMSの相互作用...)
-
リダイレクトを含むフェデレーションSSO操作の実行にかかる時間に基づくユーザーのレスポンス時間。
その他の学習リソース
docs.oracle.com/learnで他のラボを探すか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスしてOracle Learning Explorerになります。
製品ドキュメントについては、Oracle Help Centerを参照してください。