Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
SAML標準の1つの目的は、異なるベンダのアクセス制御製品間の相互運用性を推進することである。
参考 †
応用技術部会 セキュリティ WG 活動報告 - SAML の実装 †
https://hittel.hai.hitachi.co.jp/lpb/H0ZKYSC4020EventAction.do?H0ZKYSC40200001=event&uid=10032673.A
- SAML protocolはSAML Assertionを獲得するための
Request/Response型のメッセージプロトコルフォーマット
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）
- SAML Core
認証情報を表すXMLのスキーマ（SAML Assertions）と、
メッセージ交換のプロトコル（SAML Protocols）を定義。
- SAML Bindings
SAMLのメッセージを実際の通信プロトコル（HTTPなど）に
マッピングする方法を定義。
- SAML Profiles
特定のユースケースを実現するための組み合わせ方を定義。
- SAML Assertions
- SAML Protocols
- SAML Bindings
- SAML Metadata
IdPやSPに関する情報を表現するためのXMLのスキーマを定義（IdPとSPの信頼関係を構築）。
Webサービスのセキュリティ †
（4）強力なSSOを実現するXML認証・認可サービス（SAML）
(1-2) - ＠IT †
http://www.atmarkit.co.jp/ait/articles/0210/02/news002.html
- 従来SSOは、認証クッキーを使って実現してきた。
- クッキーは第三者が不正使用してなりすましを許す可能性がある。
- 認証クッキーは同じクッキードメイン内でのSSOに制限されている。
- SAMLはクッキーを用いず、グローバルなSSOとより強力なセキュリティを可能にする。
- 企業間のそれぞれ独立したサービスをグローバルなSSOで連携させることが可能になる。
- SSO
2つのモデル（PullモデルとPushモデル）。
- Pullモデル
アクセス要求を受けたサイトが主体の認証情報をオーソリティに問い合わせる。
- Pushモデル
オーソリティがユーザーの認証情報を事前にアクセス要求を受けるサイトに知らせておく。
- 認可
- Webユーザーはアクセス制御を実行するWebサイトのPEPへアクセスを要求する。
- PEPはPDPに問い合わせ、Webユーザーのアクセス権限をチェックし、資源へのアクセス制御を実行する。
- 用語
- アサーション（Assertion）
アサーションとはSAMLオーソリティによって発行され、
対象とする主体の認証や属性あるいは資源に関する認可権限の証明。
- オーソリティ（Authority）
オーソリティ には認証オーソリティ、属性オーソリティ、ポリシー決定点の3つがあり、
問い合わせにその正当性を証明する応答（アサーション）を返すシステム・エンティティ。
SSOを実現するだけなら、認証オーソリティを用いるだけでよい。
- 認証オーソリティ（Authentication Authority）
ユーザーの認証を証明するもので、CAの機能ではなく、
認証権限の許可を「認証アサーション」として返す。
- 属性オーソリティ（Attribute Authority）
ユーザーの登録された属性情報の証明を「属性アサーション」として返す。
- ポリシー決定点（Policy Decision Point：PDP）
ポリシー実行点（Policy Enforcement Point：PEP）の要求に対して
ユーザーのPolicyに従ったアクセス制御の権限が何であるかの証明を「認可決定アサーション」として返す。
- ポリシー実行点（Policy Enforcement Point：PEP）
PDPの証明に従ってアクセス制御を実行しその結果を返すところ。
(2-2) - ＠IT †
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モデルに相当する。
Windowsで構築する、クラウド・サービスと社内システムのSSO環境 †
シングルサインオンの歴史とSAMLへの道のり †
http://www.slideshare.net/shinichitomita/saml-34672223
「認証」と「認可」 †
どちらもシングルサインオンのエクスペリエンス。
- 認証（Authentication）：「あなたは〇〇さんですね」
認証サーバで認証する。
- 認可（Authorization）：「あなたは△△してもいいですよ」
認可情報を生成し、サーバー（アプリケーション）上で認可する。
- （署名なし）トークン形式
- 認可情報に紐付けられた割符のようなもの。
- トークンを持っていればアクセス許可されている。
- アサーション形式
- 認可情報を文書として記述し、発行者の署名つきで渡す。
- 電子署名されているので、認可情報は改ざんできない。
UXからの分類 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
