「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 汎用認証サイトにSAML2.0を実装するため仕様を読む。
- ターゲットはWeb Browser SSO Profileに絞る。
ロードマップ †
Technical Overview †
SAML2.0 の 技術概要
特定のユースケースを実現するための組み合わせ方を定義。
- セキュリティ情報を伝達するためのSAMLの豊富で柔軟な
構文を使用および制限するための一連の特定の規則を定義。
- 属性プロファイルの構文の側面をカバーするいくつかの関連する小さなスキーマ。
- SAMLアサーションと要求/応答プロトコル・メッセージを交換する方法を定義
- SAMLのメッセージを実際の通信プロトコル（HTTPなど）にマッピングする方法を定義。
- 認証、属性、許可情報を記述したプロトコル・メッセージを伝達する
XMLエンコードアサーションを作成するための構文とセマンティクス
- アサーション用とプロトコル用のスキーマを定義する。
- 認証情報を表す用のXMLのスキーマ（SAML Assertions）
- メッセージ交換のプロトコル用のXMLのスキーマ（SAML Protocols）
- SAMLパーティ間で設定情報を表現および共有するXMLのスキーマを定義
- SPがIdPを利用するための情報を記述して、IdPとSPの信頼関係を構築できる。
- エンティティのサポートされているSAMLバインディング
- 運用上の役割（IDP、SPなど）
- 識別子情報、サポートID属性
- および暗号化と署名のための鍵情報
- 認証メカニズムを記述する認証コンテキスト宣言を記述するための構文を定義
- 認証のタイプと強度に関する詳細な情報をSPが要求し、IdPは、これに応答する。
- 認証コンテキスト宣言を作成するためのメカニズムを定義する一般的なXMLスキーマ
- 一般的に使用されるSAMLの認証コンテキストクラスのセットがあります。
XML Signature Syntax and Processing †
XMLデジタル署名処理規則と構文
ユースケース †
参加者 †
- システム・エンティティ
システム・エンティティは、さまざまなSAMLロールで動作するが、
最低限、SAML交換は、以下のシステム・エンティティ間で行われる。
- アサーティング・パーティ（SAMLオーソリティ）
- SAMLアサーションを行うシステム・エンティティ
- ユーザもアサーティング・パーティの参加者である可能性がある。
- リライング・パーティ（RP）
受け取ったアサーションを使用するシステム・エンティティ
- リクエスタ / レスポンダ
- アサーティング・パーティとリライング・パーティは、SAMLリクエスタにもレスポンダにもなりうる。
- アサーティング・パーティの情報に依存するという回答側の意向は、アサーティング・パーティとの信頼関係に依存
- Identityプロバイダ（IdP）
≒ アサーティング・パーティ（SAMLオーソリティ）
- Serviceプロバイダ（SP）
≒ リライング・パーティ
- 属性機関の役割
アイデンティティ属性クエリに応答してSAMLエンティティがアサーションを生成
- サブジェクト≒プリンシパル
- 殆どのSAMLアサーションの中心にある対象
- 通常は人間、それ以外にも会社やコンピュータなどエンティティを表す。
Web-SSO †
- マルチドメインWebシングルサインオン
- SAMLが適用される最も重要なユースケース
IDフェデレーション †
- 考慮しなければならない多くの質問
- ユーザーは、既存のローカルIDをサイトに持っているか？
- ユーザーの連合IDの確立と終了は静的か？動的か？
- ユーザーは連合IDの確立に明示的に同意する必要があるか？
- ユーザーに関するID属性を交換する必要があるか？
- IDフェデレーションは、SessionIDなどの識別子に依存するべきか？
- 情報が暗号化されるべきか？交換される情報のプライバシーは大きな関心事か？
- 連合ID機能を強化するための2つの機能
- フェデレーション名識別子の動的確立と管理をサポートする、新しい構成とメッセージ
- プライバシー保護の特徴を持った2つの新しいタイプの名前識別子
- プロバイダー間のユーザー情報の維持および更新
- 追加のフローは必要のないケース。
- 追加のフローが必要になるケース。
SAML V2.0メッセージ交換の外部で行われるケース
- IdPにおけるデータソースによって駆動され、
- SPに伝播されるバッチまたはオフラインのIDフィードを利用
アカウントリンク †
- 連合IDをローカルIDと関連付けるプロセスは、アカウントリンクと呼ばれる。
- IdP検出機能を使用し、SPからIdPにアカウントリンクするかしないかをユーザに問う。
- ユーザが、フェデレーションに同意するとIdPにリダイレクトされる。
- IdPでSPのフェデレーション名識別子が生成され、IdP上のアカウントにリンクされる。
- IdPでSPは、後続のトランザクションでこの識別子を使用してユーザを参照する。
- IdPからSPにリダイレクトされた後、この識別子をSPのローカル・アカウントに関連付ける。
※ 追加のサイトとアカウントリンクする場合は、
新たにフェデレーション名識別子を生成し、上記手順を繰り返す。
アーキテクチャ †
基本概念 †
基本的なSAMLの概念 †
（プロファイル（バインディング（プロトコル（アサーション））））
・メタデータ
・認証コンテキスト
Assertions †
アサーティング・パーティが真実であると主張するプリンシパルに関する
ステートメントを伝えるXMLスキーマによって定義されたアサーション。
- リライング・パーティからの要求に基づいてアサーティング・パーティによって作成される。
- 特定の状況下では、アサーションは未承諾の方法でリライング・パーティに配信できる。
Protocols †
- SAMLのリクエスト / レスポンスを行うプロトコル。
- これにより、アサーションの入手や、IDマネジメントを行う。
Bindings †
参加者間でSAMLプロトコル・メッセージを転送するために下位レベルの
通信またはメッセージングプロトコル（HTTPまたはSOAPなど）を使用する方法
Profiles †
- WebブラウザSSOプロファイルなどの特定のユースケースを満たすように定義される。
- SAMLアサーション、プロトコル、およびバインディングの内容に対する制約を定義する。
- プロトコルメッセージやバインディングを参照しない属性プロファイルもある。
（X.500 / LDAP、DCEなどの一般的な使用環境と一致する方法でアサーションを使用）
構築と展開の2つの概念 †
- SAML Metadata
- Authentication Context
高度な概念 †
Subject Confirmation †
- Assertionsには、SubjectConfirmation?という要素を含めることができる。
- 実際的には、Subject Confirmationは...。
- Method属性に3つの値を定義することによって、
3つの異なるセキュリティシナリオに対応する。
- urn:oasis:names:tc:SAML:2.0:cm:bearer
所謂、一つの、持参人切符
- 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 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
- 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 XML構造と例 †
SAMLコンポーネントとの関係 †
Transport Protocol
- Transport Protocol ヘッダ
- Transport Protocol ペイロード
- レスポンス（アサーション）
- Authentication statements
- Other statements
Assertion、Subject、Statementの構造 †
- NameIDのフォーマット
- Email address
- X.509 subject name
- Windows domain qualified name
- Kerberos principal name
- Entity identifier
- Persistent identifier
- プライバシー保護仮名を使用する。
- 通常単一のSPでのみ使用するために確立される。
- 明示的に削除されるまでローカルIDと関連付けられたままになる。
- Name Identifier Mapping Protocolにより所属という概念に対するサポートも提供。
- Transient identifier
- プライバシー保護仮名を使用する。
- IdPで作成された使い捨て識別子に対応するため、SPでの匿名性をサポート。
- SPで特定のローカルIDと関連付けられておらず、セッションが終了すると破棄される。
Attribute statementsの構造 †
が属性に使用されているとは想定していない。
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>
プライバシー †
情報技術の文脈では、プライバシは一般に、
- 自分の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
- Response message
- HTTP POST Binding
- HTTP Artifact Binding
SP-Initiated SSO: Redirect/POST Bindings †
SP-Initiated SSO: POST/Artifact Bindings †
IdP-Initiated SSO: POST Binding †
ECP Profile †
概要 †
ECP Profile Using PAOS Binding †
Single Logout Profile †
概要 †
SP-Initiated Single Logout with Multiple SPs †
Establishing and Managing Federated Identities †
概要 †
Federation Using Out-of-Band Account Linking †
Federation Using Persistent Pseudonym Identifiers †
Federation Using Transient Pseudonym Identifiers †
Federation Termination †
Use of Attributes †
以下、参考 †
OASIS †
OASISは「SGML Open」として1993年、
主に「研修活動を通じたSGMLの採用促進を目的として」結成された、
SGMLツール業者の業界団体。
SAML 1.0 †
- SAMLのAssertionsのスキーマと要求／応答プロトコルを定めた仕様
- SAMLをSOAPとHTTPにバインドする仕組みとSSOプロファイルの規定
- SAMLの相互運用性を確保するために適合性要件をまとめたもの
SAML 1.1 †
SAML 2.0 †
http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip
- 以下を読むとイイらしい。
以下のQiitaを参考にすると、TechnicalOverview? をざっと眺めて、
どの Profile か選択してから Profile, binding, core と見ていくとイイらしい。
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) †
Else †
参考 †
SAML XML.org †
SAML 公式サイト
OSSTech †
OpenSSO社内勉強会第二回 - SAML - †
https://www.osstech.co.jp/_media/techinfo/opensso/osstech-opensso-study-02-saml.pdf
概要 †
- 仕様の原文
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の構成要素
- バインディング
- メッセージを既存の通信プロトコルに埋め込む方法を規定
- 有：HTTP Artifact
アサーションがクライアントに渡ることがない、
OpenID Connect の Authorization Code Flow の code みたいな
(ただ、IdPからSPへの通信があるようなので、コレが何かは別途確認が必要)
クラウド時代の シングルサインオン †
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>
認証要求・認証応答 †
ネットワーク構成 †
- IdPを社内LANに設置
SPへのアクセスを社内のみからに制限することが可能
- IdPをDMZに設置
社外からSPにアクセスすることが可能
OpenAMのSAML利用時の認証方式の指定について †
https://www.osstech.co.jp/_media/techinfo/openam/saml_authncontext_20150417.pdf
Cybozu †
SAML認証ができるまで Cybozu Inside Out サイボウズエンジニアのブログ †
http://developer.cybozu.co.jp/tech/?p=4224
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が認証応答メッセージを受け取り、検証する
- メッセージの内容に問題がない場合、ユーザーはSPにログインできる
要件 †
Web Browser SSO Profileの要件
- SPに信頼するIdPを登録する。
- IdPが認証要求メッセージを受け取るURL
- IdPが認証応答メッセージの署名の検証に使用する公開鍵
- SPからログアウトした後に遷移するURL
（IdPのログアウト用URLへのリダイレクト）
- IdPが信頼するSPの登録
IdPの管理画面で手動で設定するか、SPが提供するメタデータを読み込む。
- 管理画面で手動で設定
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>要素の署名の検証
SAML認証を使用したシングルサインオンを設定する - cybozu.com ヘルプ †
https://jp.cybozu.help/general/ja/admin/list_externalservices/list_saml/saml_settings.html
SP Initiated な Web Browser SSO Profile †
SAMLリクエストとSAMLレスポンスには、次のバインディングを使用する。
- SAMLリクエスト：HTTP Redirect Binding
- SAMLレスポンス：HTTP POST Binding
フロー †
- SAMLレスポンスの内容に問題がない場合、
ユーザがSPにログインした状態になる。
設定 †
- エンティティID
URLの最後に"/"（スラッシュ）をつけないでください。
- SPにIdPの情報を設定。
- IdPのSSOエンドポイントURL（HTTP-Redirect）
- SPからのログアウト後に遷移するIdPのURL
- IdPが署名に使用する公開鍵の証明書
Wikipedia †
en †
ja †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :SAML
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
