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

SP/IdP
- Identity Provider（IdP）
  - 認証・認可の情報を提供する役割を担う。
  - IdPで認証されたユーザーは SP のサービスにアクセスできるようになる。
- Service Provider（SP）
  - シングルサインオン対象の Web アプリケーションなどを意味する。
  - IdP が発行した認証・認可の情報に応じてクライアントにサービスを提供する。

トラストサークル（Circle Of Trust）
- IdP と SP の間で結ばれた信頼関係を意味する。
- シングルサインオンを実現するためには、
  IdP と SP との間で事前に信頼関係を結んでおく必要がある。
- IdP-SP 間でお互いを事前に登録し、お互いの証明書を交換する。
- 一つのトラストサークル内に複数の IdP が存在することもある

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

アカウント連携
- IdP のアカウントと SP のアカウントを紐付ける
- NameID というユーザー識別子を IdP と SP 間で共有することで実現する
- NameID には以下のものが使用される
  - メールアドレス
  - ユーザー名
  - GUIDなどの識別子
  - X.509 の Subject

↑

シーケンス †

認証シーケンス
- SP-initiated SSO
  - ユーザーは最初にSPにアクセスし、IdPでの認証に成功した後に、再びSPにアクセスする。
- IdP-initiated SSO
  - ユーザーは最初にIdPにアクセスし、IdPでの認証に成功した後にSPにアクセスする。
  - SAML RelayState?というパラメタに遷移先情報を埋め込む。

メッセージの送受信方法
- HTTP Redirect/HTTP POST Binding
  - IdP-SP間の直接的な通信が発生しない
  - ブラウザが通信を中継する（HTTP Redirect/HTTP POST を利用）
- HTTP Artifact Binding
  - IdP-SP間の直接的な通信が発生する
  - アサーションへのリファレンスである Artifact をブラウザを介してIdPとSPの間で送受信する。
    IdPと SP は Artifact を利用して直接相手に SAML 認証要求/認証応答メッセージを問い合わせる。
  - Artifact のデータサイズは小さい。

↑

SAMLアサーション †

事前に 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>

↑

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

↑

SAML認証ができるまで Cybozu Inside Out サイボウズエンジニアのブログ †

http://developer.cybozu.co.jp/tech/?p=4224

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

↑

SAML用語 †

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

↑

SAMLの仕様 †

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の信頼関係を構築）。

↑

＠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の仕様
SAML 1.0（XML Security Assertion Markup Language）
http://www.oasis-open.org/committees/security/#documents

Assertions and Protocol［SAML Core］
http://www.oasis-open.org/committees/security/docs/cs-sstc-core-01.pdf
- SAMLのAssertionsのスキーマと要求／応答プロトコルを定めた仕様

Bindings and Profiles［SAML Bind］
http://www.oasis-open.org/committees/security/docs/cs-sstc-bindings-01.pdf
- SAMLをSOAPとHTTPにバインドする仕組みとSSOプロファイルの規定

Security and Privacy Considerations［SAML Sec］
http://www.oasis-open.org/committees/security/docs/cs-sstc-sec-consider-01.pdf
- SAMLのセキュリティ要件を考察したもの

Conformance Program Specification［SAML Conform］
http://www.oasis-open.org/committees/security/docs/cs-sstc-conform-01.pdf
- SAMLの相互運用性を確保するために適合性要件をまとめたもの

Glossary［SAML Gross］
http://www.oasis-open.org/committees/security/docs/cs-sstc-glossary-01.pdf

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）で使われる重要な用語

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

↑

第3回クラウド・サービスと社内ADとのSSOを実現する（前） †

http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso03/adfs2sso03_01.html

AD FS 2.0のセットアップ
Google AppsとAD FS 2.0との連携
Windows Live IDとAD FS 2.0との連携
Salesforce.com CRMとAD FS 2.0との連携

↑

第4回クラウド・サービスと社内ADとのSSOを実現する（後） †

http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso04/adfs2sso04_01.html

Windows AzureとAD FS 2.0との連携（1）
Windows AzureとAD FS 2.0との連携（2）

↑

シングルサインオンの歴史とSAMLへの道のり †

http://www.slideshare.net/shinichitomita/saml-34672223

↑

「認証」と「認可」 †

どちらもシングルサインオンのエクスペリエンス。

認証（Authentication）：「あなたは〇〇さんですね」
認証サーバで認証する。

認可（Authorization）：「あなたは△△してもいいですよ」
認可情報を生成し、サーバー（アプリケーション）上で認可する。

（署名なし）トークン形式
- 認可情報に紐付けられた割符のようなもの。
- トークンを持っていればアクセス許可されている。

アサーション形式
- 認可情報を文書として記述し、発行者の署名つきで渡す。
- 電子署名されているので、認可情報は改ざんできない。

↑

UXからの分類 †

ポータル型
独立連携型

Tags: :IT国際標準, :認証基盤, :クレームベース認証

目次 †

概要 †

参考 †

SAML 2.0 †

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

SAML概要 †

SAML用語 †

シーケンス †

SAMLアサーション †

認証要求・認証応答 †

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

SAML概要 †

SAML用語 †

SAMLアサーション †

SAMLプロトコル †

SAML認証ができるまで Cybozu Inside Out サイボウズエンジニアのブログ †

SAML用語 †

SAMLの仕様 †

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

(1-2) †

(2-2) †

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

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

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

第3回 クラウド・サービスと社内ADとのSSOを実現する（前） †

第4回 クラウド・サービスと社内ADとのSSOを実現する（後） †

シングルサインオンの歴史とSAMLへの道のり †

「認証」と「認可」 †

UXからの分類 †

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

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

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

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

第3回クラウド・サービスと社内ADとのSSOを実現する（前） †

第4回クラウド・サービスと社内ADとのSSOを実現する（後） †