「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
汎用認証サイトにSAML2.0を実装するため仕様を読む。
- ターゲットはSP Initiated な Web Browser SSO Profileに絞る。
- ココに書いた情報は、SAML の Technical Overviewと他社コンテンツの情報の範囲。
ロードマップ †
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属性
- および暗号化と署名のための鍵情報
- 認証メカニズムを記述するAuthentication Context宣言を記述するための構文を定義
- 認証のタイプと強度に関する詳細な情報をSPが要求し、IdPは、これに応答する。
- Authentication Context宣言を作成するためのメカニズムを定義する一般的なXMLスキーマ
- 一般的に使用されるSAMLのAuthentication Contextクラスのセットがあります。
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つの新しいタイプの名前識別子
アカウントリンク †
連合IDをローカルIDと関連付けるプロセスは、アカウントリンクと呼ばれる。
- IdP検出機能を使用し、SPからIdPにアカウントリンクするかしないかをユーザに問う。
- ユーザが、フェデレーションに同意するとIdPにリダイレクトされる。
- IdPでSPのフェデレーション名識別子が生成され、IdP上のアカウントにリンクされる。
- IdPでSPは、後続のトランザクションでこの識別子を使用してユーザを参照する。
- IdPからSPにリダイレクトされた後、この識別子をSPのローカル・アカウントに関連付ける。
※ 追加のサイトとアカウントリンクする場合は、
新たにフェデレーション名識別子を生成し、上記手順を繰り返す。
アーキテクチャ †
基本概念 †
基本的なSAMLの概念 †
(Profile(Binding(Protocol(Assertion))))
・Metadata
・Authentication Context
アサーティング・パーティが真実であると主張するプリンシパルに関する
ステートメントを伝えるXMLスキーマによって定義されたアサーション。
- リライング・パーティからの要求に基づいてアサーティング・パーティによって作成される。
- 特定の状況下では、アサーションは未承諾の方法でリライング・パーティに配信できる。
- SAMLのリクエスト / レスポンスを行うプロトコル。
- これにより、アサーションの入手や、IDマネジメントを行う。
参加者間でSAMLプロトコル・メッセージを転送するために下位レベルの
通信またはメッセージングプロトコル(HTTPまたはSOAPなど)を使用する方法
- WebブラウザSSOプロファイルなどの特定のユースケースを満たすように定義される。
- SAMLアサーション、プロトコル、およびバインディングの内容に対する制約を定義する。
- プロトコルメッセージやバインディングを参照しない属性プロファイルもある。
(X.500 / LDAP、DCEなどの一般的な使用環境と一致する方法でアサーションを使用)
構築と展開の2つの概念 †
- Authentication Context#zdb546a9
Authentication Contextの例
# | Authentication Context | 説明 |
1 | urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified | 不特定の方法で認証したことを示す。 |
2 | urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport? | HTTPSでパスワードを提示して認証したことを示す(≒既定値) |
3 | urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport? | HTTPでパスワードを提示して認証したことを示す(推奨されない) |
4 | urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession? | セッション等を使用し、 ・すでに認証済みであること示す。 ・過去のある時点で認証したこと示す。 |
5 | urn:oasis:names:tc:SAML:2.0:ac:classes:X509 | デジタル署名により認証したことを示す。 |
高度な概念 †
- Assertionsには、SubjectConfirmation?という要素を含めることができる。
- 実際的には、Subject Confirmationは、
- Assertionの利用者が許可されている条件
- ≒ SPが検証を行うための手段を提供する。
- 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 †
通常、アサーションは以下から構成される。
- アサーションのsubject
- subject(主題)
- subjectが存在しない場合、他の方法で識別される。
例えばsubjectの確認に使用された証明書
- Authentication statements
- ユーザーを正常に認証した当事者によって作成される。
- 最低でも、認証に使用される特定の手段と認証が行われた特定の時間を説明。
- Attribute statements
- サブジェクトに関する特定の識別属性
- 例えば、ユーザー"John Doe"は"ゴールドカードステータス"を持つ。
- Authorization decision statements
- 対象がする権利があるものを定義する
- 例えば、ユーザー"John Doe"は"特定の品目を購入すること"が許可されている。
いくつかの一般化された要求/応答プロトコルを定義する。
- 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で使用できるユーザーの名前識別子を要求することを許可する。
トランスポート層上で、プロトコルメッセージをどのように伝達するか?
- 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アサーションを取得するための手段を定義
特定シナリオでアサーション、プロトコル、バインディングの組合せ(制約)を定義
- 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
EndPoint? †
この項目は、SAMLの公式資料にはないが、図を見ると、
EndPoint?には以下の様な名称が付与されている。
- SAML Requestを受けるEndPoint?
SSO Service
- SAML Responseを受けるEndPoint?
Assertion Consumer Service
- Artifact Requestを発行するEndPoint?
- SSO Service(RequestでArtifactを使用する場合)
- Assertion Consumer Service(ResponseでArtifactを使用する場合)
- Artifact Requestを受けるEndPoint?
Artifact Resolution Service
- SAML Requestを受けるEndPoint?
Single logout Service
- Logout Request/Responseを受けるEndPoint?
Single logout Service
- SAML Responseを受けるEndPoint?
Assertion Consumer Service
- 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の構造 †
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データの共有を制御するため、以下をサポートする。
メカニズム †
仮名の確立をサポート
セキュリティ †
公開鍵基盤(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でリクエスト
- Authentication Response message
HTTP POST Bindingでレスポンス
- その後
- SAML Responseのデジタル署名を検証
- 内容を処理し、SPでのローカルログオンセキュリティコンテキストを作成
- SPはRelayState?データによって、最初に要求されたリソースURLを呼び戻す。
- アクセス検査が行われ、検査に合格すると、リソースがブラウザに返される。
SP-Initiated SSO: POST/Artifact Bindings †
SP-Initiated SSO
- Authentication Request message
HTTP POST Bindingでリクエスト
- Authentication Response message
- HTTP Redirect Bindingでレスポンス
- HTTP Redirect
Technical Overviewに記載なし。
- HTTP Artifact Bindingでアサーションを取得
- その後
- 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を使用できる。
- 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を紐付ける)
# | SP1 | | IdP1 |
local ID | IdP | linked ID | | local ID | SP | linked ID |
1 | XXX | IdP1 | 111 | <-> | AAA | SP1 | 111 |
- (初回時)動的動作で、ユーザーは、
- SPでローカルの資格情報を提供するよう求められる。
- 2つのアカウントを統合したいかどうかを尋ねられる。
Federation Using Transient Pseudonym Identifiers †
一時的な仮名
- 一時的な仮名識別子を使用して、SSOセッションの存続期間中にSPのローカルIDと関連付ける。
- 以下の様なスキーマになるらしい(SP側が一時的な仮名識別子を使用)
# | SP1 | | IdP1 |
local ID | IdP | linked ID | | local ID | SP | linked ID |
1 | N/A | IdP1 | 111 | <-> | AAA | SP1 | 111 |
- 連携される属性
- 基本、メンバーシップレベル属性のみで匿名ユーザとして処理できる。
- 必要に応じて、SAML属性クエリを属性機関に送信し、ユーザーID属性を取得できる。
Federation Termination †
既存のフェデレーションの終了。
Use of Attributes †
SAMLアサーションによる、属性転送機能と、その属性の使い方。
プロファイル情報の転送 †
IdPからSPへユーザプロファイル情報を伝達して使用する。
属性に基づく承認 †
- メンバーシップレベル属性のみで匿名ユーザとして処理できる。
- IdPとSPは、属性名と値に関する事前の合意を必要とする。
詳細 †
構築と展開の2つの概念 †
以下、参考 †
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.
Else †
参考 †
SAML XML.org †
SAML 公式サイト
千歳科学技術大学 > 深町研究室 †
SAML2.0日本語情報
医療分野共通認証基盤整備コンソーシアム †
用語 †
# | 用語 | 説明 |
1 | Principal プリンシパル | ID が認証可能なSystem Entity(通常は、ユーザ)。 |
2 | Subject 主体 | SAMLアサーションに含まれるプリンシパル |
3 | Profile プロファイル | いくつかの目的のひとつのルールの集合。 |
4 | System Entity システムエンティティ | コンピュータ/ネットワークシステムのアクティブな要素。 |
5 | Provider プロバイダ | IdPとSPの総称(System Entity)。 |
6 | Identity Provider(IdP) アイデンティティプロバイダ | プリンシパルの ID 情報を作成、維持、及び管理し、他のサービスプロバイダに契約の範囲でプリンシパルの認証を提供するプロバイダ。 |
7 | Service Provider(SP) サービスプロバイダ | プリンシパルまたは他のSystem Entityにサービスを提供するプロバイダ。 |
8 | Attribute Assertion 属性アサーション | Subjectの属性に関する情報を伝えるAssertion。 |
9 | Authentication Assertion 認証アサーション | Subjectに対して行われた認証に関する情報を伝達するアサーション。 |
10 | Authorization Decision Assertion 認可決定アサーション | Subjectに対して決定された認可に関する情報を伝達するアサーション。 |
11 | Security Assertion セキュリティアサーション | セキュリティアーキテクチャのコンテキストで精査されたアサーション。 |
12 | SAML Authority SAML オーソリティ | Assertionを発行する抽象的なSystem Entity。 |
13 | Attribute Authority 属性オーソリティ | 属性アサーションを生成するSystem Entity。 |
14 | Authentication Authority 認証オーソリティ | 認証アサーションを生成するSystem Entity。 |
15 | Session Authority セッションオーソリティ | セッションに関連する状態を保持しているSystem Entityの役割≒IdP。 |
16 | Party 当事者 | 1つ以上の不特定のプリンシパル。 |
17 | Asserting Party アサーティングパーティ | 形式的には、一つ以上の SAML オーソリティをホストする管理ドメイン。非公式には、そのインスタンス。 |
18 | Relying Party(RP) 当事者 | 別のSystem Entityからの情報に基づいて動作が決まるSystem Entity。 |
19 | Policy Enforcement Point(PEP) ポリシー実行点 | PDP に認可決定要求を送信し、応答で送信される認可決定アサーションを受け付ける。 |
20 | Policy Decision Point(PDP) ポリシー決定点 | PEP から認可決定要求を受け付けて、応答の認可決定アサーションを生成する。 |
21 | SAML Requestor SAMLリクエスタ | サービス要求のために SAML プロトコルを利用するSystem Entity |
22 | SAML Responder SAMLレスポンダ | サービス要求に応答するために SAML プロトコルを利用するSystem Entity |
23 | SAML Artifact SAMLアーティファクト | 固定サイズの構造化されたデータオブジェクトで間接参照して SAML プロトコルメッセージを取得する |
24 | Front Channel フロントチャンネル | UAなどの仲介者を経由するエンドポイント |
25 | Back 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
概要 †
- 仕様の原文
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 みたいな
ただ、SAML Responseだけでなく、SAML Requestにも使えるので、その辺りが異なる。
クラウド時代の シングルサインオン †
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
認証方式の指定 †
<AuthnContextClassRef?>を使用する。
- SAML RequestのRequestedAuthnContex?を使用して指定する。
- RequestedAuthnContext?の構成
- <AuthnContextClassRef?>要素
Authentication Context Classを一つ以上記述
- Comparison属性
Authentication Context Classの比較手法を指定
(exact(既定値)、minimum、maximum、better)
OpenAMの実装を把握する †
- SAML RequestのRequestedAuthnContex?にAuthentication Context Classを指定可能
- 既定値では、PasswordProtectedTransport?を指定。
- QueryString?でAuthnContextClassRef?を指定することもできる。
- 「|」(パイプ)で区切ることで複数の<AuthnContextClassRef?>を指定することが可能
- SAML ResponseとSAML RequestののAuthentication Context Classを比較
- 指定したAuthentication Context Classとマッチしなかった場合はエラー
- デフォルト設定ではPasswordProtectedTransport? のみ許容。
- 許容しないAuthentication Context Classの場合も同様のエラー
- 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の要件
- SPに信頼するIdPを登録する。
- IdPが認証要求メッセージを受け取るURL
- IdPが認証応答メッセージの署名の検証に使用する公開鍵
- SPからログアウトした後に遷移するURL
(IdPのログアウト用URLへのリダイレクト)
- 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
フロー †
- SAMLレスポンスの内容に問題がない場合、
ユーザがSPにログインした状態になる。
設定 †
- エンティティID
URLの最後に"/"(スラッシュ)をつけないでください。
- SPにIdPの情報を設定。
- IdPのSSOエンドポイントURL(HTTP-Redirect)
- SPからのログアウト後に遷移するIdPのURL
- IdPが署名に使用する公開鍵の証明書
Wikipedia †
en †
ja †
Tags: :IT国際標準, :認証基盤, :クレームベース認証, :SAML