• 検索結果がありません。

多様なポリシーを反映可能な認証フェデレーション機構の実現

N/A
N/A
Protected

Academic year: 2021

シェア "多様なポリシーを反映可能な認証フェデレーション機構の実現"

Copied!
13
0
0

読み込み中.... (全文を見る)

全文

(1)

多様なポリシーを反映可能な認証フェデレーション機構の実現

西村 健

中村 素典

山地 一

佐藤 周行

††

大谷 誠

†††

岡部 寿男

††††

曽根原 登

An Identity Federation which can Reflect Diversity of Policies by Each Stakeholders Takeshi NISHIMURA

, Motonori NAKAMURA

, Kazutsuna YAMAJI

,

Hiroyuki SATO

††

, Makoto OTANI

†††

, Yasuo OKABE

††††

, and Noboru SONEHARA

あらまし Webベースのシングルサインオン認証技術を機関にまたがって活用する認証フェデレーションが,

世界的に広がりを見せている.特に学術分野においては,大学等の学術機関が提供する認証情報を電子ジャーナ ルやeラーニング等の各種学術サービスでの認可等に活用すべく,学術認証フェデレーションの構築と運用が国 を単位として進んでいる.異なる機関が提供する認証機構を利用するとともに,利用者に対応づく個人情報を利 用する分散サービスアーキテクチャであることから,相互に信頼させるための統一的なポリシーへの準拠が不可 欠であるが,その一方で,機関ごとのもつアクセス制御ポリシーやプライバシーポリシーの異なりに対応するこ との重要性を日本における学術認証フェデレーション「学認」の運用を通して強く認識した.そこで,我々は各 機関のアクセス制御ポリシーを細かく表現・反映する仕組みを提供するとともに,プライバシーポリシーの実現 において送信する情報に対して利用者が細かく指定可能な機構を開発した.これによって,それぞれのポリシー の違いに基づく柔軟な制御が可能な認証フェデレーションが実現された.

キーワード 認証フェデレーション,SAML,Shibboleth,プライバシー,セキュリティ

1.

ま え が き

大学等の機関では,研究・教育及びその支援を効果 的に行うためのオンラインサービスの提供を,それぞ れの機関ごとに独自に行っており,多くの場合,その 整備はサービスごとに個別に進められてきた.これら のサービスを提供するシステムは定期的に更新され,

更新の際にはより高い利便性を提供することが求めら れる

[1], [2]

が,その中の要素の一つとして認証機構が ある.まず,従来サービスごとに発行されていた異な るアカウントの使い分けの煩雑さを軽減するために認 証統合が実施され

[3]

,更に,異なるサービスの利用の

国立情報学研究所,東京都

National Institute of Informatics, 2–1–2 Hitotsubashi, Chiyoda-ku, Tokyo, 101–8430 Japan

††東京大学,東京都

The University of Tokyo, 7–3–1 Hongo, Bunkyo-ku, Tokyo, 113–0033 Japan

†††佐賀大学,佐賀市

Saga University, 1 Honjo-machi, Saga-shi, 840–8502 Japan

††††京都大学,京都市

Kyoto University, Yoshida-Honmachi, Sakyo-ku, Kyoto-shi, 606–8501 Japan

際に個別に要求されていた認証を最初の一度だけに集 約するシングルサインオン(

Single Sign-On

SSO

) 技術の導入が広まっている

[4]

SSO

技術は,利用者 の認証と,サービス提供可否の判断である認可を行う ポイントを分離するものである.認証はサービスにア クセスしようとしている者が誰であるかを識別する ことであり,認可は,認証された当該利用者に関する 情報(以下,属性と呼ぶ)から,その利用者に対して サービスを提供するか否かを決定することである.例 えば,認証を経た利用者のうち,学生であるという属 性が付与された利用者のみにサービスを提供するとい うことが考えられる.これらの技術により認証と認可 を分離し認証を

1

箇所に集約することで,利用者の利 便性の向上,アカウント管理コストの削減,システム 全体としてのセキュリティ対策レベルの底上げ等が期 待される.

認証・認可の分離においては,認証結果の共有にお ける信頼性の確保が不可欠となる.一つの機関に閉じ た

SSO

技術の導入では,信頼性の確保は容易である.

これを更にスケールアウトし,信頼関係の輪を組織の 枠を超えて構築することができれば,インターネット

(2)

上に展開される数多くのサービスを研究・教育のため に活用できる新たな道が開けると期待される.

このような可能性を現実のものとすべく,学術認証 フェデレーションが,世界的に広がりをみせており,欧 米を中心に,現在,

34

か国で学術認証フェデレーショ ンが運用されている

[5]

[9]

.認証のプロトコルとし ては,国際標準である

SAML [10]

が採用されている.

個々の学術機関は,認証サーバ(

Identity Provider:

IdP

)を提供し,サービス提供者(

Service Provider:

SP

)は,

IdP

での認証結果に基づいて,その学術機 関の構成員である利用者にサービスを提供する.

SP

は複数の大学に対してサービスを提供することから,

ユーザの所属機関となる

IdP

への接続には,

IdP

の 選択システム(

Discovery Service

DS

)が介在する.

IdP

から

SP

には,認証結果とともに利用者の属性が 送信され,属性は

SP

での認可に利用される.

日本では,

2008

年に

UPKI Federation

として国内 における学術認証フェデレーションの実証実験を開始 し,

2009

年の試行運用を経て,

2010

年より「学認:

GakuNin

」として実運用を開始している

[11], [12]

.学 認は

IdP

として日本の大学等学術機関を対象としてお り,

2013

1

月現在で既に

52

機関が参加している.

またサービスの数は商用のものも含めて

60

を超える.

学認では,実施要領

[13]

とシステム運用基準

[14]

と 呼ばれる

2

種類の参加要件(以下,まとめてフェデ レーションポリシーと呼ぶ)を参加機関が遵守するこ とで,認証を担当する

IdP

と認可とサービスを担当す る

SP

との間で機関の枠を越えた信頼関係を構築する.

しかしながら,これまで独自にシステム構築・運用を 行ってきた各機関では,それぞれで培ってきた運用ポ リシーをもち,それらは少しずつ異なる.したがって,

各機関にはフェデレーションポリシーを満たす範囲内 において自由度が与えられるとともに,満たされない 部分についてはポリシーの摺り合わせが必要となる.

IdP

運用者,

SP

運用者,利用者(以下,まとめて参 加者と呼ぶ)のそれぞれがもつ多様なポリシーに柔軟 に対応できるシステムを提供することが,認証フェデ レーションの基盤を効果的に拡大していくために求め られる.具体的には,次に示す

3

種類のポリシーの違 いに基づく運用上の問題が生じる.

(a) IdP/SP

が接 続する

SP/IdP

を制限する場合(ポリシーの違いの利 用者への提示が必要),

(b) IdP

においてフェデレー ションの参加条件を満たさない利用者アカウントが管 理されている場合(フェデレーションのポリシーへの

整合が必要),

(c) SP

が求める属性の中で任意とされ る情報の送信可否の判断を利用者に委ねる場合(利用 者によるポリシーの表現手段が必要).

しかしながら,従来より提供されているフェデレー ションを実現するための機能は,全ての参加機関が等 しく相互接続することを前提としているため,この前 提が満たされないことがあると,フェデレーションへ の参加や利用への障害となり得る.この問題を解決し,

参加者がもつ異なるポリシーを反映可能なカスタマイ ザビリティを備えることは,フェデレーションの発展 の加速に大きく寄与するものと考えられる.そこで,

日本国内におけるフェデレーションの展開に際し,そ れら三つの視点からのポリシーの違いを的確に反映可 能な認証フェデレーション機構を実現することを目的 として研究開発を行った.

本論文の構成は,以下のとおりである.

2.

で従来の フェデレーションにおける課題を指摘する.

3.

ではそ の問題を解決するための方策を提示し,

4.

にて学認に おける実装及びその結果を評価する.最後に,本研究 の成果をまとめるとともに,今後の検討課題について 述べる.

2.

フェデレーション及びその要素技術 本章では,まず,学術認証フェデレーションにおけ る認証技術及びシステムについて概説し,次に,そう したシステムにおいて,従来どのような運用ポリシー が表現可能であるかをまとめる.

2. 1 SAML

及びフェデレーション

SAML

は複数サービスに対して

SSO

を実現する認 証プロトコルとして定義されたが,認証結果のみなら ず,認証された利用者に関する情報を属性として同時 に

IdP

から

SP

へ提供する方法も含まれている.

SP

では,

IdP

から送信された属性に基づいて,認証の成 功とは別の基準による利用者ごとの認可判断を行うこ とが可能である.フェデレーションでは,

IdP

SP

が 連携するにあたって必要とする情報を,同じく

SAML

内で規定されるメタデータという形で集約し公開す る.各

IdP/SP

がメタデータを参照することで,フェ デレーションに参加し接続可能な

SP/IdP

を機械的に 識別することができる.これにより,フェデレーショ ンの枠内で信頼関係を構築し,安全な情報の交換を担 保している.これらの関係を図

1

に示す.

このようなフェデレーションを実現する形態は,大 きく二つに分けられる.一つは,全ての

IdP

SP

(3)

1 フェデレーションの概略図 Fig. 1 Basic architecture of the federation.

の通信に介在するハブをフェデレーションが用意して,

それを介して認証連携を行う方式である.もう一つは,

IdP

SP

が直接認証連携を行う方式である.前者は

hub-and-spoke

方式と呼ばれ,スペインの

SIR [7]

や ノルウェーの

Feide [8]

などで採用されている.

IdP

SP

の情報を

1

箇所で管理することができカスタ マイズも容易である反面,個人情報を含む情報が集 中するハブを問題なく運用できる強力な組織が必要 になる.一方,ハブをもたず各機関とサービスが直接 認証連携を行う方式を本論文では

full-mesh

方式と呼 ぶ.高等教育機関数の多い日本の学認では,米国や英 国と同様に,この

full-mesh

方式を採用している.な お,米国のフェデレーションである

InCommon

では,

2013

1

月時点でおよそ

300 IdP

及び

1000 SP

が参 加し約

6

百万人の利用者が利用しているが

[22]

,同様 に

full-mesh

方式を採用している他のフェデレーショ ンも含めて,この方式に起因するスケーラビリティの 問題は報告されていない.

こうしたプロトコルの他にも,フェデレーションで は,参加する多数の

IdP

及び

SP

の間で,交換される データのスキームの共通化やポリシーの合意を行うこ とで,相互運用性を実現している.

IdP

SP

がそれ ぞれ個別に行わなければならなかった交渉や技術検証 を連合体として行い,ノウハウの共有や蓄積を行う枠 組みとしても,フェデレーションは有効である.

2. 2

ミドルウェア

SAML

によるフェデレーションの中で広く利用され ているミドルウェアとして,

Shibboleth [15], [16]

simpleSAMLphp [17]

がある.いずれも,

IdP

におい

て必要とされる機能及び

SP

において必要とされる機 能を提供する.

Shibboleth

を含むほとんどの

IdP

の実装は,大学 の既存の認証基盤のフロントエンドとして動作する.

認証基盤との通信は

LDAP

等のプロトコルを用い,個 人の認証及び属性の取得を行う.属性の扱いに関する 更なる取組みとしては,利用者に対する属性送信の同 意への対応がある.

IdP

から

SP

への属性送信は,多 くの場合第三者提供にあたり,国によって,あるいは 機関の種別によっては,法令等の要請により,

IdP

の 運用機関は属性の送信について利用者から同意を得る 必要がある.すなわち,属性送信に関しては,機関に よる判断・制御のみならず,利用者による判断・制御 の機能が必要となる(特に事前に包括的な同意を得て いない場合).

利用者の同意を得る方法として,

hub-and-spoke

方 式のフェデレーションにおいてはハブがその役割を担 い,各フェデレーションでの独自実装により機能を提 供している.

Full-mesh

方式においては,

IdP

の機能 として提供されている.

Shibboleth

には,スイスの フェデレーションである

SWITCHaai [6]

が開発して いる

uApprove [18]

という同意取得のプラグインがあ る.

simpleSAMLphp

には,

consent module

という モジュールが付属しており

[17]

,これを有効にするこ とで属性送信時に利用者に同意を求めることができる.

2. 3 Discovery Service

DS

DS

の配備は,フェデレーションの規模が大きくな るにつれ,必須と考えられるようになった.

hub-and- spoke

方式のフェデレーションでは,ハブにおいてその フェデレーションにカスタマイズされた

DS

を運用す るのが一般的である.一方,

full-mesh

方式については,

DS

機能を実現するいくつかの実装がある.

Shibboleth Consortium

が提供するものには,

Shibboleth Central DS

Shibboleth CDS

)と

Shibboleth Embedded DS

Shibboleth EDS

)がある

[16]

.また,

SWITCHaai

が提供するものとして,

SWITCHwayf [19]

がある.こ のうち,

Shibboleth EDS

SWITCHwayf

は,

Em-

bedded DS

と呼ばれる機能も提供する.従来の

DS

で は,

SP

から

DS

に画面遷移し,

DS

のサイトにて

IdP

を選択する必要があった.フェデレーションでは,利用 者は

SP

DS

IdP

と多くの画面遷移を経験すること になる.

Embedded DS

は,画面遷移数を減らしユー ザエクスペリエンスを向上させるために,

DS

SP

の画面内に埋め込むことを目的とした新しい

DS

の実

(4)

装形態である.

SP

は,

Embedded DS

が提供するス クリプトを

SP

内に記述することで,

SP

の画面であ りながら,

IdP

選択機能を実現することができる.接 続できる

IdP

リストは,フェデレーションのメタデー タなどを用いて生成する.

2. 4

認証フロー

2

は,

SAML

による認証連携のフローを示した ものである.まず,利用者はブラウザを介して

SP

に アクセスする.

SP

において認可判断などが必要にな ると,

(1)

の認証要求が行われる.最初に

(2)

におい て

DS

が提示する

IdP

のリストの中から,利用者は自 身の所属機関が提供する

IdP

を選択する.次に

(3)

に おいて,選択された

IdP

に対して認証を行う.認証の 可否判断は

IdP

のバックエンドにある既存の認証基盤 に問い合わせることで行われ,正しく認証された場合 は,併せて利用者の属性が取得される.そして

(4)

で 送信する属性の選択や利用者同意取得など必要な処理

2 SAMLによる認証処理の流れ Fig. 2 Authentication flow by SAML.

1 従来のミドルウェアで反映可能なポリシー

Table 1 Policies which can be reflected by the conventional middleware.

を実行した上で,

IdP

から

SP

へ,認証結果及び属性 情報の送信が行われ,認証フローは完了となる.

2. 5 Shibboleth

で反映可能な参加者のポリシー フェデレーションへの参加者が,それぞれの運用ポ リシーを認証連携の過程で実現することは,フェデ レーションの運用にあたって本質的である.ここで は,各参加者の運用ポリシーが従来の実装でどの程 度反映可能であるかを,多くのフェデレーションで 利用されている

Shibboleth

,及びその機能を拡張す る

SWITCHwayf/Shibboleth EDS

uApprove

を対 象として説明する.

1

は,上記ミドルウェアで反映可能な様々な種類 のポリシーを列挙し,それぞれのミドルウェアでのポ リシーの反映可能性を示したものである.当該ポリ シーをどの参加者が保持するか,及びそのポリシーが 反映されるべき箇所をそれぞれ「ポリシー保持主体」

及び「反映箇所

/

機能」に併記している.同一ポリシー でも反映箇所が複数ある場合があり得るので,その場 合は複数行に分けて記述している.それぞれのポリ シーの説明を以下に示す.

IdP

による

SP

取捨選択

このポリシーは,

IdP

が信頼する

SP

,すなわ ち,認証連携可能な

SP

IdP

自身の意思に よって取捨選択できることを示す.

Shibboleth

では取捨選択する

SP

を直接指定することは できないが,フェデレーションが提供するメタ データから必要な

SP

のみを残すように加工し

(5)

たメタデータを

IdP

で読み込むようにすること で,

IdP

において反映することが可能である.

SP

による

IdP

取捨選択

このポリシーは,

IdP

による

SP

取捨選択と同様 に,

SP

が信頼する

IdP

,すなわち認証連携可能 な

IdP

を取捨選択することが

SP

自身の意思に よって可能であることを示す.

Shibboleth

では フェデレーションが提供するメタデータをベー スとして,取捨選択する

IdP

を指定することが 可能である.加えて,

SWITCHwayf

若しくは

Shibboleth EDS

を用いることで,この

SP

の ポリシーを

DS

で示す

IdP

リストに反映させる ことも可能である.この場合,

DS

から除外する

IdP

のブラックリストを用意することになる.

属性要求

SP

がどのような属性を必要とするかは各

SP

の機能・実装に応じて異なり,

SP

のポリシー といえる.これが

IdP

において反映可能である とは,特定の

SP

についてその

SP

が要求する 属性のみを選択して

IdP

が送信可能であること を示す.

属性送信

IdP

及び利用者がもつ,属性送信の可否につい てのポリシーである.

Shibboleth

では,

IdP

が 個々の属性について,それぞれの

SP

に対して 送信するかどうかを決定することができる.ま た,

IdP

プラグインである

uApprove

は,利用 者ポリシーとしての本ポリシーを反映させるた め,

Web

上で利用者の同意をとった上で属性を 送信するという機能をもつ.

IdP

選択

利用者が所属機関の

IdP

を選択することも,利 用者の意思としてシステムに反映させるべき利 用者ポリシーである.一般に,

DS

によって実 現される.

SP

による

IdP

取捨選択」ポリシーの

DS

におけ る反映と「属性要求」

SP

ポリシー,「属性送信」利用 者ポリシーの三つについては,

Shibboleth

本体では 実現できないが,

Shibboleth

のプラグイン若しくは 別実装として実現可能である.特に一つ目のポリシー については

SWITCHwayf

若しくは

Shibboleth EDS

がこの機能をもっている.残り二つのポリシーについ ては

Shibboleth IdP

のプラグインである

uApprove

により実現可能である.

3 属性要求ポリシーのメタデータでの表現の例 Fig. 3 An example of the attribute requirement

policy in the metadata expression.

ここで注目すべき点は,ほとんどのポリシーにおい て,ポリシー保持主体と,そのポリシーの反映箇所が 同一ということである.これにより,ポリシー保持主 体がローカルの設定ファイルとしてポリシーを記述す れば,ミドルウェアがそれを読み込んで反映すること が可能となっている.

ポリシー保持主体と反映箇所が同一でない項目は

SP

による

IdP

取捨選択」の

DS

における反映と「属 性要求」ポリシー,及び,最後二つの利用者ポリシー である.このうち利用者ポリシーについては利用者か ら

Web

ブラウザを通して入力してもらうことで直接 的に利用者ポリシーを反映箇所で取得している.

SWITCHwayf

及び

Shibboleth EDS

における「

SP

による

IdP

取捨選択」ポリシーは保持主体と反映箇所 が異なるが,いずれも

Embedded DS

として

DS

機能 を

SP

上で実現することによりポリシー伝達が不要と なる.この場合,ポリシー表現は

SP

ローカルの設定 ファイルに記述する.

uApprove

が反映する「属性要求」ポリシーも保持 主体と反映箇所が異なるポリシーであるが,これはポ リシー表現として

SAML

で規定されたメタデータ内 での記法を採用し,

uApprove

がそれを解釈すること により

IdP

において反映可能となる.メタデータに おける記述例を図

3

に示す.この例では,当該

SP

は メールアドレス属性を必須属性として要求している ことを示している.そして,それを反映させるための

IdP

での記述例を図

4

に示す.通常これは

SP

の条件 とともに用いるものであるが,この例では当該

SP

が メールアドレス属性を必須属性として要求している場 合に

IdP

はその属性を送信する,という指定である.

実際には,

IdP

が送信可能な属性の数だけこの指定を 列挙する.

2. 6

登録システム

フェデ レ ー ション に よって は ,参 加 す る

IdP/SP

の手続きのためにオンラインの登録システムを用

(6)

4 属性要求ポリシーのIdPにおける反映のための設 定例

Fig. 4 An example of the IdP configuration which corresponds with the attribute requirement policy.

意 し て い る .登 録 シ ス テ ム と し は

SWITCHaai

Resource Registry [5]

AAF

Federation Registry [20]

SURFfederatie

のシステム

[21]

InCommon

Federation Manager [23]

な ど が あ る .こ れ ら は ,

IdP/SP

が使用する公開鍵証明書の登録を受け付け,

メタデータを自動生成するなど,

IdP/SP

運用者の省 力化のための機能をもっている.また,登録システム の機能として,

IdP

が利用可能な

SP

を限定できるな どポリシー表現とみなせる機能をもつものもあるが,

先に述べた属性要求ポリシーを除いて,

IdP/SP

向け の設定ファイルの自動生成などそのシステム内での使 用を目的とするものであり,そのポリシーを他の箇所 で使うようなポリシー伝達を目的とするものではない.

3.

従来のフェデレーションにおけるポリ シー反映の問題

1.

で述べたように,フェデレーションを実際に運用 していく上では,

IdP

SP

,利用者という各参加者が もつポリシーに対し,柔軟に対応できる機構の提供が 望まれる.本章では,これまでの学認の運用を通して 明らかになってきた,表

1

には表現されていない新た な参加者ポリシーの具体的な例を提示しながら,現行 のシステムにおいて改善すべき点を指摘する.

3. 1 DS

における接続可否ポリシー反映の問題

2 (2)

のフェーズで,

DS

において利用者が

IdP

を選択する際の問題点を,以下に指摘する.

2. 1

で述べたように,フェデレーションの参加機関 である

IdP

SP

群は,基本的には相互に接続可能な 状態にある.しかしながら,ある

IdP

とある

SP

の間 には,一部のサービスを利用させない

/

できないとい う,運用上のポリシーをもつことがある.

IdP

におけ る連携不可の理由としては,

SP

が要求する属性を

IdP

側が提供できない場合,若しくは,機関として

SP

用可否の判断が保留されている場合などが挙げられる.

一方,

SP

における理由としては,電子ジャーナルの ように,契約のある機関(の構成員)にのみサービス を提供する場合などが挙げられる.しかしながら,従 来の

DS

では,こうした運用上のポリシーを適切に反 映できる機能を備えていない.

2. 3

で触れたように,

DS

には,大きく分けて

2

種 類の実装がある.一つは,

Central DS

と呼ばれるも のであり,この機能はフェデレーションが提供する.

Central DS

では,一般的に,フェデレーションに参 加する全ての

IdP

が選択肢として提示される.その ため,上記のような運用上のポリシーが存在する場合 でも,利用者は

DS

に表示される所属機関の

IdP

を選 択することができ,図

2 (4)

まで進んだ段階でエラー 画面が提示され,初めてサービスが利用できないこと に気づくことになる.こうした利用者の混乱を避け るために,いくつかの出版社

SP

では,独自の

DS

機 能を提供し,契約機関の

IdP

のみをリストに表示し ている.独自

DS

を採用することにより,先に挙げた

Central DS

の問題は回避されるが,従来の

SP

には ない機能を独自に実現しているため運用のコストは高 くなる.

SWITCHwayf

Shibboleth EDS

は,この ような

SP

による

DS

カスタマイズを低コストで行う ための機能を提供するものの,表

1

からも分かるよう に,

IdP

における

SP

の取捨選択のポリシーを反映す ることはできない.

IdP

の選択はフェデレーション特有の処理であるた めに,その操作が利用者に混乱を与えないよう,利用 者が直感的かつ適切にナビゲートされるものにして おくことが重要である.

IdP

SP

における運用上の ポリシーを反映可能な

DS

を提供することは,フェデ レーションにとって解決すべき重要な課題であるとい える.

3. 2 IdP

における複合型トラストドメインポリ

シー反映の問題

2 (3)

のフェーズで,

IdP

とそのバックエンドに ある統合認証基盤とのやり取りにおける問題点を,以 下に指摘する.

大学で

IdP

を運用する場合,接続対象となる全て の

SP

が同じトラストドメインに属するとは限らない.

例えば,学内のサービスを利用できる対象者としては,

卒業生や委託関係のある外部者が含まれる可能性があ る.これに対し,学認のシステム運用基準では,自機 関に所属する利用者の属性のみを保証することを基

(7)

本としている

[14]

.すなわち,学内サービスとフェデ レーションに属するサービスでは,トラストドメイン が異なり,それぞれのサービスが対象としている利用 者の母集団が違う.

こうした条件の違いに対処するために,それぞれの トラストドメインに対して,別の

IdP

を運用する方法 も考えられるが,構築や運用のコストが高くなる.ま た,利用者に対して,異なる

IdP

を常に意識させるこ とも,情報リテラシーやユーザサポートのコスト増に つながる.それと同時に,学内外のサービスに対する 統一的な

SSO

も提供できず,不便な環境を強いるこ とになる.このため,単一の

IdP

で異なるトラストド メインに対応することが不可欠となる.しかし現状で は,最も利用されている

Shibboleth

では認証処理及 び属性取得処理が完全に独立した機能として提供され ており,属性として表現される利用者のカテゴリーに 基づいて認証結果を制御することができない.こうし た機能が提供できれば,学内外,あるいは,地域や研 究プロジェクトでの利用など,異なるトラストドメイ ンに対応可能な,スケーラビリティの高い

IdP

が運用 できるようになる.

3. 3 IdP

における利用者の属性送信可否ポリシー

反映の問題

2 (4)

のフェーズで,

IdP

から

SP

への認証結果 及び属性を送信する際の問題点を,以下に指摘する.

属性は図

2 (3)

の問合せ先となる認証基盤に保存され ている.各

SP

は,その運用ポリシーとして必要とする 属性を要求し,

IdP

はそれに対応するように設定され る.このとき,

SP

が要求する属性には,必須と任意の ものがある.必須属性とは,それを送信しなければサー ビスを利用することができない必要最低限の属性を意 味する.一方,任意属性とは,それを送信することに より,追加的な機能を使うことができる属性を意味す る.例えば,電子ジャーナルサイトでは,必須属性に基 づき論文の閲覧機能を提供するとともに,任意属性が 送信されていれば,検索条件や結果を保存できるパー ソナライズ機能が利用できるようになる場合がある.

1

に示したように,従来の仕組みでは,送信する 属性を取捨選択できるのは,

IdP

のみである.利用者 には,属性送信の同意機能を介して,

IdP

が決定した 属性を全て送信するか否かの二者択一の選択肢しか与 えられない.すなわち,必須属性は送信するが,任意 属性は送信しないという利用者のポリシーが反映でき る機能は提供されていない.利用者の視点からは,こ

うした制約は取り除かれるべきである.サービスを利 用する権利がある場合には,属性送信に基づきどのレ ベルのサービスまでを利用するかを,利用者として判 断できることが望まれる.こうした柔軟な機能が提供 できれば,

IdP

としても,属性送信の可否に係る運用 コストが軽減できることになる.

4.

学認申請システムによるポリシー表現と 各参加者におけるポリシー反映の実現

3. 1

から

3. 3

で述べた三つの問題を解決するため,

各ポリシーの表現方法を規定し,それを各エンティ ティで反映させるための手法を提案する.

学認では,フェデレーションへの

IdP

及び

SP

の参 加登録をオンラインで実現するために学認申請システ ムを用いているが,これが提案手法においても中心的 役割を果たす.学認申請システムはフェデレーション が運用するシステムであり,

IdP/SP

の管理者がログ インし各種登録情報をメンテナンスすることが可能な ように設計されている.

4. 1

学認申請システムと連動して実現する

IdP

ポ リシーの

DS

への反映

DS

が提示する

IdP

選択肢に

IdP

ポリシー及び

SP

ポリシーを反映することにより

3. 1

で指摘した問題 が解決できる.提案手法の全体像を図

5

に示すが,

DS

と学認申請システムとを次のように連携させることで 実現する.

SP

に組み込む

Embedded DS

機能において,

SP

ごとに

IdP

リストをカスタマイズできるよ

5 学認申請システムと連動したGakuNinDSによる IdPリストの制御

Fig. 5 Relationship between GakuNinDS and GakuNin application system regarding IdP list management.

(8)

うにする.これにより,

SP

Embedded DS

を導入することにより,

SP

ポリシーが

SP

自 身で反映可能になる.

学認申請システムにおいて,各

IdP

管理者が

IdP

ポリシーを登録できるようにするとともに,

その情報を

SP

に提供する.

SP

は,提供を受 けた情報を

Embedded DS

IdP

リストに反 映させる.これにより,

IdP

ポリシーが反映さ れる.

この

Embedded DS

SWITCHwayf

Embed- ded DS

機能をベースに実装した.このような

Em- bedded DS

機能をもたせた

GakuNinDS [24]

と学認 申請システムによる,

IdP

リスト制御の処理の流れを 図

6

に示す.

まず,

IdP

運用者は

IdP

のポリシーを学認申請シス テムに登録する.例えば,この

IdP

では

SP A

及び

SP B

を利用するが,その他の

SP

は利用不可であると いうようなポリシーである.学認申請システムは,こ のような

IdP

ポリシーを参照し,

SP

ごとにその

SP

を 利用可能としている

IdP

の一覧を提供する.この一覧 は

JavaScript

で処理できるように

JSON

形式で提供 される.なお,このフォーマットは

Shibboleth EDS

Shibboleth SP

とも共通である.

SP

では,

SP

ポリシーを設定した

GakuNinDS

Embedded DS

SP

Web

ページに埋め込む.

IdP

リストを表示するための

HTML

片を元の

HTML

ファ イル中に挿入する形になる.

Embedded DS

が埋め 込まれたページを利用者がアクセスしたときの処理 の流れは図

6

の後半部分にあたる.挿入した

HTML

6 GakuNinDSによるEmbedded DS表示処理の流れ Fig. 6 Processing flow of the embedded DS by

GakuNinDS.

片は,

JavaScript

Central DS

から読み込み,この

JavaScript

JSON

形式の

IdP

リストを取得する.

取得した

IdP

リストと,あらかじめ設定された

SP

ポ リシーと併せて処理することで,これらポリシーを反 映させた

IdP

リストが利用者に提示される.

4. 2 IdP

プラグインによるトラストドメインごと

の対象利用者制限の実装

IdP-SP

間のプロトコル実装を除けば,従来からの

IdP

の役割は

SP

ごとの送信属性選択のみであり,認 証が成功すれば処理は

IdP

から

SP

に移る.

3. 2

で 指摘したトラストドメインの違い,すなわちアクセス 先の

SP

に応じて対象利用者の母集団を切り換えるに は,

IdP

において制御機構を実装する必要があるが,

このような機能を実装するにあたっても,

IdP

のプラ グインの形態をとれば実装が容易になると考えられ る.実装したプラグインを

FPSP

Filter Per Service Provider

[25]

と呼ぶ.

FPSP

をインストールした

IdP

での処理の流れを 図

7

に示す.

FPSP

では,あらかじめトラストドメイ ンごとにアクセス可能な利用者が満たすべき属性条件 を図

8

に示すような

XML

形式のファイルとして設定 しておく.この例では特定

SP

に対して学生・教員・

職員からなる利用者の集合を母集団とするように設定 している.

利用者が

IdP

で認証を行う際にこのポリシーの強 制が行われる.利用者がクレデンシャル,例えば

ID/

パスワードの組を入力し,

IdP

において認証が行われ 利用者の属性が取得された後に,

FPSP

にてその属性 を用いて設定された条件との比較を行う.図

8

に例示

7 FPSPによる利用者制限処理の流れ Fig. 7 Processing flow of the authentication control

by FPSP.

(9)

8 FPSPに設定する対象利用者制限ポリシーの例 Fig. 8 An example of policy description which rep-

resent how to restrict the authentication user by means of FPSP configuration.

した条件であれば,当該

SP

に卒業生や外部業者がア クセスした場合には不一致となる.この結果,不一致 だった場合には,通常フローとして

SP

に認証結果を 戻す代わりに,利用者ブラウザにエラー表示を行い,

認証フローをその先に進まなくする.

他の手法と異なり,オンラインでのポリシー表現方 法は用意せず,フェデレーション等トラストドメイン からのポリシーを

IdP

管理者がオフラインで設定する こととしている.これは係るポリシーの主体はフェデ レーション

SP

群,学内

SP

群といったように,ある 程度のまとまりをもって表現され,またその内容も静 的なものであるので,

IdP

側で容易に把握可能である と考えられるためである.

4. 3

学認申請システムと

IdP

プラグインの連携 による属性送信の利用者ポリシーの反映

3. 3

で述べた送信属性の選択に関する問題は,学認 申請システムと

IdP

プラグインの連携により解決する ことができる.概略図を図

9

に示す.学認申請システ ムは「属性要求」ポリシーの伝達,特に要求される属 性が必須か任意かの情報を

IdP

に伝達する役割を担 い,

IdP

プラグイン

uApprove.jp [26]

が,図

2

(4)

の部分に介在し,送信属性選択のユーザインタフェー スを担当する.

uApprove.jp

uApprove

をベースと して我々が改良,公開している

Shibboleth IdP

向け のプラグインである.

利用者による属性選択の具体的な処理の流れを図

10

に示す.まず,

SP

運用者が学認申請システムに対し て要求する属性及び当該属性が必須か任意かの別を指 定する.指定された内容は先に図

3

で示したものと同 じポリシー表現を使ってメタデータに記載され公開さ れる.必須か任意かの情報も,この表現に含まれる.

9 uApprove.jpによる要求属性反映,同意取得及び属 性選択方法

Fig. 9 Methods for attribute request, consent acquisition and attribute selection by uApprove.jp.

10 利用者による送信属性選択の処理の流れ Fig. 10 Processing flow of the attribute selection by

users.

IdP

側ではこのメタデータを読み込むことにより

SP

のポリシーを反映可能となる.

次に利用者が

IdP

で認証を行う際の処理の流れを 説明する.

uApprove.jp

の処理は,利用者がクレデン シャルを入力し,

IdP

において認証が行われ利用者の 属性が取得された後に行われる.もし

4. 2

で述べた

FPSP

と組み合わせて使用する場合は,

FPSP

のフィ ルタの後に実行させる.

uApprove.jp

は,利用者の属性が

SP

に要求されて いるか否か,必須か任意かをメタデータで示された属 性要求ポリシーから判別し,それをもとに利用者に対 する選択肢を構成する.実際に利用者に提示される画 面を図

11

に示す.画面上部に必須属性の一覧を配置 し,必ず送信されるものとしてチェックボックスなし で提示される.画面下部には任意属性の一覧を配置し,

利用者が取捨選択できるようにチェックボックス付き で提示される.これを利用者に提示し利用者の同意を

(10)

11 利用者に提示される送信属性情報のスクリーン ショット

Fig. 11 Screenshot showing attributes to be sent for users.

求め,同意が得られた場合に限り必須属性及び選択さ れた任意属性を

SP

に送信する.このようにして,属 性送信,特に属性選択に関する利用者ポリシーの反映 を実現する.

利用者が属性を取捨選択するとき,当該任意の属 性の

SP

における利用用途は,その判断材料として 重要な情報である.学認申請システムでは,属性の 利用用途を任意の文を入力できるようにしている.

ま た ,こ の 属 性 利 用 用 途 を ポ リ シ ー 表 現 と し て 扱 えるように,図

3

md:RequestedAttribute

要素に

uajpmd:description

属性を追加し,メタデータとし て配布する.

uApprove.jp

ではメタデータからこの情 報を取り出し,利用者に提示する情報として要求属性 一覧の一部として提示する.図

11

に例示しているが,

当該属性をポイントしたときにその利用用途が表示さ れるようになっている.

ここで,重複する「属性送信」

IdP

ポリシー及び

IdP

による

SP

取捨選択」

IdP

ポリシーについて述 べておく.

2. 5

で述べたように

IdP

からの属性送信 については「属性要求」

SP

ポリシーをもとに「送信 可能な属性のうち

SP

が要求しているもの」のように 指定することが可能である.更に「

IdP

による

SP

取 捨選択」

IdP

ポリシーにより一部の

SP

が使用不可と 指定されていることと考え併せると,「使用可能と指 定されている

SP

については

SP

が要求している属性 を送信する」という

IdP

ポリシーが合理的に導き出せ る.このポリシーを表現する設定ファイルは学認申請 システムがもつ情報から自動的に生成される.

自動生成された設定ファイルを適用することにより,

結果として,

IdP

運用者は「

IdP

による

SP

取捨選択」

ポリシーを,学認申請システムを通して適切に設定す るだけで,その他の

IdP

ポリシーは合理的なポリシー

が設定されるシステムが準備できる.これは,従来 個々の属性の送信設定をローカルの設定ファイルに対 して行っていた作業と比較すると,

IdP

運用者の負担 を大きく改善するものであると考える.もちろん

IdP

運用者がより細かくポリシーを設定して運用すること を望む場合は,提供された設定ファイルを適宜修正し て利用することができる.

4. 4

従来実装との比較

本章で提案したポリシー反映機能を,表

1

に追加し たものが表

2

である.従来の実装である

Shibboleth

SWITCHwayf/Shibboleth EDS

uApprove

におけ る反映の可否は一つにまとめて従来実装として示して いる.

本表で追加したポリシーを以下に説明する.

対象利用者母集団

SP

がどの範囲の利用者を対象として想定して いるか,

SP

による認可前の,

IdP

経由で

SP

に 到達することが可能な利用者の範囲,いわゆる 母集団を表す.一般に属性による判別は不可能 であることが多いため,

SP

による認可とは別問 題である.

3. 2

に書いたように,この母集団は

SP

のトラストドメインにより異なる.

IdP

に おいて反映可能であるとは,この母集団を

SP

ごとに

IdP

が制御可能であることを示す.

属性選択

これは利用者のポリシーであり,これが

IdP

に おいて反映可能とは,利用者が選択した属性を

IdP

から

SP

に送信できることを指す.

このほか,本章で説明したように,参加者がもつ ポリシーをそれと異なる箇所で反映可能となってい るのが「

IdP

による

SP

取捨選択」ポリシーである.

IdP

による

SP

取捨選択」ポリシーは

IdP

がもつポ リシーであるが,学認申請システムがポリシーを伝達 し

GakuNinDS

がそれを処理することにより,

SP

上 の

Embedded DS

において反映可能となっている.

このように,本論文で提案した実装は参加者のポリ シーを反映可能な部分を拡大し,利用者により高い ユーザビリティを提供するとともに,従来ポリシー反 映のために要していた

IdP/SP

運用者の負担を軽減す るものである.フェデレーションにおいてポリシー表 現方法・伝達プロトコルを適切に定義することにより,

ポリシー保持者と異なる箇所でのポリシー反映を実現 している.

異なる箇所でのポリシー反映のためのポリシー伝達

(11)

2 本論文における実装と従来実装での反映可能なポリシーの比較 Table 2 Comparison in the applicable policy between this study and conventional

implementations.

については,オンラインで自動的に行われることが基 本であるが,「対象利用者母集団」ポリシーは例外であ る.

4. 2

で説明したようにこのポリシーはフェデレー ションポリシーやその他の形でオフラインで

IdP

側に 伝達されるもので,ほとんどの場合静的なものである ため,

IdP

運用者が手作業でローカルファイルとして 設定することを想定している.

4. 5

提案手法によるポリシー反映の効果

本節では,これまでに述べた改善点のまとめとして,

一つの利用例をもとに提案手法を利用することによる 効果を示す.ここでは,電子ジャーナル閲覧サービス を例として取りあげ,機関ごとに契約を行った場合に その機関に所属する利用者が自由にサイト上の論文を 閲覧でき,また付加機能として自分が行った検索履歴 を参照するパーソナライズ機能を提供するサービスを 想定する.このサービスの利用対象者は当該組織に所 属している者に限られているものとする.

まず,従来のフェデレーションに本事例を適用した 場合について述べる.最初にサービスにアクセスした 利用者は,所属機関を選択するために

DS

を利用する が,契約の有無にかかわらずフェデレーションに参加 する全ての機関が一覧表示される.契約のない機関の 利用者がそれと知らず所属機関を選択すると,認証の

プロセスを経たあとにサービス側でアクセスを拒否さ れる.利用者にはアクセス拒否の原因が示されないの で,

IdP

SP

の管理者にサポートを求めることにな る.また,送信する属性は機関側で決定されるので,

個人にひも付けられる

ID

を属性として送信すること で提供されるパーソナライズ機能の利用可否は機関ご とに決定されることになる.つまり,機関の単位で,

全ての利用者がパーソナライズ機能を利用できないか,

あるいはプライバシーに配慮せず全ての利用者がパー ソナライズ機能を利用できるかという,利用者に選択 の自由がない状態となる.

次に,提案手法を用いてサービスを実現した場合の 効果を示す.

DS

GakuNinDS

)では,実際に機関契 約のもとでサービス利用可能な機関のみがリストアッ プされるため,契約外の利用者が認証に進むという 混乱は生じない.また,

OB/OG

が当該機関の統合認 証基盤に登録され認証可能な状態であったとしても,

FPSP

プラグインにより

OB/OG

の当該サービスへ のアクセスは

IdP

上でブロックされ,サービスとの 契約条件に合致したアクセス制御が効率的に実現され る.更に,

uApprove.jp

プラグインによって利用者が

ID

属性の送信可否を選択できるようになり,プライ バシー保護に配慮しつつパーソナライズ機能を使いた

(12)

い利用者だけが,要求される個人情報を開示すること でその機能を利用することが可能となる.

5.

む す び

本論文では

Web

ベースの

SSO

技術を活用した学 術認証フェデレーションの展開にあたって,

IdP/SP/

利用者それぞれがもつ多様なポリシーが従来のフェデ レーション機構では十分に反映できないことを指摘す るとともに,それぞれのポリシーを細かく反映するた めの手法を提案した.提案手法は,日本における学術 認証フェデレーションである「学認」に試験的に実装 し,意図どおりに動作することを確認した.このよう な柔軟性の実現により,更により多くの機関が学術認 証フェデレーションに容易に参加できるようになるこ とを期待したい.

フェデレーションは学術機関に限定されるものでは ない.現在,クラウド上に多種多様なサービスが展開 され,利用者となる組織がその中からサービスを選択 して利用する形態が急速に普及している中で,サービ スから認証機能を分離しユーザ管理を一元化しよう とする動きは自然なものである.この状況で,認証基 盤同士が連合し集約することによるコストメリットが フェデレーション構築の動機付けとなる.学術機関は 共通して利用するサービスが多いなどそのメリットが 大きかったために先行しているが,グループ企業・中 央省庁・地方自治体などにもその動機が存在すると考 えられる.仮にそのようなフェデレーションが構築さ れた場合,全ての参加組織が表

2

で列挙したポリシー について均質であるとは考えにくい.実装として,学 術機関由来である

Shibboleth

以外の実装が用いられ ることや,プロトコルとして

SAML

と同様の機能を もつ

OpenID [27]

が利用されることも考えられるが,

本論文の成果である各参加者のポリシーの差異を吸収 する機構は依然として必要であり,本論文で提案した 手法が必要とされるであろう.

文 献

[1] 宮下健輔,水野義之,“京都女子大学における情報教育と 情報システムの変遷に関する考察,3回インターネッ トと運用技術シンポジウム(IOTS2010),pp.9–16, Dec.

2010.

[2] 藤村喬寿,田島浩一,大東俊博,西村浩二,相原玲二,“大 規模キャンパスネットワークHINET2007へのシングル サインオン機能の実装および評価,3回インターネッ トと運用技術シンポジウム(IOTS2010),pp.111–118, Dec. 2010.

[3] 江藤博文,渡辺健次,只木進一,渡辺義明,“全学的な共

通情報アクセス環境のための統合認証システム,情処

学研報DSM,[分散システム/インターネット運用技術],

vol.2002, no.95, pp.31–36, Oct. 2002.

[4] J.D. Clercq, “Single sign-on architectures,” Proc.

InfraSec 2002, LNCS, vol.2437, pp.40–58, 2002.

[5] L. H¨ammerle, “SWITCHaai: Shibboleth-based fed- erated identity management in Switzerland,” Proc.

CESNET 2006 Conference, 2006.

[6] M. Linden, “Organising federated identity in Finnish higher education,” Computational Methods in Sci- ence and Technology, vol.11, no.2, pp.109–117, 2005.

[7] D.R. Lopez and C. Rodr´ıguez, “Digital identity made simple: The RedIRIS identity service - SIR,” EUNIS 2009, Spain, June 2009.

[8] I. Melve and A.˚A. Solberg, “Building a federated identity for education: Feide,” Telektronikk [0085- 7130], vol.103, no.3/4, pp.85–102, 2007.

[9] Research and Education FEDerations (REFEDS),

“Federations - survey of federations in higher edu- cation,” https://refeds.terena.org/index.php/

Federations, last visited Aug. 31, 2012.

[10] S. Cantor, J. Kemp, R. Philpott, and E. Maler ed., “Security Assertion Markup Language (SAML) V2.0,” http://saml.xml.org/saml-specifications, March 2005.

[11] K. Yamaji, T. Kataoka, T. Nishimura, M. Shimaoka, M. Nakamura, N. Sonehara, and Y. Okabe, “UPKI federation 2009 pilot operation,” 27th APAN Meet- ing, 2009.

[12] 国立情報学研究所,“学術認証フェデレーション:学認,” https://www.gakunin.jp/ja/,参照Sept. 3, 2012.

[13] 学認,“学術認証フェデレーション実施要領,” https://www.gakunin.jp/docs/files/

gakunin-youryou120322.pdf, March 22, 2012.

[14] 学認,“学術認証フェデレーションシステム運用基準,” https://www.gakunin.jp/docs/files/

GakuNin System SpecV1.2.pdf, Aug. 24, 2011.

[15] S. Cantor ed., “Shibboleth Architecture,”

https://wiki.shibboleth.net/confluence/download/

attachments/2162702/

internet2-mace-shibboleth-arch-protocols-200509.

pdf, Sept. 2005.

[16] Shibboleth Consortium, “Shibboleth-home,”

http://shibboleth.net/, last visited Aug. 31, 2012.

[17] I. Andronache and C. Nisipasiu, “Web single sign-on implementation using the simpleSAMLphp applica- tion,” Journal of Mobile, Embedded and Distributed Systems [Online], vol.3, no.1, pp.21–29, March 2011.

[18] The SWITCH Foundation, “uApprove,”

http://www.switch.ch/aai/support/tools/

uApprove.html, last visited Aug. 31, 2012.

[19] The SWITCH Foundation, “WAYF service,”

http://www.switch.ch/aai/support/tools/wayf.html, last visited Aug. 31, 2012.

[20] Australian Access Federation (AAF), “Federation

(13)

Registry,” http://wiki.aaf.edu.au/federationregistry/, last visited Aug. 31, 2012.

[21] R.P. Wijnen and B. Hulsebosch, “SURFfederatie self-service business case,” http://www.surfnet.nl/

nl/Innovatieprogramma%27s/gigaport3/Documents/

EDS-6R%20SURFfederatie%20self-service.pdf, Sept.

2010.

[22] InCommon, LLC, “InCommon: Security, privacy and trust for the research and education community,”

http://incommon.org/, last visited Aug. 31, 2012.

[23] InCommon, “InCommon federation manager,”

https://spaces.internet2.edu/display/InCCollaborate/

Federation+Manager, last visited Aug. 31, 2012.

[24] 学認,“Embedded DSの利用方法,

https://www.gakunin.jp/docs/fed/technical/

embeddedds,参照Aug. 31, 2012.

[25] 学認,“ユーザに対する特定SPへのアクセス制限,” https://www.gakunin.jp/docs/fed/technical/idp/

customize/knowhow/authorization, 参 照 Aug. 31, 2012.

[26] T. Orawiwattanakul, K. Yamaji, M. Nakamura, T.

Kataoka, and N. Sonehara, “User consent acquisition system for Japanese Shibboleth-based academic fed- eration (GakuNin),” Int. J. Grid and Utility Com- puting (IJGUC), vol.2, no.4, pp.284–294, Oct. 2011.

[27] OpenID Foundation, “OpenID Foundation website,”

http://openid.net/, last visited Aug. 31, 2012.

(平成2496日受付,25111日再受付)

西村 健

1998東京大学大学院理学系研究科情報 科学専攻修士課程了.2001同大学院理学 系研究科情報科学専攻博士課程単位取得退 学.同年東京大学人文社会系研究科助手,

同情報基盤センター特任助教を経て,2009 より国立情報学研究所特任研究員.認証基 盤の構築,認証技術及び認証連携技術の研究開発を行う.

中村 素典 (正員)

1994京都大学大学院工学研究科博士後 期課程単位取得退学.立命館大学理工学部 助手,京都大学経済学部助教授,京都大学 学術情報メディアセンター助教授を経て,

2007より国立情報学研究所教授,2008 り総合研究大学院大学教授(併任),現在 に至る.博士(工学).情報処理学会,日本ソフトウェア科学 会,IEEE各会員.コンピュータネットワーク,ネットワーク コミュニケーション,認証連携などの研究に従事.

山地 一 (正員)

2000豊橋技術科学大学大学院博士課程 了・博士(工学).同年日本学術振興会特別 研究員.2002より理化学研究所脳科学総 合研究センター研究員.2007より国立情 報学研究所学術ネットワーク研究開発セン ター准教授.データシェアリング並びにそ の認証基盤に関する研究開発に従事.情報処理学会,情報知識 学会各会員.

佐藤 周行

1985東大卒.1990同大大学院了.理 博.現在東京大学情報基盤センター准教授.

2005より国立情報学研究所客員准教授.専 門はコンピュータサイエンス・情報セキュ リティ.情報処理学会,日本ソフトウェア 科学会,ACM,IEEE各会員.

大谷 誠

10佐賀大・理工・情報科学卒.平12 同大大学院工学系研究科博士前期課程情報 科学専攻了.平15同大学院工学系研究科 博士後期課程システム生産科学専攻了.同 年海洋エネルギー研究センターCOE研究 員.平16同大学学術情報処理センター(現 総合情報基盤センター)講師.平21同大学総合情報基盤セン ター准教授,平23(1年間)国立情報学研究所学術ネットワー ク研究開発センター外来研究員併任,インターネットの研究に 従事.博士(工学).

岡部 寿男 (正員)

1988京都大学大学院工学研究科修士課 程了.同年京都大学工学部助手.同大型 計算機センター助教授などを経て2002 り同学術情報メディアセンター教授.博士

(工学).2005より国立情報学研究所客員 教授.インターネットアーキテクチャ,ネッ トワークセキュリティ等に興味をもつ.情報処理学会,システ ム制御情報学会,日本ソフトウェア科学会,IEEE,ACM 会員.

曽根原 登 (正員)

1978信州大学大学院修士了,同年日本 電信電話公社(現,NTT)入社.ファクシ ミリ,コンテンツ流通システム等の研究開 発・実用化に従事.1999〜2003東京工業 大学客員教授.2004〜国立情報学研究所

(NII)教授,総合研究大学院大学教授兼務.

2006〜NII情報社会相関研究系研究主幹.工博.

図 1 フェデレーションの概略図 Fig. 1 Basic architecture of the federation.
Table 1 Policies which can be reflected by the conventional middleware.
Fig. 5 Relationship between GakuNinDS and GakuNin application system regarding IdP list management.
図 6 GakuNinDS による Embedded DS 表示処理の流れ Fig. 6 Processing flow of the embedded DS by
+4

参照

関連したドキュメント

実際, クラス C の多様体については, ここでは 詳細には述べないが, 代数 reduction をはじめ類似のいくつかの方法を 組み合わせてその構造を組織的に研究することができる

※ 硬化時 間につ いては 使用材 料によ って異 なるの で使用 材料の 特性を 十分熟 知する こと

 ESET PROTECT から iOS 端末にポリシーを配布しても Safari の Cookie の設定 を正しく変更できない現象について. 本製品で iOS

および皮膚性状の変化がみられる患者においては,コ.. 動性クリーゼ補助診断に利用できると述べている。本 症 例 に お け る ChE/Alb 比 は 入 院 時 に 2.4 と 低 値

サイトにバナーを貼ろう! プライバシー‧ポリシー セキュリティ‧免責‧リンクについて (C)2021 Ministry of Health, Labour and Welfare, All

本案における複数の放送対象地域における放送番組の

本学陸上競技部に所属する三段跳のM.Y選手は