<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_2" InResponseTo="identifier_1" Version="2.0" IssueInstant="2004-12-05T09:22:05Z" Destination="https://sp.example.com/SAML2/SSO/POST">
  <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="identifier_3" Version="2.0" IssueInstant="2004-12-05T09:22:05Z">
    <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
    <!-- a POSTed assertion MUST be signed -->
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">3f7b3dcf-1674-4ecd-92c8-1544f346baf8</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData InResponseTo="identifier_1" Recipient="https://sp.example.com/SAML2/SSO/POST" NotOnOrAfter="2004-12-05T09:27:05Z"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2004-12-05T09:17:05Z" NotOnOrAfter="2004-12-05T09:27:05Z">
      <saml:AudienceRestriction>
          <saml:Audience>https://sp.example.com/SAML2</saml:Audience>
        </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2004-12-05T09:22:00Z" SessionIndex="identifier_3">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef>
        </saml:AuthnContext>
    </saml:AuthnStatement>
  </saml:Assertion>
</samlp:Response>

2020-05-18

IdP-Initiated SSOについて

SAML

参考

SP-Initiated と IdP-Initiated の動作の違いを Fiddler を見ながら確認してみる - Qiita

メモ

・IdP-InitiatedとSP-Initiatedの2つのタイプのSSOがある
・違いはログイン時に最初にどっちにアクセスするか？
・IdP-InitiatedはIdPログイン後、SPにリダイレクトされSSOする。
・IdP-Initiatedの時は、IdPがSAMLリクエストを生成してる。
　※SAMLリクエストには、ACS、SP URLの情報が含まれるべき。
　※IdPに上記を設定する必要あり。

2020-05-18

SAML2.0について

SAML

参考

パートナーが運営する 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 の公開鍵と秘密鍵でデジタル署名されます。

SAMLレスポンスがIdPの秘密鍵でデジタル署名される。

6. パートナーは SAML レスポンスと RelayState パラメータをエンコードして、その情報をユーザーのブラウザに返します。パートナーが提供するメカニズによって、ブラウザはその情報を Google の ACS に転送できます。たとえば、パートナーは SAML レスポンスと宛先 URL をフォームに埋め込み、クリックすると Google にフォームが送信されるボタンを表示することができます。また、自動的にフォームを Google に送信する JavaScript をページに含めることも可能です。

ブラウザに以下情報が渡される(エンコードはされる)
・SAMLレスポンス
　※ACSは通常SAMLレスポンスに含まれる。
・SPのURL