「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次 †

↑

概要 †

汎用認証サイトにSAML2.0を実装するため仕様を読む。

  • ターゲットはSP Initiated な Web Browser SSO Profileに絞る。
  • ココに書いた情報は、SAML の Technical Overviewと他社コンテンツの情報の範囲。
↑

ロードマップ †

↑

Technical Overview †

SAML2.0 の 技術概要

↑

Profiles †

特定のユースケースを実現するための組み合わせ方を定義。

  • セキュリティ情報を伝達するためのSAMLの豊富で柔軟な
    構文を使用および制限するための一連の特定の規則を定義。
  • 属性プロファイルの構文の側面をカバーするいくつかの関連する小さなスキーマ。
↑

Bindings †

  • SAMLアサーションと要求/応答プロトコル・メッセージを交換する方法を定義
  • SAMLのメッセージを実際の通信プロトコル（HTTPなど）にマッピングする方法を定義。
↑

Core (Assertions and Protocols) †

  • 認証、属性、許可情報を記述したプロトコル・メッセージを伝達する
    XMLエンコード・アサーションを作成するための構文とセマンティクス
  • アサーション用とプロトコル用のスキーマを定義する。
    • 認証情報を表す用のXMLのスキーマ（SAML Assertions）
    • メッセージ交換のプロトコル用のXMLのスキーマ（SAML Protocols）
↑

SAML Metadata †

  • SAMLパーティ間で設定情報を表現および共有するXMLのスキーマを定義
  • SPがIdPを利用するための情報を記述して、IdPとSPの信頼関係を構築できる。
    • エンティティのサポートされているSAMLバインディング
    • 運用上の役割（IDP、SPなど）
    • 識別子情報、サポートID属性
    • および暗号化と署名のための鍵情報
↑

Authentication Context †

  • 認証メカニズムを記述するAuthentication Context宣言を記述するための構文を定義
  • 認証のタイプと強度に関する詳細な情報をSPが要求し、IdPは、これに応答する。
    • Authentication Context宣言を作成するためのメカニズムを定義する一般的なXMLスキーマ
    • 一般的に使用されるSAMLのAuthentication Contextクラスのセットがあります。
↑

XML Signature Syntax and Processing †

XMLデジタル署名処理規則と構文

↑

ユースケース †

↑

参加者 †

  • システム・エンティティ
    システム・エンティティは、さまざまなSAMLロールで動作するが、
    最低限、SAML交換は、以下のシステム・エンティティ間で行われる。
  • アサーティング・パーティ（SAMLオーソリティ）
    • SAMLアサーションを行うシステム・エンティティ
    • ユーザもアサーティング・パーティの参加者である可能性がある。
  • リライング・パーティ（RP）
    受け取ったアサーションを使用するシステム・エンティティ
  • リクエスタ / レスポンダ
    • アサーティング・パーティとリライング・パーティは、SAMLリクエスタにもレスポンダにもなりうる。
    • アサーティング・パーティの情報に依存するという回答側の意向は、アサーティング・パーティとの信頼関係に依存
  • ロール
  • SSOのロール
  • Identityプロバイダ（IdP）
    ≒ アサーティング・パーティ（SAMLオーソリティ）
  • Serviceプロバイダ（SP）
    ≒ リライング・パーティ
  • ID連携のロール
  • 属性リクエスタ
    アイデンティティ属性クエリ
  • 属性機関の役割
    アイデンティティ属性クエリに応答してSAMLエンティティがアサーションを生成
  • サブジェクト≒プリンシパル
    • 殆どのSAMLアサーションの中心にある対象
    • 通常は人間、それ以外にも会社やコンピュータなどエンティティを表す。
↑

Web-SSO †

  • マルチドメインWebシングルサインオン
  • SAMLが適用される最も重要なユースケース
↑

IDフェデレーション †

  • 考慮しなければならない多くの質問
    • ユーザーは、既存のローカルIDをサイトに持っているか？
    • ユーザーの連合IDの確立と終了は静的か？動的か？
    • ユーザーは連合IDの確立に明示的に同意する必要があるか？
    • ユーザーに関するID属性を交換する必要があるか？
    • IDフェデレーションは、SessionIDなどの識別子に依存するべきか？
    • 情報が暗号化されるべきか？交換される情報のプライバシーは大きな関心事か？
  • 連合ID機能を強化するための2つの機能
    • フェデレーション名識別子の動的確立と管理をサポートする、新しい構成とメッセージ
    • プライバシー保護の特徴を持った2つの新しいタイプの名前識別子
  • プロバイダー間のユーザー情報の維持および更新
↑

アカウントリンク †

連合IDをローカルIDと関連付けるプロセスは、アカウントリンクと呼ばれる。

  • IdP検出機能を使用し、SPからIdPにアカウントリンクするかしないかをユーザに問う。
  • ユーザが、フェデレーションに同意するとIdPにリダイレクトされる。
  • IdPでSPのフェデレーション名識別子が生成され、IdP上のアカウントにリンクされる。
  • IdPでSPは、後続のトランザクションでこの識別子を使用してユーザを参照する。
  • IdPからSPにリダイレクトされた後、この識別子をSPのローカル・アカウントに関連付ける。

※ 追加のサイトとアカウントリンクする場合は、
　新たにフェデレーション名識別子を生成し、上記手順を繰り返す。

↑

アーキテクチャ †

↑

基本概念 †

↑

基本的なSAMLの概念 †

（Profile（Binding（Protocol（Assertion））））

                     ・Metadata
                     ・Authentication Context
↑

Assertions †

アサーティング・パーティが真実であると主張するプリンシパルに関する
ステートメントを伝えるXMLスキーマによって定義されたアサーション。

  • リライング・パーティからの要求に基づいてアサーティング・パーティによって作成される。
  • 特定の状況下では、アサーションは未承諾の方法でリライング・パーティに配信できる。
↑

Protocols †

  • SAMLのリクエスト / レスポンスを行うプロトコル。
  • これにより、アサーションの入手や、IDマネジメントを行う。
↑

Bindings †

参加者間でSAMLプロトコル・メッセージを転送するために下位レベルの
通信またはメッセージングプロトコル（HTTPまたはSOAPなど）を使用する方法

↑

Profiles †

  • WebブラウザSSOプロファイルなどの特定のユースケースを満たすように定義される。
  • SAMLアサーション、プロトコル、およびバインディングの内容に対する制約を定義する。
  • プロトコルメッセージやバインディングを参照しない属性プロファイルもある。
    （X.500 / LDAP、DCEなどの一般的な使用環境と一致する方法でアサーションを使用）
↑

構築と展開の2つの概念 †

  • Authentication Context#zdb546a9
    Authentication Contextの例
    #Authentication Context説明
    1urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified不特定の方法で認証したことを示す。
    2urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport?HTTPSでパスワードを提示して認証したことを示す（≒既定値）
    3urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport?HTTPでパスワードを提示して認証したことを示す（推奨されない）
    4urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession?セッション等を使用し、
    ・すでに認証済みであること示す。
    ・過去のある時点で認証したこと示す。
    5urn:oasis:names:tc:SAML:2.0:ac:classes:X509デジタル署名により認証したことを示す。
↑

高度な概念 †

  • Subject Confirmation
  • Assertionsには、SubjectConfirmation?という要素を含めることができる。
  • 実際的には、Subject Confirmationは、
    • Assertionの利用者が許可されている条件
    • ≒ SPが検証を行うための手段を提供する。
  • Method属性に3つの値を定義することによって、
    3つの異なるセキュリティシナリオに対応する。
  • urn:oasis:names:tc:SAML:2.0:cm:holder-of-key
    SubjectConfirmationData?を使用した、記名式切符
  • urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
    どのRPがそのClaimを使用することを許可されるべきかを決定する際に他の基準を使用
↑

SAML Components †

↑

Assertions †

通常、アサーションは以下から構成される。

  • アサーションのsubject
    • subject（主題）
    • subjectが存在しない場合、他の方法で識別される。
      例えばsubjectの確認に使用された証明書
  • アサーションの検証条件
  • アサーション・ステートメント
  • Authentication statements
    • ユーザーを正常に認証した当事者によって作成される。
    • 最低でも、認証に使用される特定の手段と認証が行われた特定の時間を説明。
  • Attribute statements
    • サブジェクトに関する特定の識別属性
    • 例えば、ユーザー"John Doe"は"ゴールドカードステータス"を持つ。
  • Authorization decision statements
    • 対象がする権利があるものを定義する
    • 例えば、ユーザー"John Doe"は"特定の品目を購入すること"が許可されている。
↑

Protocols †

いくつかの一般化された要求/応答プロトコルを定義する。

  • Authentication Request Protocol
  • 以下を含むアサーションを要求できるようにする手段を定義。
    • Authentication statements
    • Attribute statements
  • Web Browser SSO Profile
    SPからIdPにユーザをリダイレクトするときに使用する。
  • Single Logout Protocol
    • プリンシパルのアクティブ・セッションのログアウト・メカニズムを定義。
    • ログアウトは以下の様なエンティティが開始できる。
      • ユーザ（直接開始
      • SP/IdP（Sessionタイムアウト、管理者コマンド
  • Assertion Query and Request Protocol
    アサーションを取得するための一連のクエリを定義
  • Artifact Resolution Protocol
    アーティファクトと呼ばれる小さな固定長の値を使用して、
    メッセージを参照によって渡すことができるメカニズムを提供
  • Name Identifier Management Protocol
    • 要求の発行者は、SP/IdPのどちらでもかまわない。
    • プリンシパルを参照するために使用される名前識別子に関するメカニズムを提供。
      • 形式を変換する
      • 関連付けを開始 / 終了する
  • Name Identifier Mapping Protocol
  • 適切なポリシー制御に従って、名前識別子を
    別の名前識別子にマッピングするためのメカニズムを提供
  • アプリケーション統合シナリオでは、あるSPがIdPから
    別のSPで使用できるユーザーの名前識別子を要求することを許可する。
↑

Bindings †

トランスポート層上で、プロトコルメッセージをどのように伝達するか？

  • HTTP Redirect Binding
    リダイレクト（302応答）を使用してプロトコルメッセージを転送する方法を定義
  • HTTP POST Binding
    HTMLのformコントロール(base64)でプロトコルメッセージを転送する方法を定義
  • HTTP Artifact Binding
    • Artifact Resolution Protocolを使用して、プロトコルメッセージを転送する方法を定義
    • HTMLのformコントロールと、URL中のQuery stringを使用する方法がある。
  • SAML SOAP Binding
    SOAP 1.1を使用して、プロトコルメッセージが転送される方法を定義
  • Reverse SOAP (PAOS) Binding
    • HTTPクライアントをSOAPレスポンダにする多段階のSOAP / HTTPメッセージ交換を定義
    • IDPディスカバリをサポートする拡張クライアントおよびゲートウェイ・プロキシで使用
  • SAML URI Binding
    URIを解決することによって既存のSAMLアサーションを取得するための手段を定義
↑

Profiles †

特定シナリオでアサーション、プロトコル、バインディングの組合せ（制約）を定義

  • Web Browser SSO Profile
    標準のWebブラウザでシングルサインオンを実現する
  • 以下の使用方法を定義する。
    • Authentication Request Protocol
    • SAML Response messages & assertion
  • バインディングの組合せを定義
    • HTTP Redirect Binding
    • HTTP POST Binding
    • HTTP Artifact Binding
  • Enhanced Client and Proxy (ECP) Profile
    • 特殊クライアントまたはゲートウェイ・プロキシ用の
    • Reverse-SOAP (PAOS) や SOAPを使用する特殊SSOプロファイルを定義す。
  • Identity Provider Discovery Profile
    ユーザが以前に訪問したことのあるIdPについてSPが知るためのメカニズムを定義
  • Single Logout Profile
  • 以下の使用方法を定義する。
    • Single Logout Protocol
    • SAML Response messages & assertion
  • バインディングの組合せを定義
    • HTTP Redirect Binding
    • HTTP POST Binding
    • HTTP Artifact Binding
    • SAML SOAP Binding
  • Assertion Query and Request Profile
    • 同期バインディング
  • 以下の使用方法を定義する。
    • Assertion Query and Request Protocol
    • SAML Response messages & assertion
  • Artifact Resolution Profile
  • 以下の使用方法を定義する。
    • Artifact Resolution Protocol
  • バインディングを定義
    • SAML SOAP Binding
  • Name Identifier Management Profile
  • 以下の使用方法を定義する。
    • Name Identifier Management Protocol
  • バインディングの組合せを定義
    • HTTP Redirect Binding
    • HTTP POST Binding
    • HTTP Artifact Binding
    • SAML SOAP Binding
  • Name Identifier Mapping Profile
  • 以下の使用方法を定義する。
    • Name Identifier Mapping Protocol
  • バインディングを定義
    • SAML SOAP Binding
↑

EndPoint? †

この項目は、SAMLの公式資料にはないが、図を見ると、
EndPoint?には以下の様な名称が付与されている。

  • Single sign-on
  • SAML Requestを受けるEndPoint?
    SSO Service
  • SAML Responseを受けるEndPoint?
    Assertion Consumer Service
  • Artifact
  • Artifact Requestを発行するEndPoint?
    • SSO Service(RequestでArtifactを使用する場合)
    • Assertion Consumer Service(ResponseでArtifactを使用する場合)
  • Artifact Requestを受けるEndPoint?
    Artifact Resolution Service
  • Single logout
  • SAML Requestを受けるEndPoint?
    Single logout Service
  • Logout Request/Responseを受けるEndPoint?
    Single logout Service
  • SAML Responseを受けるEndPoint?
    Assertion Consumer Service
  • Termination
  • ManageIDNameRequest? (Termination) を受けるEndPoint?
    Manage NameID Service
  • ManageIDNameRequest? (Affirmative) を受けるEndPoint?
    ？
↑

SAML XML構造と例 †

↑

SAMLコンポーネントとの関係 †

Transport Protocol

  • Transport Protocol ヘッダ
  • Transport Protocol ペイロード
    • レスポンス（アサーション）
      • Authentication statements
      • Other statements
↑

Assertion、Subject、Statementの構造 †

  • 単一のAuthentication statementを含むAssertionの例を含むXMLフラグメント 
     1: <saml:Assertion
 2:   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
 3:   Version="2.0" IssueInstant="2005-01-31T12:00:00Z">
 4:   <saml:Issuer Format=urn:oasis:names:SAML:2.0:nameid-format:entity>> ... Nature of the assertion.
 5:     http://idp.example.org
 6:   </saml:Issuer>
 7:   <saml:Subject> ... Subject of the assertion.
 8:     <saml:NameID
 9:       Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
10:       j.doe@example.com
11:     </saml:NameID>
12:   </saml:Subject>
13:   <saml:Conditions ... Additional conditions of period.
14:     NotBefore="2005-01-31T12:00:00Z"
15:     NotOnOrAfter="2005-01-31T12:10:00Z">
16:   </saml:Conditions>
17:   <saml:AuthnStatement ... Authentication statement
18:     AuthnInstant="2005-01-31T12:00:00Z" SessionIndex="67775277772">
19:     <saml:AuthnContext>
20:       <saml:AuthnContextClassRef>
21:         urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
22:       </saml:AuthnContextClassRef>
23:     </saml:AuthnContext>
24:   </saml:AuthnStatement>
25: </saml:Assertion>
↑

Attribute statementsの構造 †

  • SAMLの属性構造は、特定のタイプの
    • データストア
    • データタイプ

が属性に使用されているとは想定していない。

  • 注意
    • 単一のステートメントに複数の属性を含めることができる。
    • 属性名は、属性名を解釈するか名前形式で修飾される。 
       1: <saml:AttributeStatement>
 2:   <saml:Attribute ... SAML X.500 / LDAP属性プロファイル
 3:     xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
 4:     NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
 5:     Name="urn:oid:2.5.4.42" FriendlyName="givenName">
 6:     <saml:AttributeValue xsi:type="xs:string" x500:Encoding="LDAP">
 7:       John
 8:     </saml:AttributeValue>
 9:   </saml:Attribute>
10:   <saml:Attribute
11:     NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"
12:     Name="LastName">
13:     <saml:AttributeValue xsi:type="xs:string">
14:       Doe
15:     </saml:AttributeValue>
16:   </saml:Attribute>
17:   <saml:Attribute
18:     NameFormat="http://smithco.com/attr-formats"
19:     Name="CreditLimit">
20:     xmlns:smithco="http://www.smithco.com/smithco-schema.xsd"
21:     <saml:AttributeValue xsi:type="smithco:type">
22:       <smithco:amount currency="USD">500.00</smithco:amount>
23:     </saml:AttributeValue>
24:   </saml:Attribute>
25: </saml:AttributeStatement>
↑

Message構造とSOAP Binding †

  • SAMLパーティがSOAP対応である環境では、
    SOAP Bindingを使用してSAML要求/応答プロトコルメッセージを交換できる。
  • HTTP Response
    • SOAP envlope
      • SOAP ヘッダ
      • SOAP ボディ
        SAMLリクエスト
        or SAMLレスポンス
  • 例
    • Attribute Query in SOAP Envelope 
       1: <?xml version="1.0" encoding="UTF-8"?>
 2: <env:Envelope
 3:   xmlns:env="http://www.w3.org/2003/05/soap/envelope/">
 4:   <env:Body>
 5:     <samlp:AttributeQuery
 6:       xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
 7:       xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
 8:       ID="aaf23196-1773-2113-474a-fe114412ab72"
 9:       Version="2.0" IssueInstant="2006-07-17T20:31:40Z">
10:       <saml:Issuer>
11:         http://example.sp.com
12:       </saml:Issuer>
13:       <saml:Subject>
14:         <saml:NameID
15:           Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName">
16:           C=US, O=NCSA-TEST, OU=User, CN=trscavo@uiuc.edu
17:         </saml:NameID>
18:       </saml:Subject>
19:       <saml:Attribute
20:         NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
21:         Name="urn:oid:2.5.4.42" FriendlyName="givenName">
22:       </saml:Attribute>
23:     </samlp:AttributeQuery>
24:   </env:Body>
25: </env:Envelope>
  • Response in SOAP Envelope 
     1: <?xml version="1.0" encoding="UTF-8"?>
 2: <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
 3:   <env:Body>
 4:     <samlp:Response
 5:       xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
 6:       xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
 7:       ID="i92f8b5230dc04d73e93095719d191915fdc67d5e"
 8:       Version="2.0" IssueInstant="2006-07-17T20:31:41Z"
 9:       InResponseTo="aaf23196-1773-2113-474a-fe114412ab72 "> ... 応答先の要求を参照
10:       <saml:Issuer>
11:         http://idp.example.org
12:       </saml:Issuer>
13:       <samlp:Status>
14:         <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
15:       </samlp:Status>
16:       ...SAML assertion...
17:     </samlp:Response>
18:   </env:Body>
19: </env:Envelope>
↑

プライバシー †

情報技術の文脈では、プライバシは一般に、

  • 自分のIDデータがどのように共有され使用されるかを制御するユーザの能力
  • 複数のSPでの彼らの行動が不適切に関連付けられるのを妨げるメカニズム

の両方を指す。

↑

ユーザの能力 †

  • IDデータの共有を制御するユーザの能力必要になる。
  • この同意がどのように、行われるかは、SAMLの範囲外。
  • SAMLは、IDデータの共有を制御するため、以下をサポートする。
    • Authentication Contextにより十分な保証レベルでユーザを認証できる。
    • 特定の操作に同意したユーザのクレームをプロバイダ間で表現する。
↑

メカニズム †

仮名の確立をサポート

↑

セキュリティ †

↑

公開鍵基盤（PKI）に依存する信頼関係を推奨 †

↑

HTTP over SSL 3.0またはTLS 1.0を推奨 †

↑

主要ProfileとFederationのUseCase? †

↑

Web Browser SSO Profile †

使用される可能性が高い典型的なフローで、主に2つのオプションがある。

  • 1つ目はフローがSP開始またはIdP開始のどちらであるか
  • SP開始：SPで開始されるWeb SSOモデル
    • ユーザはSPにログインしていないため、リソースへのアクセスを許可する前に、 SPはユーザをIdPに送信する。
    • IdPでユーザを認証し、IdPは、アサーションを作成し、アサーションをSPに送り返す。
    • SPは、アサーションを検証し、ユーザにリソースへのアクセスを許可するかどうかを決定。
  • IdP開始：IdPで開始されるWeb SSOモデル
    • ユーザは既に認証されていて、IdP上のSPへのリンクをクリック。
    • IdPはアサーションを作成し、、アサーションをSPに送信。
    • SPは、アサーションを検証し、ユーザにリソースへのアクセスを許可するかどうかを決定。
  • 2つ目はIdPとSP間のメッセージ配信に使用されるバインディング
  • Authentication Request message
    • HTTP Redirect Binding
    • HTTP POST Binding
    • HTTP Artifact Binding
  • Authentication Response message
    • HTTP POST Binding
    • HTTP Artifact Binding
↑

SP-Initiated SSO: Redirect/POST Bindings †

SP-Initiated SSO

  • Authentication Request message
    HTTP Redirect Bindingでリクエスト
  • HTTP Redirect 
    https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=value
  • Response 
    HTTP/1.1 302 Found
Location: https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request&RelayState=value
  • Request 
    GET /SAML2/SSO/Redirect?SAMLRequest=request&RelayState=value HTTP/1.1
Host: idp.example.org
  • SAML Request 
    <samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_1" Version="2.0"
  IssueInstant="2004-12-05T09:21:59Z"
  AssertionConsumerServiceIndex="1">
  <saml:Issuer>
    https://sp.example.com/SAML2
  </saml:Issuer>
  <samlp:NameIDPolicy
    AllowCreate="true"
    Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>
  • Authentication Response message
    HTTP POST Bindingでレスポンス
  • HTML Form 
    <form method="post" action="https://sp.example.com/SAML2/SSO/POST" ...>
  <input type="hidden" name="SAMLResponse" value="response" />
  <input type="hidden" name="RelayState" value="value" />
  ...
  <input type="submit" value="Submit" />
</form>
  • HTTP POST 
    POST /SAML2/SSO/POST HTTP/1.1
Host: sp.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLResponse=response&RelayState=value
  • SAML Response 
    <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>
  • その後
    • SAML Responseのデジタル署名を検証
    • 内容を処理し、SPでのローカルログオンセキュリティコンテキストを作成
    • SPはRelayState?データによって、最初に要求されたリソースURLを呼び戻す。
    • アクセス検査が行われ、検査に合格すると、リソースがブラウザに返される。
↑

SP-Initiated SSO: POST/Artifact Bindings †

SP-Initiated SSO

  • Authentication Request message
    HTTP POST Bindingでリクエスト
  • HTML Form 
    <form method="post" action="https://idp.example.org/SAML2/SSO/POST" ...>
  <input type="hidden" name="SAMLRequest" value="request" />
  <input type="hidden" name="RelayState" value="value" />
  ...
  <input type="submit" value="Submit" />
</form>
  • HTTP POST 
    POST /SAML2/SSO/POST HTTP/1.1
Host: idp.example.org
Content-Type: application/x-www-form-urlencoded
Content-Length: nnn
SAMLRequest=request&RelayState=value
  • Authentication Response message
  • HTTP Redirect Bindingでレスポンス
  • HTTP Redirect
    Technical Overviewに記載なし。
  • HTTP Artifact Bindingでアサーションを取得
  • Artifact Resolve 
    <samlp:ArtifactResolve
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_2" Version="2.0" IssueInstant="2004-12-05T09:22:04Z"
  Destination="https://idp.example.org/SAML2/ArtifactResolution">
  <saml:Issuer>
    https://sp.example.com/SAML2
  </saml:Issuer>
  <!-- an ArtifactResolve message SHOULD be signed -->
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    ...
  </ds:Signature>
  <samlp:Artifact>
    artifact
  </samlp:Artifact>
</samlp:ArtifactResolve>
  • Artifact Response 
    <samlp:ArtifactResponse
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  ID="identifier_3" InResponseTo="identifier_2"
  Version="2.0" IssueInstant="2004-12-05T09:22:05Z">
  <!-- an ArtifactResponse message SHOULD be signed -->
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    ...
  </ds:Signature>
  <samlp:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
  <samlp:Response
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    ID="identifier_4" InResponseTo="identifier_1"
    Version="2.0" IssueInstant="2004-12-05T09:22:05Z"
    Destination="https://sp.example.com/SAML2/SSO/Artifact">
    <saml:Issuer>
      https://idp.example.org/SAML2
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
      ...
    </ds:Signature>
    <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_5" Version="2.0"
      IssueInstant="2004-12-05T09:22:05Z">
      <saml:Issuer>
         https://idp.example.org/SAML2
      </saml:Issuer>
      <!-- a Subject element is required -->
      <saml:Subject>
        <saml:NameID
          Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
          user@mail.example.org
        </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/Artifact"
             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_5">
        <saml:AuthnContext>
          <saml:AuthnContextClassRef>
            urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
          </saml:AuthnContextClassRef>
        </saml:AuthnContext>
      </saml:AuthnStatement>
    </saml:Assertion>
  </samlp:Response>
</samlp:ArtifactResponse>
  • その後
    • Artifact Responseのデジタル署名を検証
    • 内容を処理し、SPでのローカルログオンセキュリティコンテキストを作成
    • SPはRelayState?データによって、最初に要求されたリソースURLを呼び戻す。
    • アクセス検査が行われ、検査に合格すると、リソースがブラウザに返される。
↑

IdP-Initiated SSO: POST Binding †

もともとSAML v1でサポートされていたIdP-Initiated SSOユースケースを引き続きサポート

  • Authentication Request message
    N/A
  • Authentication Response message
    HTTP POST Bindingでレスポンス（リクエストはないが）
↑

ECP Profile †

Enhanced Client and Proxy（ECP）プロファイル

  • 特別な機能を持たない市販のブラウザで動作する、
    • 拡張クライアントデバイス
    • ゲートウェイ・プロキシ

を考慮に入れたプロファイル

※ 昔の携帯電話（ガラケー）など機能の貧弱なDEVICEを想定して
　作成された仕様であるため、昨今はあまり使われないと思う。

↑

ECP Profile Using PAOS Binding †

PAOS（Reverse SOAP）という単一のバインディングを定義

  • SOAPヘッダとSOAPボディを使用
  • SAML Request、ResponseをすべてSOAPで処理する。
  • これらの処理は、SP、IdP、ゲートウェイ・プロキシが協調して行う。
↑

Single Logout Profile †

  • SAMLのシングルログアウトのプロファイル
  • シングルログアウト ≒ Oneアクションで複数のSP & IdPからログアウト出来る的な。
  • 1つのSPで開始され、IdPのSingle Logout Serviceから各SPのSingle Logout Serviceに要求が送信される。
↑

SP-Initiated Single Logout with Multiple SPs †

  • シングルログアウトのメッセージは以下のBindingを使用できる。
  • Synchronous？
    • SOAP over HTTP binding
  • Asynchronous？
    • HTTP Redirect bindings
    • HTTP POST bindings
    • HTTP Artifact bindings
  • Cookie認証チケットを削除する場合、 ブラウザをSPにリダイレクトする必要がある。
    • だったら、最初からHTTP Redirect bindingsを使えと言う気もするが、
    • そもそも、SOAP over HTTP bindingの場合、どうやって処理するのか？
↑

Establishing and Managing Federated Identities †

Federated Identitiesを確立・管理するSAMLメカニズムの説明（フェデレーションスタイル）

↑

Federation Using Out-of-Band Account Linking †

実名

  • SAML1.0でサポートされている唯一のスタイル（SAML2.0でも引き続きサポート）。
  • SAML仕様の外でアカウント同期が行われる（Hybrid-IdP の Azure AD Connectみたいな）。
↑

Federation Using Persistent Pseudonym Identifiers †

永続的な仮名

  • IdPは、永続的なSAML名識別子を使用して、SPのローカルIDと関連付ける。
  • SAML2.0では、AuthnRequest?にNameIDPolicy要素を提供して、SPの動的動作を強制できる。
  • 以下の様なスキーマになるらしい（linked IDで、SP / Idp間のlocal IDを紐付ける）
    #SP1IdP1
    local IDIdPlinked IDlocal IDSPlinked ID
    1XXXIdP1111<->AAASP1111
  • （初回時）動的動作で、ユーザーは、
    • SPでローカルの資格情報を提供するよう求められる。
    • ２つのアカウントを統合したいかどうかを尋ねられる。
↑

Federation Using Transient Pseudonym Identifiers †

一時的な仮名

  • 一時的な仮名識別子を使用して、SSOセッションの存続期間中にSPのローカルIDと関連付ける。
  • 以下の様なスキーマになるらしい（SP側が一時的な仮名識別子を使用）
    #SP1IdP1
    local IDIdPlinked IDlocal IDSPlinked ID
    1N/AIdP1111<->AAASP1111
  • 連携される属性
    • 基本、メンバーシップレベル属性のみで匿名ユーザとして処理できる。
    • 必要に応じて、SAML属性クエリを属性機関に送信し、ユーザーID属性を取得できる。
↑

Federation Termination †

既存のフェデレーションの終了。

↑

Use of Attributes †

SAMLアサーションによる、属性転送機能と、その属性の使い方。

↑

プロファイル情報の転送 †

IdPからSPへユーザプロファイル情報を伝達して使用する。

↑

属性に基づく承認 †

  • メンバーシップレベル属性のみで匿名ユーザとして処理できる。
  • IdPとSPは、属性名と値に関する事前の合意を必要とする。
↑

詳細 †

↑

SAML Profiles †

↑

SAML Bindings †

↑

SAML Core †

↑

SAML Protocols †

↑

SAML Assertions †

↑

SAML Signature or Encryption †

↑

構築と展開の2つの概念 †

↑

SAML Metadata †

↑

Authentication Context †

↑

SAMLを実装する。 †

↑

以下、参考 †

↑

OASIS †

OASISは「SGML Open」として1993年、

主に「研修活動を通じたSGMLの採用促進を目的として」結成された、

SGMLツール業者の業界団体。

↑

SAML 1.0 †

  • SAMLのAssertionsのスキーマと要求／応答プロトコルを定めた仕様
  • SAMLをSOAPとHTTPにバインドする仕組みとSSOプロファイルの規定
  • SAMLのセキュリティ要件を考察したもの
  • SAMLの相互運用性を確保するために適合性要件をまとめたもの
↑

SAML 1.1 †

↑

SAML 2.0 †

http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip

↑

Reference †

↑

用語集 †

  • SAML仕様全体を通して使用される用語を規範的に定義
  • 可能な限り、用語は他のセキュリティ用語集で定義されている用語と一致させてある。
↑

適合要件 †

↑

セキュリティ考慮事項 †

SAMLのセキュリティとプライバシーの特性について分析/説明。

↑

Security †

http://www.oasis-open.org/committees/security/.

  • SAMLExecOvr?
    • エグゼクティブの概要
    • SAMLとその主な利点についてエグゼクティブレベルで簡単に説明（非規範的な文書）。
  • SAMLMDV1x
    SAML V1.x OASIS規格をサポートするSAMLエンティティ
    を記述するためのSAML V2.0メタデータ構成体の使用
  • SAMLMDExtQ
    クエリ要求者用のSAMLメタデータ拡張
  • SAMLProt3P
    • サードパーティの要求に対するSAMLプロトコルの拡張を定義
    • SAMLプロトコルの拡張意図された応答受信者以外のエンティティによる要求を容易にするため
  • SAMLX509Attr
    X.509認証ベースシステム用のSAML属性共有プロファイル
  • SAMLXPathAttr?
    属性名としてXPath URIを使用するためのSAML属性の使用をプロファイル
  • SAMLErrata
    • 正誤表
    • SAML準拠ソフトウェアの実装者によって使用される可能性のある解釈へのガイド
    • SAML V2.0規格の矛盾や不明確である点の解釈を明確化する。
↑

WSS †

http://www.oasis-open.org/committees/wss/

  • WSS
    Web Services Security: SOAP Message Security 1.1 (WS-Security 2004).
  • WSSSAML
    Web Services Security: SAML Token Profile 1.1. OASIS WSS-TC, February 2006.
↑

XML(W3C) †

  • XMLSig
  • XMLEnc
↑

Else †

↑

参考 †

↑

SAML XML.org †

SAML 公式サイト

↑

千歳科学技術大学 > 深町研究室 †

SAML2.0日本語情報

↑

医療分野共通認証基盤整備コンソーシアム †

  • SAML 実装仕様書 第 1.0 版
    https://www.keieiken.co.jp/medit/pdf/240423/7-data.pdf
    • 第Ⅰ編 概要、用語及び参考文献
    • 第Ⅱ編 フレームワーク（SAML）
    • 第Ⅲ編 機能仕様
    • 第Ⅳ編 実装規約
    • 第Ⅴ編 試験仕様
    • 第Ⅵ編 セキュリティとプライバシに関する考慮事項
↑

用語 †

#用語説明
1Principal
プリンシパル		ID が認証可能なSystem Entity（通常は、ユーザ）。
2Subject
主体		SAMLアサーションに含まれるプリンシパル
3Profile
プロファイル		いくつかの目的のひとつのルールの集合。
4System Entity
システムエンティティ		コンピュータ/ネットワークシステムのアクティブな要素。
5Provider
プロバイダ		IdPとSPの総称（System Entity）。
6Identity Provider(IdP)
アイデンティティプロバイダ		プリンシパルの ID 情報を作成、維持、及び管理し、他のサービスプロバイダに契約の範囲でプリンシパルの認証を提供するプロバイダ。
7Service Provider(SP)
サービスプロバイダ		プリンシパルまたは他のSystem Entityにサービスを提供するプロバイダ。
8Attribute Assertion
属性アサーション		Subjectの属性に関する情報を伝えるAssertion。
9Authentication Assertion
認証アサーション		Subjectに対して行われた認証に関する情報を伝達するアサーション。
10Authorization Decision Assertion
認可決定アサーション		Subjectに対して決定された認可に関する情報を伝達するアサーション。
11Security Assertion
セキュリティアサーション		セキュリティアーキテクチャのコンテキストで精査されたアサーション。
12SAML Authority
SAML オーソリティ		Assertionを発行する抽象的なSystem Entity。
13Attribute Authority
属性オーソリティ		属性アサーションを生成するSystem Entity。
14Authentication Authority
認証オーソリティ		認証アサーションを生成するSystem Entity。
15Session Authority
セッションオーソリティ		セッションに関連する状態を保持しているSystem Entityの役割≒IdP。
16Party
当事者		1つ以上の不特定のプリンシパル。
17Asserting Party
アサーティングパーティ		形式的には、一つ以上の SAML オーソリティをホストする管理ドメイン。非公式には、そのインスタンス。
18Relying Party(RP)
当事者		別のSystem Entityからの情報に基づいて動作が決まるSystem Entity。
19Policy Enforcement Point(PEP)
ポリシー実行点		PDP に認可決定要求を送信し、応答で送信される認可決定アサーションを受け付ける。
20Policy Decision Point(PDP)
ポリシー決定点		PEP から認可決定要求を受け付けて、応答の認可決定アサーションを生成する。
21SAML Requestor
SAMLリクエスタ		サービス要求のために SAML プロトコルを利用するSystem Entity
22SAML Responder
SAMLレスポンダ		サービス要求に応答するために SAML プロトコルを利用するSystem Entity
23SAML Artifact
SAMLアーティファクト		固定サイズの構造化されたデータオブジェクトで間接参照して SAML プロトコルメッセージを取得する
24Front Channel
フロントチャンネル		UAなどの仲介者を経由するエンドポイント
25Back Channel
バックチャネル		UAなどの仲介者を経由しないエンドポイント
↑

機能概要 †

  • ユーザはUA（ブラウザ）を使用して、SP に対してリソース要求を送信する。
  • SP は、認証されていないユーザからのリソース要求の場合、
    SP に対する<AuthnReq?>のRedirect要求をユーザのUAに返却する。
  • ユーザのUAは、SSLで IdPにRedirect要求の<AuthnReq?>を転送。
  • IdP は、ユーザを認証して認証アサーションを作成、
    認証アサーションのArtifactのRedirect要求をユーザのUAに返却する。
  • ユーザのUAは、Redirect要求のArtifactを SP に転送する。
  • SP は、IdP に対して<ArtifactResolve?>でArtifactを提示して認証アサーションを要求。
  • IdP は、SP に対して<ArtifactResponse?>で認証アサーションを応答する。
↑

通信フローの概要 †

↑

OSSTech †

↑

OpenSSO社内勉強会第二回 - SAML - †

https://www.osstech.co.jp/_media/techinfo/opensso/osstech-opensso-study-02-saml.pdf

↑

概要 †

  • SAMLとは
    • 認証情報の送受信の方法を規定する
      • フォーマット（XML）
      • 通信プロトコル
  • 仕様の原文
    http://www.oasis-open.org/specs/index.php から入手可能
    • saml-core-2.0-os.pdf
    • saml-bindings-2.0-os.pdf
    • saml-profiles-2.0-os.pdf
    • saml-authn-context-2.0-os.pdf
    • saml-metadata-2.0-os.pdf
    • saml-conformance-2.0-os.pdf
    • saml-sec-consider-2.0-os.pdf
    • saml-glossary-2.0-os.pdf
  • SSO実現のための準備
    信頼の輪（Circle of Trust - Cot）の準備
    • CoT内のSPに対してのみSSO可能
    • IdP-SP間でお互いを事前に登録（CoTを構成）
    • 一つのCoT内に複数のIdPが存在することもある
  • アカウント連携
  • NameIDというユーザ識別子をIdPとSP間で共有
  • IdPのアカウントとSPのアカウントを紐付ける
  • NameIDには以下のものが使用される
    • メールアドレス
    • ユーザー名
    • ユーザID（GUIDなどの識別子）
    • 仮名：ランダムな文字列によるユーザ識別
    • X.509のSubject
  • アカウント・ライフサイクル
    サインイン・サインアウト < 連携・解除 < 作成・削除
  • SSOの開始
    • CoTの構成・アカウント連携が完了して、SSO可能に
    • OpenID Connect の Authorization Code Flow の Tokenリクエストが無い感じ。
↑

詳細 †

SAMLの構成要素

  • アサーション
    IdPが発行するXML形式のユーザに関する証明情報 
    <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" Version="2.0"
  ID="s2907181983bc6f588aeb045fca183d671224506ec" IssueInstant="2009-11-18T08:28:09Z">
  アサーション発行者
  アサーションのデジタル署名
  アサーションの利用条件
  ユーザ識別子(NameID)
</saml:Assertion>
  • プロトコル
  • 認証要求（AuthnRequest?）
    SPがIdPに対して、ユーザの認証情報を要求する 
    <samlp:AuthnRequest ID="xxx" Version="2.0" 
  Destination="http://idp.osstech.co.jp/idp/sso">
  認証要求情報が入る
</samlp:AuthnRequest>
  • 認証応答（Response）
    IdPがSPにユーザの認証情報を送付する 
    <samlp:Response ID="xxx" Version="2.0" 
  Destination="http://sp.osstech.co.jp/sp/sso">
  <saml:Assertion ...>
    アサーションが入る
  </saml:Assertion>
</samlp:AuthnRequest>
  • バインディング
    • メッセージを既存の通信プロトコルに埋め込む方法を規定
  • IdP-SP間の通信有無で分類すると...。
  • 有：HTTP Artifact
    アサーションがクライアントに渡ることがない、
    OpenID Connect の Authorization Code Flow の code みたいな
    ただ、SAML Responseだけでなく、SAML Requestにも使えるので、その辺りが異なる。
  • メタデータ
    • CoTの構成、アカウント連携に必要な情報
    • これによりIdP、SPの構築作業が楽になる
    • Google Apps のメタデータの例 
      <EntityDescriptor entityID="google.com" xmlns="urn:oasis:names:tc:SAML:2.0:metadata">
 <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
 <NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</NameIDFormat>
 <AssertionConsumerService index="1"
Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
 Location="https://www.google.com/a/ドメイン名/acs" />
 </SPSSODescriptor>
</EntityDescriptor>
↑

クラウド時代の シングルサインオン †

https://www.osstech.co.jp/_media/techinfo/seminar/hbstudy-20110416-sso.pdf

↑

概要 †

  • SAML : Secure Assertion Markup Lauguage
  • 認証、認可、ユーザ属性情報などをXMLで送受信するための仕様
  • Webアプリの”認証処理”を、外部で代行してもらうための仕組み。
↑

用語 †

  • SP/IdP
    • Identity Provider（IdP）
      • 認証・認可の情報を提供する役割を担う。
      • IdPで認証されたユーザーは SP のサービスにアクセスできるようになる。
    • Service Provider（SP）
      • シングルサインオン対象の Web アプリケーションなどを意味する。
      • IdP が発行した認証・認可の情報に応じてクライアントにサービスを提供する。
  • トラストサークル（Circle Of Trust）
    • IdP と SP の間で結ばれた信頼関係を意味する。
    • シングルサインオンを実現するためには、
      IdP と SP との間で事前に信頼関係を結んでおく必要がある。
    • IdP-SP 間で、お互いを事前に登録し、お互いの証明書を交換する。
    • 一つのトラストサークル内に複数の IdP が存在することもある

※同じ言葉でも、他のプロトコルでは意味が違うことがあるので注意

↑

シーケンス †

  • 認証シーケンス
    • SP-initiated SSO
      • ユーザーは最初にSPにアクセスし、IdPでの認証に成功した後に、再びSPにアクセスする。
      • SPがIdPにリクエストする際に、RelayState?というパラメタに遷移先情報を埋め込む。
  • IdP-initiated SSO
    • ユーザーは最初にIdPにアクセスし、IdPでの認証に成功した後にSPにアクセスする。
    • IdPがSPにアサーションをレスポンスする際に、RelayState?というパラメタに遷移先情報を埋め込む。
  • メッセージの送受信方法
  • HTTP Redirect / HTTP POST Binding
    • IdP-SP間の直接的な通信が発生しない
    • ブラウザが通信を中継する（HTTP Redirect/HTTP POST を利用）
  • HTTP Artifact Binding
    • アサーションへのリファレンスである Artifact をブラウザを介してIdPとSPの間で送受信する。
      IdPと SP は Artifact を利用して直接相手に SAML 認証要求/認証応答メッセージを問い合わせる。
    • IdP-SP間の直接的な通信が発生する。
    • Artifact のデータサイズは小さい。
  • リソース・アクセス
    リソースが格納されているuriを格納したRelayState?パラメタを使用してリダイレクトする。
↑

アサーション †

事前に IdP の証明書を SP に登録しておく必要がある（JWTみたいなもの）

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  Version="2.0"
  ID="s2907181983bc6f588aeb045fca183d671224506ec"
  IssueInstant="2009-11-18T08:28:09Z">
    アサーション発行者
    アサーションのデジタル署名
    ユーザー識別子(NameID)
</saml:Assertion>
↑

認証要求・認証応答 †

  • 認証要求（AuthnRequest?）
    SPがIdPに対して、ユーザーの認証情報（アサーション）を要求するメッセージ 
    <samlp:AuthnRequest ID="xxx" Version="2.0"
 Destination="http://idp.osstech.co.jp/idp/sso">
    認証要求情報
</samlp:AuthnRequest>
  • 認証応答（Response）
    IdPがSPにユーザーの認証情報（アサーション）を送付するメッセージ 
    <samlp:Response ID="xxx" Version="2.0"
 Destination"http://sp.osstech.co.jp/sp/sso">
    < saml:Assertion ...>
        アサーション
    </saml:Assertion>
</samlp:AuthnRequest>
↑

ネットワーク構成 †

  • IdPを社内LANに設置
    SPへのアクセスを社内のみからに制限することが可能
  • IdPをDMZに設置
    社外からSPにアクセスすることが可能
↑

OpenAMのSAML利用時の認証方式の指定について †

https://www.osstech.co.jp/_media/techinfo/openam/saml_authncontext_20150417.pdf

↑

認証方式の指定 †

<AuthnContextClassRef?>を使用する。

  • SPで、利用するIdPに認証方式を指定する。
  • SAML RequestのRequestedAuthnContex?を使用して指定する。
    • RequestedAuthnContex?は省略可能（多くのSPで使用していない）
    • SPはIdPに対してAuthentication Contextを通知できる。 
      <samlp:AuthnRequest
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  ID="XXXX" Version="2.0" IssueInstant="2015-04-13T04:59:38Z"
  Destination="xxxxxx" ForceAuthn="false" IsPassive="false"
  ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
  AssertionConsumerServiceURL="XXXXX">
  <samlp:RequestedAuthnContext
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="exact">
    <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
      urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    </saml:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
  • RequestedAuthnContext?の構成
  • <AuthnContextClassRef?>要素
    Authentication Context Classを一つ以上記述
  • Comparison属性
    Authentication Context Classの比較手法を指定
    （exact（既定値）、minimum、maximum、better）
  • IdPで、SPに実施した認証方式に応答する。
    • これにより、SPは、IdPでどのような認証が行われたか判断できる。
    • SAML ResponseのAssertionには必須(MUST)の要素 
      AuthnStatement -> AuthnContext -> AuthnContextClassRef
↑

OpenAMの実装を把握する †

  • OpenAMをSPとして構築した場合
  • SAML RequestのRequestedAuthnContex?にAuthentication Context Classを指定可能
    • 既定値では、PasswordProtectedTransport?を指定。
    • QueryString?でAuthnContextClassRef?を指定することもできる。
    • 「|」(パイプ)で区切ることで複数の<AuthnContextClassRef?>を指定することが可能
  • SAML ResponseとSAML RequestののAuthentication Context Classを比較
    • 指定したAuthentication Context Classとマッチしなかった場合はエラー
    • デフォルト設定ではPasswordProtectedTransport? のみ許容。
    • 許容しないAuthentication Context Classの場合も同様のエラー
  • OpenAMをIdPとして構築した場合
  • SAML RequestのAuthentication Context Classを、
    • 既定値は、PasswordProtectedTransport?として解釈。
    • デフォルト設定ではPasswordProtectedTransport? のみ許容
    • 許容しない値の場合はエラー
  • SAML ResponseのAuthentication Context Classは、
    Assertion -> AuthnStatement? -> AuthnContext? -> AuthnContextClassRef?に指定される。
↑

Cybozu †

↑

サイボウズエンジニアのブログ †

SAMLはSecurity Assertion Markup Languageの略で、OASIS3によって策定された、
異なるセキュリティドメイン間で、認証情報を連携するためのXMLベースの標準仕様。

↑

用語 †

  • 認証情報を提供する側を、Identity Provider（IdP）
  • 認証情報を利用する側を、Service Provider（SP）
↑

仕様 †

  • Core
    認証情報を表すXMLのスキーマ（Assertions）と、
    メッセージ交換のプロトコル（Protocols）を定義。
  • Bindings
    メッセージを実際の通信プロトコル（HTTPなど）にマッピングする方法を定義。
  • Profiles
    特定のユースケースを実現するための組み合わせ方を定義。
    • Assertions
    • Protocols
    • Bindings
  • Metadata
    IdPやSPに関する情報を表現するためのXMLのスキーマを定義（IdPとSPの信頼関係を構築）。
↑

シーケンス †

Web Browser SSO Profileのシーケンス

  • ユーザーがSPにアクセスする
  • ユーザーが未ログイン状態な場合、SPが認証要求メッセージを生成する
  • ユーザーがSPから認証要求メッセージを受け取り、それをIdPに送る
  • IdPが認証要求メッセージを受け取り、ユーザーを認証する
  • IdPが認証応答メッセージを作成する
  • ユーザーがIdPから認証応答メッセージを受け取り、それをSPに送る
  • SPが認証応答メッセージを受け取り、検証する（検証項目の一部）
    • Version属性の評価
    • Status要素の評価
    • SubjectConfirmation?要素のmethod属性の評価
    • SubjectConfirmationData?要素の内容の評価
    • Conditions要素の評価
    • AudienceRestriction?要素の評価
    • Assertion要素の署名の検証
  • メッセージの内容に問題がない場合、ユーザーはSPにログインできる
↑

要件 †

Web Browser SSO Profileの要件

  • IdPとの信頼関係の構築機能の設計
  • SPに信頼するIdPを登録する。
    • IdPが認証要求メッセージを受け取るURL
    • IdPが認証応答メッセージの署名の検証に使用する公開鍵
    • SPからログアウトした後に遷移するURL
      （IdPのログアウト用URLへのリダイレクト）
  • IdPが信頼するSPの登録
  • IdPの管理画面で手動で設定
    NameIDFormat要素
    AssertionConsumerService?要素
  • メッセージ処理機能の設計
  • 認証要求メッセージの作成
  • 認証要求メッセージをIdPに送る
    • HTTP Redirect Binding :
      Deflateエンコード -> Base64エンコード -> URLエンコード
    • HTTP POST Binding :
      Base64エンコード -> URLエンコード
  • IdPが発行した認証応答メッセージを受け取る
    • HTTP Redirect Binding :
      Deflateエンコード -> Base64エンコード -> URLエンコード
    • HTTP POST Binding :
      Base64エンコード -> URLエンコード
  • 認証応答メッセージを検証する
    • Version属性の評価
    • <Status>要素の評価
    • <SubjectConfirmation?>要素のmethod属性の評価
    • <SubjectConfirmationData?>要素の内容の評価
    • <Conditions>要素の評価
    • <AudienceRestriction?>要素の評価
    • <Assertion>要素の署名の検証
↑

cybozu.com ヘルプ †

↑

SP Initiated な Web Browser SSO Profile †

SAMLリクエストとSAMLレスポンスには、次のバインディングを使用する。

  • SAMLリクエスト：HTTP Redirect Binding
  • SAMLレスポンス：HTTP POST Binding
↑

フロー †

  • ユーザがSPにアクセスする。
  • SPがSAMLリクエストを生成する。
  • ユーザがSPからSAMLリクエストを受け取る。
  • IdPがユーザを認証する。
  • IdPがSAMLレスポンスを生成する。
  • ユーザがIdPからSAMLレスポンスを受け取る。
  • SPがSAMLレスポンスを受け取り、検証する。
  • SAMLレスポンスの内容に問題がない場合、
    ユーザがSPにログインした状態になる。
↑

設定 †

  • IdPにSPを登録する
  • 手入力する場合。
  • エンティティID URLの最後に"/"（スラッシュ）をつけないでください。
  • SPのエンドポイントURL
  • ユーザーを識別する要素：NameID
  • メタデータファイルを使用する場合。
    ...。
  • SPにIdPを登録する
  • SPでSAML認証を有効化し、
  • SPにIdPの情報を設定。
    • IdPのSSOエンドポイントURL（HTTP-Redirect）
    • SPからのログアウト後に遷移するIdPのURL
    • IdPが署名に使用する公開鍵の証明書
↑

Wikipedia †

↑

en †

↑

ja †

Tags: :IT国際標準, :認証基盤, :クレームベース認証, :SAML
トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-08-03 (月) 08:55:25 (1356d)