SAML

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

• 戻る
  • XML
  • SAML / WS-FED
  • トークン
  • クレームベース認証

目次 †

概要 †

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 Profiles †

SAML Bindings †

SAML Core †

• SAML Assertions
• SAML Protocols
• SAML Signature or Encryption

SAMLを実装する。 †

構築と展開の2つの概念 †

SAML Metadata †

Authentication Context †

参考 †

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

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

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

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

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

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

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

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

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

• アイデンティティ・メタシステムの実装コンポーネント／ライブラリ
  • 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

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

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

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

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

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

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

「認証」と「認可」 †

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

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

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

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

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

UXからの分類 †

• ポータル型
• 独立連携型

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