SAML のバックアップ(No.21)

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

戻る

目次 †

↑

概要 †

2016年現在の最新版は2005年3月に策定されたSAML v2.0。

↑

経緯 †

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

同様の技術として
- Securant Technologies社が発表したAuthXML
- Netegrity社が発表したS2ML

という規格があり、SAML はこの二つの規格を統合したもの。

↑

目的 †

SAML標準の1つの目的
- 異なるベンダのアクセス制御製品間の相互運用性を推進すること。
- 異なるベンダ製品でサイト間でのSSOを実現することが難しい。
- しかし、SAML標準を実装したアクセス制御製品間では連携SSOが可能となる。

SAMLはクッキーを用いず、グローバルなSSOとより強力なセキュリティを可能にする。

企業間のそれぞれ独立したサービスをグローバルなSSOで連携させることが可能になる。

↑

詳細 †

↑

SAMLの仕様を読む。 †

↑

SAMLを実装する。 †

↑

参考 †

以下は、SAMLの雰囲気を知るために集めたリンク集。

↑

Webサービス技術解説 -　SAML技術解説 †

http://xmlconsortium.org/websv/kaisetsu/C10/content.html

↑

SAML概要 †

SAMLは、メッセージのトランスポートとして、HTTPとSOAPの両方が利用できます。

SAMLをHTTPやSOAPメッセージに付加することで、
一つの信用情報を持ち回りでき、シングルサインオンを実現しています。

今後のWebサービスに使われる重要な技術の一つとして注目されています。

↑

SAML用語 †

Use Case (シングルサインオン[Single Sign-On])
- Single Sign-on, Pull Model
- Single Sign-on, Push Model
- Single Sign-on, Third-Party Security Service

↑

SAMLアサーション †

SAMLアサーション要素のスキーマ
SAMLアサーションの構成と要素名

↑

SAMLプロトコル †

Protocol Binding and Profile Concepts

↑

＠IT Webサービスのセキュリティ †

（4）強力なSSOを実現するXML認証・認可サービス（SAML）

↑

(1-2) †

http://www.atmarkit.co.jp/ait/articles/0210/02/news002.html

従来SSOは、認証クッキーを使って実現してきた。
- クッキーは第三者が不正使用してなりすましを許す可能性がある。
- 認証クッキーは同じクッキードメイン内でのSSOに制限されている。

SAMLはクッキーを用いず、グローバルなSSOとより強力なセキュリティを可能にする。
- 企業間のそれぞれ独立したサービスをグローバルなSSOで連携させることが可能になる。

SAML標準の1つの目的
- 異なるベンダのアクセス制御製品間の相互運用性を推進すること。
- 異なるベンダ製品でサイト間でのSSOを実現することが難しい。
- しかし、SAML標準を実装したアクセス制御製品間では連携SSOが可能となる。

SAMLはセキュリティ情報交換のためのXMLベースのフレームワークであり、
要求と応答のプロトコルと応答に含まれるアサーションの構文仕様を定めたものである。

SAML用語

アサーション（Assertion）
アサーションとはSAMLオーソリティによって発行され、
対象とする主体の認証や属性あるいは資源に関する認可権限の証明。

オーソリティ（Authority）
- 認証オーソリティ、属性オーソリティ、ポリシー決定点の3つがある
- 問合せにその正当性を証明する応答（アサーション）を返すシステム・エンティティ。
- SSOを実現するだけなら、認証オーソリティを用いるだけでよい。

認証オーソリティ（Authentication Authority）
ユーザーの認証を証明するもので、CAの機能ではなく、
認証権限の許可を「認証アサーション」として返す。

属性オーソリティ（Attribute Authority）
ユーザーの登録された属性情報の証明を「属性アサーション」として返す。

ポリシー決定点（Policy Decision Point：PDP）
ポリシー実行点（Policy Enforcement Point：PEP）の要求に対して
ユーザーのPolicyに従ったアクセス制御の権限が何であるかの証明を
「認可決定アサーション」として返す。

ポリシー実行点（Policy Enforcement Point：PEP）
PDPの証明に従ってアクセス制御を実行しその結果を返すところ。

PullモデルとPushモデル（SSOの2つのモデル）
- Pullモデル
  アクセス要求を受けたサイトが主体の認証情報をオーソリティに問い合わせる。
- Pushモデル
  オーソリティがユーザーの認証情報を事前にアクセス要求を受けるサイトに知らせておく。

認可
- Webユーザーはアクセス制御を実行するWebサイトのPEPへアクセスを要求する。
- PEPはPDPに問い合わせ、Webユーザーのアクセス権限をチェックし、資源へのアクセス制御を実行する。

SAMLのモデル
- 要求者の問い合わせに対するSAMLオーソリティの対応（アサーションの提供）
  - 認証オーソリティは認証情報の再利用（SSO）を可能にする「認証アサーション」を提供する
  - 属性オーソリティはポリシーに定めた資格や役職などの「属性アサーション」を提供する
  - 認可決定オーソリティはポリシーで定めた規則に従った「認可決定アサーション」を提供する

アサーションの提供を受けた要求者の行動
- 本人性（Identity）を認証し、指定したWebサイトにアクセスさせる
- 本人の資格属性によって特定のページへのアクセスを許可する
- 本人の認可権限によって特定の資源へのアクセス（読み、書き、実行など）をさせる

手順
- ・・・

SAMLの利用例

SSO
- SSO Pullモデル
- SSO Pushモデル

認可サービス
- 認可モデル

↑

(2-2) †

http://www.atmarkit.co.jp/ait/articles/0210/02/news002_2.html

SAMLプロトコルとSAMLアサーション

SAML要求プロトコル<Request>
- 認証問い合わせ要求<AuthenticationQuery?>
- 属性問い合わせ要求<AttributeQuery?>
- 認可決定問い合わせ要求<AuthorizationDecisionQuery?>

SAML応答プロトコル<Response>
- 認証<AuthenticationQuery?>→<AuthenticationStatement?>
- 属性<AttributeQuery?>→<AttributeStatement?>
- 認可決定<AuthorizationQuery?>→<AuthorizationStatement?>

SOAPバインディングとプロファイル
- SAML仕様は下位のトランスポートプロトコルとして特定のプロトコルを想定していないが、
- SAML over SOAP over HTTPを必須のプロトコルバインディング（ヘッダ情報）としてしている。
- （ただし、over HTTPということは、トランスポートプロトコルは通常、TCP/IPになる）

SAMLをSOAPにバインドする際の基本的方針は以下のとおりである。
- SOAPバインディングではSOAPのHeaderは使わず、Body内にSAMLプロトコルを記述する。
- 1つのSOAPメッセージにはSAML<Request>は1つだけにする。
- 1つのSOAPメッセージにはSAML<Response>は1つだけにする。

SAML SSOプロファイル
ブラウザベースのSAMLプロファイルとして、
ブラウザ／artifactプロファイルとブラウザ／POSTプロファイルを定めている。

ブラウザ／artifactプロファイル
Pullモデルに相当する。

ブラウザ／POSTプロファイル
・・・

↑

Windowsで構築する、クラウド・サービスと社内システムのSSO環境 †

↑

第1回クラウド・コンピューティングとアイデンティティ管理の概要 †

http://www.atmarkit.co.jp/fwin2k/operation/adsf2sso01/adsf2sso01_01.html

クラウド・サービスを企業で利用するうえでの課題之一つ→「セキュリティが不安である。」

新たに必要なセキュリティ対策
- セキュリティ境界となる層（防御手段）
- 伝送経路に対する警戒度合い
- 認証（信頼）対象
  「アイデンティティ情報」を管理する「アイデンティティ管理」の役割がより重要なものとなってくる。
  - アプリケーション層における強固な認証
  - ネットワーク上を流れる重要データの極小化
  - ユーザーに加えてサービスの認証（正当性確認）

↑

第2回クラウド・コンピューティング時代の認証技術 †

http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso02/adfs2sso02_01.html

フェデレーション（SAML）で使われる重要な用語

#	用語	意味／役割	備考
1	サブジェクト	サービスを利用する主体（ユーザーなど）
2	アイデンティティ・プロバイダ（IdP）	認証を行い、アイデンティティ情報を提供する	OpenIDではOpenID Provider（OP）と呼ばれる
3	サービス・プロバイダ（SP）	IdPに認証を委託し、IdPによる認証情報を信頼してサブジェクトにサービスを提供する	リライング・パーティ（RP）とも呼ばれる
4	Assertion（アサーション）	IdPが本人性を証明するために発行する文書。属性やアクセス権情報などを含むこともある	Assertionに含まれる属性情報をクレーム（要求）と呼ぶこともある
5	Assertion Consumer Service（ACS）	SP内でAssertionの解釈、認可を行う

アイデンティティ・メタシステム

IdP内のSTS（Security Token Service）がクレームを発行・変換
様々な認証技術への対応。
- X.509
- Kerberos
- ・・・

Security Tokenがクレームをカプセル化
- トークン識別子
- クレーム
- 電子署名

SP(RP)実装のためのライブラリ。
提示される様々な要求記述（クレーム）に対応したライブラリ。
- Windows Identity Foundation（WIF）
- .etc

異種プロトコル間のネゴシエート
- WS-Security
- WS-MetadataExchange?

Identity Selector
リライング・パーティを使う場合はどのアイデンティティ・プロバイダを使うべきかを、ユーザー自身が管理する必要があった。
そのような煩わしさを解消しつつ統一されたユーザー・エクスペリエンスを提示するために、アイデンティティ・メタシステムでは認証行為をカード（Information Card）の提示、というメタファを使って表現している。
利用するSP(RP)が要求するクレームの種類によって利用可能なカードの種類を自動的に絞り込み、ユーザーが実際にどのカードを利用するか（どのIdPで認証され、どのようなクレームを提示するか）を選択させる。
これにより、ユーザーの同意の下でアイデンティティ情報を提示するという原則と、統一されたユーザー・エクスペリエンスという原則を同時に充足している。

要求に対応したクレームの取得
ユーザ同意に基づく提示

アイデンティティ・メタシステムの実装コンポーネント／ライブラリ
- ADFS(ADベースのアイデンティティ・プロバイダ)
- WIF:Windows Identity Foundation(SP(RP)実装のためのライブラリ)
- Windows CardSpace?(Identity Selector)

↑