参考
パートナーが運営する SAML シングル サインオン（SSO）サービス - G Suite 管理者 ヘルプ
SP-Initiated と IdP-Initiated の動作の違いを Fiddler を見ながら確認してみる - Qiita
SAML2.0でのシングルサインオン実装と戦うあなたに(.NET編) - Qiita
メモ
連携に必要な情報
注: このプロセスが開始される前に、パートナーは Google に SSO サービスの URL とともに Google が SAML レスポンスを確認するのに使う公開鍵を提供しなければなりません。
図(引用)
★認証リクエスト・結果はブラウザ経由でSP、IdPへ送られる★
★SPはブラウザが提供するIdP認証結果をデジタル署名で検証する→SPにIdPの公開鍵の事前登録が要★
★SPに設定する情報は以下★
IdPの公開鍵
IdPのURL
★IdPに設定する情報は以下★
ACS(SAMLレスポンスを認証するSPのURL)
鍵ペア、デジタル署名設定
★Assertionは、認証情報等をXMLで表現したもので、SAMLレスポンスに含まれる。
図説明(引用 & コメント追加)
2. Google が SAML 認証リクエストを生成します。SAML リクエストはエンコードされ、パートナーの SSO サービスの URL に埋め込まれます。SSO URL には RelayState パラメータも埋め込まれます。このパラメータは、ユーザーがアクセスしようとしている Google アプリケーションのエンコードされた URLを含み、変更や検査なしで送り返される不透明な識別子です。
IdPへのリダイレクトURLに以下情報が含まれる。(エンコードはされる)
・SAML認証リクエスト
・SPのURL
4. パートナーは SAML リクエストをデコードし、Google の ACS（Assertion Consumer Service）とユーザーの宛先 URL（RelayState パラメータ）のために URL を抽出してから、ユーザーを認証します。パートナーは、有効なログイン認証情報を要求するか、有効なセッション クッキーを確認してユーザーを認証します。
ACSとは？SAMLレスポンスの送信先
セッションクッキー？どんな使い方？→IdPにログイン済みか判断
5. パートナーは、認証されたユーザーのユーザー名が含まれる SAML レスポンスを生成します。このレスポンスは、SAML 2.0 の仕様に従ってパートナーの DSA または RSA の公開鍵と秘密鍵でデジタル署名されます。
6. パートナーは SAML レスポンスと RelayState パラメータをエンコードして、その情報をユーザーのブラウザに返します。パートナーが提供するメカニズによって、ブラウザはその情報を Google の ACS に転送できます。たとえば、パートナーは SAML レスポンスと宛先 URL をフォームに埋め込み、クリックすると Google にフォームが送信されるボタンを表示することができます。また、自動的にフォームを Google に送信する JavaScript をページに含めることも可能です。
ブラウザに以下情報が渡される(エンコードはされる)
・SAMLレスポンス
※ACSは通常SAMLレスポンスに含まれる。
・SPのURL
7. Google の ACS は、パートナーの公開鍵を使用して SAML レスポンスを確認します。レスポンスが正常に確認されると、ACS は宛先 URL にユーザーをリダイレクトします。
ACSが"SPのURL"に最終的にリダイレクトさせる。
