![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
Open棟梁Project - マイクロソフト系技術情報 Wiki -[[戻る>認証基盤]] * 目次 [#sdd6d82f] #contents *概要 [#x2c4c7d0] SAML標準の1つの目的は、異なるベンダのアクセス制御製品間の相互運用性を推進することである。 *参考 [#i4c7566b] **応用技術部会 セキュリティ WG 活動報告 - SAML の実装 [#j44bb186] https://hittel.hai.hitachi.co.jp/lpb/H0ZKYSC4020EventAction.do?H0ZKYSC40200001=event&uid=10032673.A -SAML protocolはSAML Assertionを獲得するための~ Request/Response型のメッセージプロトコルフォーマット **SAML認証ができるまで Cybozu Inside Out サイボウズエンジニアのブログ [#b96fa2da] http://developer.cybozu.co.jp/tech/?p=4224 SAMLはSecurity Assertion Markup Languageの略で、OASIS3によって策定された、~ 異なるセキュリティドメイン間で、認証情報を連携するためのXMLベースの標準仕様。 -用語 --認証情報を提供する側を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の信頼関係を構築）。 **Webサービスのセキュリティ [#ba75a9b0] （4）強力なSSOを実現するXML認証・認可サービス（SAML） ***(1-2) - ＠IT [#ycba6710] 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 [#h02d3e64] 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環境 [#p97d7909] ***第1回 クラウド・コンピューティングとアイデンティティ管理の概要 [#n9e8dd86] http://www.atmarkit.co.jp/fwin2k/operation/adsf2sso01/adsf2sso01_01.html ***第2回 クラウド・コンピューティング時代の認証技術~ [#q81a573b] 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：Security Token Service（クレーム発行・変換）~ 様々な認証技術への対応。 ---X.509 ---Kerberos ---・・・ --Security Token ---トークン識別子 ---クレーム ---電子署名 --SP(RP)：要求記述（クレーム）の提示。~ 様々なクレームに対応したライブラリ。 ---SAML ---NT？ ---・・・ --異種プロトコル間のネゴシエート ---WS-Security ---WS-MetadataExchange --Identity Selector~ 利用するSP(RP)が要求するクレームの種類によって利用可能なカードの種類を自動的に絞り込み、~ ユーザーが実際にどのカードを利用するか（どのIdPで認証され、どのようなクレームを提示するか）~ を選択させる。 ---要求に対応したクレームの取得 ---ユーザ同意に基づく提示 ***第3回 クラウド・サービスと社内ADとのSSOを実現する（前） [#nebceca9] http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso03/adfs2sso03_01.html ***第4回 クラウド・サービスと社内ADとのSSOを実現する（後） [#d9cd5c29] http://www.atmarkit.co.jp/fwin2k/operation/adfs2sso04/adfs2sso04_01.html **シングルサインオンの歴史とSAMLへの道のり [#pfbcbe1f] http://www.slideshare.net/shinichitomita/saml-34672223 ***「認証」と「認可」 [#y08c4ba3] どちらもシングルサインオンのエクスペリエンス。 -認証（Authentication）：「あなたは〇〇さんですね」~ 認証サーバで認証する。 -認可（Authorization）：「あなたは△△してもいいですよ」~ 認可情報を生成し、サーバー（アプリケーション）上で認可する。 --（署名なし）トークン形式 ---認可情報に紐付けられた割符のようなもの。 ---トークンを持っていればアクセス許可されている。 --アサーション形式 ---認可情報を文書として記述し、発行者の署名つきで渡す。 ---電子署名されているので、認可情報は改ざんできない。 ***UXからの分類 [#t33827b6] -ポータル型 -独立連携型
