SAMLを使用してSSOを理解しようとしています。 RelayStateパラメーターに遭遇しましたが、SSOでエンコードされたURLを最初に送信する理由が正確にわかりません。正確にはどういう意味ですか?
Google Developer documentation から以下をお読みください:
GoogleはSAML認証リクエストを生成します。 SAML要求はエンコードされ、パートナーのSSOサービスのURLに埋め込まれます。ユーザーが到達しようとしているGoogleアプリケーションのエンコードされたURLを含むRelayStateパラメーターもSSO URLに埋め込まれています。このRelayStateパラメータは、変更や検査なしで返される不透明な識別子を意味します
RelayState
の本来の意味は、SPがAuthnRequest
とともにIDPに何らかの値を送信し、それを取得できることです。 SPは必要な値をRelayState
に入れることができ、IDPはそれを応答にエコーバックするだけです。
この
RelayState
パラメーターは、変更や検査なしで返される不透明な識別子を意味します。
Idpで開始されたログオンを使用する場合、RelayState
のもう1つの事実上の標準使用もあります。その場合、SPからの着信要求はないため、リレーされる状態はありません。代わりに、IDPはRelayState
を使用して、SPに信号を送りますSPがリダイレクトするURLサインオンが成功した後。それはSAML2標準の一部ではないです。
GoogleはSPで開始されたサインオンでもターゲットURLにRelayState
を使用しているようですが、これはまったく問題ありません。しかし、IDPは、ドキュメントに書かれているように、それを中継するだけです。
RelayStateはSPにあるリソースの識別子で、IDPは(ログイン成功後に)ユーザーをリダイレクトします。これは、SPで最初に要求したのと同じページに再びリダイレクトされるため、SSOプロセスをユーザーにとってより一時的なものにする方法です。
公式のSAMLドキュメントに従って、
一部のバインディングは、状態情報を保存および伝達するための「RelayState」メカニズムを定義します。そのようなメカニズムが、SAMLプロトコルの最初のステップとして要求メッセージの伝達に使用される場合、応答の伝達に後で使用されるバインディングの選択と使用に要件を課します。つまり、SAML要求メッセージにRelayStateデータが付随している場合、SAMLレスポンダーは、RelayStateメカニズムもサポートするバインディングを使用してSAMLプロトコル応答を返さなければならず(MUST)、要求とともに受信した正確なRelayStateデータを対応するRelayStateに配置する必要があります応答のパラメーター。