多様なポリシーを反映可能な認証フェデレーション機構の実現
西村 健
†中村 素典
†山地 一
†佐藤 周行
††大谷 誠
†††岡部 寿男
††††曽根原 登
†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
技術の導入では,信頼性の確保は容易である.これを更にスケールアウトし,信頼関係の輪を組織の 枠を超えて構築することができれば,インターネット
上に展開される数多くのサービスを研究・教育のため に活用できる新たな道が開けると期待される.
このような可能性を現実のものとすべく,学術認証 フェデレーションが,世界的に広がりをみせており,欧 米を中心に,現在,
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
間図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
の実装形態である.
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
のみを残すように加工したメタデータを
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
の手続きのためにオンラインの登録システムを用図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
が同じトラストドメインに属するとは限らない.例えば,学内のサービスを利用できる対象者としては,
卒業生や委託関係のある外部者が含まれる可能性があ る.これに対し,学認のシステム運用基準では,自機 関に所属する利用者の属性のみを保証することを基
本としている
[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.
うにする.これにより,
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.
図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
に示す.画面上部に必須属性の一覧を配置 し,必ず送信されるものとしてチェックボックスなし で提示される.画面下部には任意属性の一覧を配置し,利用者が取捨選択できるようにチェックボックス付き で提示される.これを利用者に提示し利用者の同意を
図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
運用者の負担を軽減す るものである.フェデレーションにおいてポリシー表 現方法・伝達プロトコルを適切に定義することにより,ポリシー保持者と異なる箇所でのポリシー反映を実現 している.
異なる箇所でのポリシー反映のためのポリシー伝達
表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
属性の送信可否を選択できるようになり,プライ バシー保護に配慮しつつパーソナライズ機能を使いたい利用者だけが,要求される個人情報を開示すること でその機能を利用することが可能となる.
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
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.
(平成24年9月6日受付,25年1月11日再受付)
西村 健
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情報社会相関研究系研究主幹.工博.