ia20120118 nishimura

Post on 27-Jun-2015

933 Views

Category:

Documents

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

日本における学術認証フェデレーションと その役割と効果

○西村健† 中村 素典† 山地 一禎† 大谷 誠† 岡部 寿男‡ 曽根原 登† †国立情報学研究所 ‡京都大学

2012年1月18日 インターネットアーキテクチャ研究会

各種オンラインサービスを構築するための「場」を提供 仮想的な大規模;認証基盤の提供(連携)

大学の1つの認証基盤で全てのサービスが使える 様々な人が様々なサービスを提供できるようにする 厳密な認証を必要とするサービスもカバーする(HPCI,医療) サービス間でつながりを生む

認証基盤

3

想定する流れ(国際標準SAMLによる) ①SP(サービス提供者)による認証要求 ②IdP(認証基盤提供者)からの認証応答(認証データ=アサーション)

属性の送受信 利用者に関する情報(=属性)はIdPが持っておいて必要に応じて

SPに提供する SPは提供された属性を使って認可判断する

認可判断するために必要な属性=必須属性 IdPはSPに対してフィルタ定義してそれに従って属性送信を行う

IdP SP

認証基盤

①認証要求

②認証応答

認証アサーション 属性アサーション

SP SP

IdP IdP

4

IdPとSPの連合体をフェデレーションと呼ぶ SPによる認証要求の前にDS機能による所属IdP選択が追加される

メタデータにより強固な信頼関係を築く メタデータ: アサーションの署名検証のためのサーバ証明書など,

連携のためのIdP/SP固有の情報

IdP SP

DS

SAML

メタデータ

認証基盤 利用者 (ブラウザ)

所属IdP選択

5

フェデレーションポリシー 参加IdP/SP間で合意される 特に認証基盤のID集合は,フェデレーションにより規定される必要があり,そこで規定されているものをSPは期待する 研究教育目的のフェデレーションであれば学術関係者に限定する,大学の構成員に限定する,など

これがあることにより,SPは安心してIDを 受け入れられる

個々の大学のポリシー 属性送信に関しては個々の大学 のセキュリティポリシーの制約を 受ける

• 各大学の認証基盤は,各大学で必要なサービスを提供するために存在する • 例えば学内システムに名誉教授等がアクセスできる必要があるなら,認証基盤はそのアカウントを持つ必要がある

• 生涯IDに対応しているところでは大学OBが認証基盤に存在していたり

学内システム等の利用形態が要求する対象者

フェデレーションが規定し,参加するSPが期待する対

象者 ≠

7

フェデレーション構築における学術界でのデファクトスタンダードのソフトウェア SAMLを実装する IdPでの属性フィルタリング機能を実装済 メタデータを読み込み,フェデレーション参加の

IdP/SPを確実に識別する機能を持つ オープンソースソフトウェア

フェデレーション構築においてはShibbolethを用いるのが現実的

8

フェデレーションの信頼性が危うい 「フェデレーションの信頼性」にはいくつかの視点がある 利用者視点でのフェデレーションの信頼性

利用者はサービスを通してフェデレーションを見る 望まない個人情報のやりとりがないことへの信頼

→ 可視化とコントロール 所属IdPを選択(+認証)すればSPが利用できる,という信頼感

SP視点でのフェデレーションの信頼性 SPはIDの信頼性のみを見ている ポリシー+運用の確からしさ 例: 退職したIDが使用し続けられていないか? 第三者が含まれていないか?

プレゼンター
プレゼンテーションのノート
障害情報集約は?

Shibbolethにはフェデレーションの信頼性を落とす4つの 問題がある.

本研究の目的: これらの問題点を解決しフェデレーションの信頼性を向上させる ⇒ 学認:GakuNin

認証基盤内IDのポリシーとの不整合

IdP

IdP

SP

DS フェデレーション

IdP管理者

利用者

問題点4

やりとりされる属性情報が不明

問題点1 DSで接続不可のIdPが表示される問題

問題点2

オペレーションミスへの対策が不十分

問題点3

IdPがSPに送信する属性はIdP管理者が決定する SPはサービスに必要な属性をIdP管理者に要求する

利用者には送信属性を知るすべがない どういう情報が送られている? IdP管理者に問い合わせる? SP利用の度に個人情報が送信されているかも…

情報を視覚化すれば信頼感アップにつながる

情報が不足することによる

「不信感」

SP管理者から要求する属性, 「必須」「任意」の種別を収集(学認申請システムによる)

SPメタデータに「必須」「任意」の情報を追加

IdPに機能を追加し,SPメタデータから情報を取得,利用者に送信属性を表示・選択させる uApprove.jp IdPプラグイン

<md:AttributeConsumingService index="1"> <md:RequestedAttribute FriendlyName="mail" Name="urn:oid:0.9.2342.19200300.100.1.3" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> <md:RequestedAttribute FriendlyName="displayName" Name="urn:oid:2.16.840.1.113730.3.1.241" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"/> </md:AttributeConsumingService>

12

以下のような情報を収集・提供するシステムを構築した IdP管理者およびSP管理者が操作する サーバ証明書等,IdP/SPの基本情報 SPが要求する属性,必須/任意の別 etc.

収集した情報を元にメタデータ生成・配布を行なう

学認申請システム

IdP

IdP管理者

SP

SP管理者

メタデータ

出力

情報交換・共有のためのハブとなる

Shibbolethにはフェデレーションの信頼性を落とす4つの 問題がある.

本研究の目的: これらの問題点を解決しフェデレーションの信頼性を向上させる ⇒ 学認:GakuNin

認証基盤内IDのポリシーとの不整合

IdP

IdP

SP

DS フェデレーション

IdP管理者

利用者

問題点4

やりとりされる属性情報が不明

問題点1 DSで接続不可のIdPが表示される問題

問題点2

オペレーションミスへの対策が不十分

問題点3

14

学認に参加しているからといって全てのIdPから全てのSPが使えるわけではない 電子ジャーナルサービスの機関契約をし

ていないから 大学の判断で接続しないことを決定した IdPの属性フィルタ設定が完了していない etc.

しかしDSでは全てのIdPが表示される

→利用者視点では不信感を生む 「ちゃんとIdPで認証されたのに何で使え

ないの?」 「学認は使えない」「フェデレーションは使

えない」

学認申請システムで,IdP管理者から設定済みのSP一覧を情報収集

学認申請システムからの情報を元に,学認DS(Embedded DS)にて,アクセスしようとするSPに接続可能なIdPのみを取捨選択して一覧表示する

接続が保証されるIdPのみを表示することで利用者に安心感・信頼感を与える

DS

学認申請システム

IdP

IdP管理者

SP

接続可能 IdP一覧

利用者

Shibbolethにはフェデレーションの信頼性を落とす4つの 問題がある.

本研究の目的: これらの問題点を解決しフェデレーションの信頼性を向上させる ⇒ 学認:GakuNin

認証基盤内IDのポリシーとの不整合

IdP

IdP

SP

DS フェデレーション

IdP管理者

利用者

問題点4

やりとりされる属性情報が不明

問題点1 DSで接続不可のIdPが表示される問題

問題点2

オペレーションミスへの対策が不十分

問題点3

17

IdPが属性を送信するかどうかを決定するのはIdP管理者 個人情報を含む場合があるので慎重に行う必要がある

学認が規定する属性一覧(16種)

18

Shibboleth IdPでの属性送信設定はXMLファイルの修正で行う 本質的にはSP名・属性名のペアの羅列 IdP管理者が記述ミスすると情報漏洩につながる

<!-- Release attributes to Elsevier --> <AttributeFilterPolicy id="PolicyforElsevier"> <basic:Rule xsi:type="basic:AttributeRequesterString“ value="https://sdauth.sciencedirect.com/" /> <AttributeRule attributeID="eduPersonEntitlement"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> </AttributeFilterPolicy>

属性フィルタ設定ファイルの記述例:

学認申請システムが仲介してIdP向けの属性フィルタ設定ファイル生成 SP管理者はSPが要求する属性を選択して入力 IdP管理者は接続するSPを選択した上でフィルタ設定ファイル取得.Shibboleth IdPに設定.

学認申請システム

IdP

IdP管理者

SP

SP管理者 属性フィルタ設定ファイル

Shibbolethにはフェデレーションの信頼性を落とす4つの 問題がある.

本研究の目的: これらの問題点を解決しフェデレーションの信頼性を向上させる ⇒ 学認:GakuNin

認証基盤内IDのポリシーとの不整合

IdP

IdP

SP

DS フェデレーション

IdP管理者

利用者

問題点4

やりとりされる属性情報が不明

問題点1 DSで接続不可のIdPが表示される問題

問題点2

オペレーションミスへの対策が不十分

問題点3

21

大学の認証基盤に含まれるIDが,すべて学認のポリシーを満たしているとは限らない 大学が運用している学内システムに依存する 大学OB・名誉教授,共同研究者,委託業者…

具体例: 生涯ID対応 現在の学認のポリシーとして,

IdPで認証される者は機関の構成員等学術関係者に限られる

IdPが学認のポリシーを守っていることの保証ができない

学認利用不可のID集合が認証され認証情報がSPに送信されることを禁止するIdPプラグイン IDを区別するための情報は認証基盤に存在することが前提 SampleFilterPerSP IdPプラグイン

これにより認証基盤に規定外のIDが入っていても安心して学認に参加できる

学内システム利用可のID集合 学認利用可のID集合

大学OB 学生 教員 職員

SampleFilterPerSP

学認参加のSP

SP

SP

プレゼンター
プレゼンテーションのノート
SPでエラーにするのではなくIdPでエラーにする

フェデレーションの信頼性に関わる4つの問題を解決した. 1. 利用者が送信される属性を確認・選択できる仕組みを提供する

ことで,利用者がやりとりされる属性情報を見られず不安・不信になる問題を解決.

2. SPを利用できるIdP一覧を提供する仕組みを提供することで,DSで利用不可のIdPが選択できてしまい利用者を混乱させる問題を解決.

3. Shibboleth IdPのフィルタ設定を自動生成・取得できるようにすることにより,IdP管理者のオペレーションミスの問題の解決.

4. 認証基盤の一部ID集合について特定のSPへの接続許可/拒否をコントロールできるプラグインの提供により,学認のIDポリシーに準拠していることの保証が難しい問題を解決.

→ これによりフェデレーションの信頼性を向上できた SPに参加してもらえる,利用者に利用してもらえるフェデレーションの実現

プレゼンター
プレゼンテーションのノート
SP視点は1,利用者視点は2,3,4 理想像から出てくるのが1,2,3,現実との兼ね合いから出てくるのが4

より厳密な信頼性の確保・LoAの定義 個人ベース認証→グループベース認証の検討 SAML外・学認外の連携 よりグローバルなサービス フェデレーション間接続 プロトコル変換

non-web services

→より幅広いサービス空間をカバーする

top related