学 割 サービス 実 現 のための SAML-OpenID ゲートウェイの 試 作 1 中 村 素 典 1 西 村 健 1 山 地 一 禎 2 佐 藤 周 行 3 岡 部 寿 男 近 年,シングルサインオンの 技 術 を 応 用 し, 組 織 をまたがった 認 証 連 携 を 行 う 取 り 組 みが 広 がりを 見 せている. 民 間 では OpenID の 仕 組 みを 活 用 した 認 証 連 携 が 進 む 一 方, 学 術 では SAML (Security Assertion Markup Language)を 用 いた 認 証 連 携 の 枠 組 みが, 国 を 単 位 として 世 界 的 に 立 ち 上 がってきている.OpenID や SAML では, 認 証 結 果 とともに, 認 証 された 利 用 者 に 関 する 属 性 情 報 をサービス 提 供 側 に 受 け 渡 す 仕 組 みが 用 意 されているため, 単 なる 利 用 者 の 本 人 確 認 にとどまらない, 高 度 な 情 報 連 携 の 可 能 性 を 秘 めている. 本 報 告 では, 大 学 等 が 運 用 管 理 する 認 証 サーバと, 民 間 のサービス 提 供 サーバとを 連 携 させ, 大 学 が 保 持 する 職 種 ( 学 生, 職 員, 教 員 など)に 関 する 属 性 情 報 を 提 供 する ことにより, 学 割 サービスを 実 現 するためのプロトコルゲートウェイの 設 計 および 試 作 について 述 べる. Trial Implementation of SAML-OpenID Gateway for realizing Student Discount Services Motonori NAKAMURA 1 Takeshi NISHIMURA 1 Kazutsuna YAMAJI 1 Hiroyuki SATO 2 Yasuo OKABE 3 A framework of cooperation on user authentication among organizations has begun to spread widely by utilizing Single-Sign-On mechanisms. OpenID is mainly used for commercial field, and SAML (Security Assertion Markup Language) is mainly used for academic field. Major countries are constructing an academic federation each. These mechanisms have possibilities for advanced cooperation since both have a mechanism to provide attribute information on authenticated user for service sites. This manuscript reports on a trial to implement a gateway between SAML and OpenID to support academic/student discount service by providing affiliation information of users, such as student, faculty, staff, etc., which is maintained by universities, by cooperating authentication server operated by universities and service sites operated by commercial providers. 1. はじめに 最 近 のクラウドサービスの 充 実 により, 自 組 織 の 外 で 提 供 されるサービスの 認 証 に, 自 組 織 の 認 証 機 構 を 利 用 する 認 証 フェデレーションの 利 用 が 急 速 に 広 まっている.この ベースにあるものは,いわゆる 認 証 認 可 の 分 離 に 基 づい たシングルサインオン 技 術 の 活 用 であり, 国 際 標 準 である SAML (Security Assertion Markup Language) [1]や OpenID [2] に 基 づいた 機 構 が 主 として 利 用 されている. 学 術 分 野 にお いては,SAML に 基 づいた 認 証 フェデレーションの 構 築 が 主 流 となっており, 国 を 単 位 として 欧 米 を 中 心 に 構 築 が 進 んでいる[3]. 日 本 においても, 国 立 情 報 学 研 究 所 を 中 心 に 2009 年 より 構 築 を 開 始 し,2010 年 より 学 術 認 証 フェデレー ション 学 認 として 実 運 用 を 行 っている[4][5]. 一 方, 商 用 サービス 提 供 授 業 者 においては,OpenID の 活 用 が 進 んで おり,Aol,Facebook,Google,mixi, Yahoo!などに 登 録 さ れたアカウントを 利 用 して, 他 のサービスにログインでき るような 環 境 の 展 開 が 進 んでいる[6]. この 2 つの 認 証 フェデレーションは, 上 述 のようにそれ ぞれ 異 なる 機 構 を 利 用 しているが, 民 間 で 提 供 される 商 用 1 国 立 情 報 学 研 究 所 National Institute of Informatics 2 東 京 大 学 The University of Tokyo 3 京 都 大 学 Kyoto University サービスの 充 実 と 高 度 化 により, 学 術 分 野 においても,こ れらを 研 究 教 育 に 採 用 する 例 が 増 加 してきている[7][8][9]. 他 方, 民 間 サービスにおいては, 福 利 厚 生 的 利 用 を 含 め, 学 術 関 係 者 の 利 用 に 対 して 割 引 を 提 供 する 慣 例 が 古 くから あり, 割 引 をオンラインサービスにおいても 同 様 に 実 現 し ユーザを 確 保 したいという 要 望 がある. 基 本 機 構 の 異 なる 2つのフェデレーションを 技 術 的 に 接 続 し, 学 術 機 関 側 か ら 認 証 とユーザの 身 分 を 示 す 情 報 を 提 供 することにより, 割 引 を 考 慮 したサービスの 提 供 を 実 現 することが 可 能 とな る. そこで,このような 仕 組 みを 実 現 するために 必 要 となる 機 能 について 検 討 し 試 作 を 行 ったので 報 告 する. 2. 認 証 フェデレーション 2.1 シングルサインオン サービス 毎 に 異 なる ID およびパスワードを 用 いて 認 証 を 行 うことは,システム 管 理 者 とユーザの 双 方 にとって 煩 雑 である. 複 数 のサービスで 共 通 の ID とパスワードを 利 用 するためには,まず LDAP[10] 等 を 用 いて ID およびパス ワードを 保 持 する 認 証 データベースを 統 合 し, 各 サービス から 同 一 の 認 証 データベースを 参 照 する 方 法 が 考 えられる. さらにそこから, 各 サービスから 認 証 機 能 を 分 離 し,サー ビス 共 通 の 認 証 サーバを 作 り,ユーザは ID とパスワード をそのサーバに 入 力 して 認 証 結 果 を 各 サービスに 伝 える, という 形 態 に 発 展 させることにより,シングルサインオン 1
が 実 現 される. 認 証 サーバが 認 証 状 態 をしばらくの 間 保 持 し,その 間 に 他 のサービスからの 認 証 要 求 が 来 た 際 に,ユ ーザに 対 する 再 認 証 (ID とパスワードの 再 入 力 )を 求 めな い 仕 組 みを 持 たせることにより,いわゆるシングルサイン オンとしての 機 能 が 実 現 される.このシングルサインオン の 機 能 を, 一 つの 組 織 内 で 閉 じて 利 用 するだけでなく, 他 の 組 織 と 連 携 させる 形 で 活 用 する 形 態 は 認 証 フェデレー ション あるいは 単 に フェデレーション と 呼 ばれる. 2.2 基 本 アーキテクチャ SAML や OpenID は, 認 証 フェデレーションを 実 現 する ための 枠 組 みを 提 供 するものである.サービスで 共 通 の 認 証 サーバのことを,SAML では IdP (Identity Provider)と 呼 び, OpenID では OP (OpenID Provider)と 呼 ぶ. 一 方,この 認 証 サーバにおける 認 証 処 理 の 結 果 に 基 づいて 実 際 にサービス を 提 供 するサーバのことを, SAML では SP (Service Provider)と 呼 び,OpenID では RP (Relying Party)と 呼 ぶ. 名 称 は 異 なるが, 基 本 的 には 同 様 の 機 能 を 提 供 するものであ る. 一 組 織 の 中 で 閉 じたシングルサインオンでは,IdP/OP は 一 つだけ 存 在 するのが 一 般 的 であるが, 認 証 フェデレー ションの 場 合 は,フェデレーションに 参 加 しサービスを 利 用 する 組 織 毎 に IdP/OP を 構 築 する 分 散 型 の 構 造 をとるこ とになる. 学 術 分 野 において 広 く 用 いられている SAML をサポー トしたプラットフォームとしては, Shibboleth [11] や SimpleSAMLphp [12]などがある. 一 方,OpenID についても, いくつかのライブラリが 提 供 されている. 2.3 属 性 送 信 と 送 信 同 意 SAML や OpenID によって 提 供 されるシングルサインオ ン 機 構 では,IdP/OP は 認 証 結 果 として 認 証 の 可 否 を SP/RP に 伝 えるだけでなく, 併 せて 認 証 されたユーザに 関 する 情 報 を 伝 達 する 機 能 を 持 つ.このような 情 報 は 属 性 情 報 と 呼 ばれる. 例 えば, 学 認 では,システム 運 用 基 準 [13]におい て 15 種 類 の 属 性 情 報 を 定 義 している.これらの 多 くは Internet2 で 定 義 されている eduperson オブジェクトクラス [14]のものをベースとしているが, 例 えば,その 中 の edupersonaffiliation はユーザの 身 分 を 示 す 属 性 情 報 であり, student ( 学 生 ),faculty ( 教 員 ),staff ( 職 員 )などの 値 を 持 つ. OpenID では,OpenID 2.0[15]の 拡 張 仕 様 である Attribute Exchange[16]において 属 性 情 報 の 交 換 が 規 定 されているが, 最 近 では OAuth 2.0[17]をベースとして 設 計 された OpenID Connect[18]が 策 定 され,そちらへの 対 応 が 始 まっている [19]. 認 証 フェデレーションでは, 他 の 組 織 に 対 して 属 性 情 報 を 送 信 する 場 合 が 生 じるが,このような 情 報 の 送 信 は 業 務 委 託 によるサービス 利 用 でない 限 り 第 三 者 提 供 にあたる. 属 性 情 報 のうちの 一 部 は 個 人 情 報 に 相 当 するものであり, プライバシー 保 護 のための 考 慮 が 求 められる. 日 本 におい ては,プライバシー 保 護 に 関 する 法 律 [20][21]が 定 められて おり, 一 般 には 事 前 の 同 意 (オプトイン; Opt-In)あるいは 事 後 の 求 めによる 提 供 停 止 (オプトアウト; Opt-Out)に 対 応 することが 求 められる. 特 に 国 立 大 学 については, 独 立 行 政 法 人 に 準 じる 扱 いが 求 められるため,オプトインをサポ ートする 必 要 がある. 公 立 大 学 については 地 方 公 共 団 体 が 定 める 条 例 が 定 めているが, 大 半 は 独 立 行 政 法 人 に 準 じた 扱 いとなっている.オプトインを 実 現 するには,ユーザか ら 情 報 提 供 を 受 ける 際 に 事 前 の 同 意 を 得 ておく 方 法 もある が, 情 報 の 提 供 先 が 頻 繁 に 追 加 されることを 考 えると,IdP において, 情 報 を 送 信 する 際 に 同 意 を 得 る 仕 組 みを 提 供 す ることが 望 ましいと 考 えられる. 個 人 情 報 の 送 信 同 意 のた めには,スイスのフェデレーション SWITCHaai [22] を 提 供 する SWITCH が 開 発 した,Shibboleth IdP において 利 用 可 能 なプラグインである uapprove[23]を 利 用 することがで きる. 学 認 では, 日 本 語 に 対 応 するとともに,よりきめ 細 かな 制 御 ができるようにするために 改 良 した uapprove.jp を 提 供 している[24]. 3. フェデレーション 連 携 によるサービス 提 供 3.1 Student Identity Trust Framework 学 術 分 野 における 認 証 フェデレーションと, 民 間 商 用 サ ービスにおける 認 証 フェデレーションは,それぞれ 異 なる 機 構 をしながら 独 立 に 発 展 してきたものである.しかしな がら, 民 間 で 提 供 される 商 用 サービスの 充 実 と 高 度 化 はめ ざましく,また,クラウド 環 境 の 普 及 も 相 まって, 学 術 分 野 においても, 各 種 サービス 向 けのシステムを 自 力 で 構 築 せずに,アウトソーシングした 方 が 安 価 かつよりよいサー ビスが 実 現 できるようになってきたことから, 民 間 商 用 サ ービスを 研 究 教 育 に 採 用 する 例 が 増 加 してきている. 他 方, 民 間 サービスにおいては, 福 利 厚 生 的 利 用 を 含 め, 学 術 関 係 者 の 利 用 に 対 して 割 引 を 提 供 する 慣 例 が 古 くからあり, 割 引 をオンラインサービスにおいても 同 様 に 実 現 しユーザ を 確 保 したいという 要 望 がある.このような 背 景 から, 基 本 機 構 の 異 なる2つのフェデレーションを 技 術 的 に 接 続 し, 学 術 機 関 側 から 認 証 とユーザの 身 分 を 示 す 情 報 を 提 供 する ことにより, 割 引 を 考 慮 したサービスの 提 供 を 実 現 するこ とについての 検 討 を 開 始 した[25]. 認 証 フェデレーション は 異 なる 組 織 が 提 供 する IdP と SP とが 連 携 して 実 現 され るものであり, 相 互 の 信 頼 関 係 が 重 要 であることから,ト ラストフレームワーク(Trust Framework)とも 呼 ばれる.そ こで, 学 生 の 身 分 であることを 大 学 が 責 任 をもって 証 明 し, その 情 報 に 基 づいて 学 割 サービスを 提 供 する 試 みを, Student Identity Trust Framework (SITF)と 呼 んでいる. 3.2 SITF における 認 証 連 携 アーキテクチャ SITF における 認 証 連 携 アーキテクチャにおいては, 大 学 が IdP を 提 供 し, 民 間 サービス 側 が RP を 提 供 するモデル について 考 える. 大 学 側 は SAML ベースの 認 証 連 携 に 基 づ く IdP を 提 供 し, 民 間 サービス 側 が OpenID Connect ベース 2
の 認 証 連 携 に 基 づく RP を 提 供 することになるため,その 間 を 橋 渡 しするためのプロトコルゲートウェイが 必 要 とな る( 図 1).このプロトコルゲートウェイは,SAML 側 にお いては SP としての 役 割 を 果 たし,OpenID 側 においては OP としての 役 割 を 果 たす.また,ユーザに 関 する 属 性 情 報 の 送 信 について,OpenID 側 の RP ごとに 制 御 できるべき という 観 点 から,このプロトコルゲートウェイは,サービ ス(すなわち RP)ごとに 用 意 することを 想 定 する. 学 認 (Shibboleth/SAML) 学 認 参 加 IDプロバイダ 群 学 認 IdP 学 認 IdP 認 証 と 属 性 学 認 SP SAML/ OpenID Connect プロトコル 変 換 ゲートウェイ バックチャネルによる 認 証 非 同 期 属 性 情 報 提 供 機 能 OP (OpenID Provider) OpenID Connect 民 間 Webサービス 群 認 証 と 属 性 RP RP (Relying (Relying Party) Party) 4. プロトコルゲートウェイの 設 計 と 試 作 4.1 概 要 3 章 で 述 べた,SAML の IdP と OpenID Connect の RP の 連 携 を 実 現 するために 必 要 となるプロトコルゲートウェイ を 含 めた 全 体 の 処 理 フローを 図 2 に 示 す.SAML をベース とする 学 術 の 認 証 フェデレーションである 学 認 では, Shibboleth が 広 く 用 いられていることから,IdP は Shibboleth によるものを 前 提 とする.しかし,オリジナルの Shibboleth は,バックチャネルを 用 いた 非 同 期 の 属 性 情 報 送 信 に 対 応 していないため,プロトコルゲートウェイの 構 築 とは 別 に, SP に 対 する 拡 張 も 行 う.また, 非 同 期 の 属 性 情 報 送 信 は, ユーザの 関 知 しないところで 行 われるため,ユーザが 随 時, バックチャネルによる 属 性 情 報 の 送 信 状 況 を 確 認 するため の 機 能 を IdP に 追 加 する.さらに,その 機 能 を 用 いて,そ の 後 の 属 性 送 信 を 拒 否 することも 可 能 とする( 図 3). 認 証 利 用 者 サービス 利 用 利 用 者 (Browser) 1サービス 要 求 図 1 SAML/OpenID プロトコルゲートウェイのデザイン Figure 1 A design of SAML/OpenID Protocol Gateway 学 割 が 適 用 されるサービスにおける 課 金 方 法 としては, 次 の 2 通 りの 形 態 が 考 えられる. 1. 一 回 のサービス 利 用 ごとに 対 価 を 支 払 うもの(チケ ット 等 の 購 入 など) 2. 継 続 的 なサービスの 利 用 権 を 取 得 し, 定 期 的 に 対 価 を 支 払 うもの( 月 額 料 金 が 設 定 されたアクセスサー ビスなど) 後 者 としては, 例 えば UQ コミュニケーションズが 提 供 する モバイル WiMAX キャンパスネットワーク 接 続 サー ビス [26]のようなものが 該 当 する( 実 際 には,このサー ビスは 直 接 SAML に 対 応 する 形 で, 割 引 に 対 応 している). このような 形 態 において, 継 続 的 な 割 引 を 適 用 するため には,ユーザの 在 籍 確 認 を 定 期 的 に 行 う 必 要 がある. 毎 回 の 在 籍 確 認 のタイミングで,ユーザに 認 証 を 求 めることは 煩 雑 であることから,ユーザへの 対 応 を 求 めることなく, IdP に 対 して 在 籍 確 認 が 可 能 となる 仕 組 みが 望 まれる. SAML では,バックチャネルと 呼 ばれる,ユーザのブラウ ザを 介 さず,SP が IdP から 直 接 属 性 情 報 を 取 得 するための 機 能 が 備 わっているため,これを 活 用 する 方 法 が 考 えられ る.しかし,この 機 能 はユーザの 認 証 を 受 けて 属 性 情 報 を 取 得 する 形 態 を 想 定 しており, 有 効 期 間 が 非 常 に 短 い(1 時 間 以 下 )セッション 識 別 子 を 用 いる 方 法 を 採 っている( 以 下,この 形 態 を 同 期 型 とする). 定 期 的 な 課 金 での 在 学 確 認 のためには, 有 効 期 間 の 長 い 識 別 子 を 用 いた 属 性 情 報 の 取 得 に 対 応 する 必 要 がある.そこで,SP ごとに 生 成 される 永 続 的 なユーザ 識 別 子 である edupersontargetedid (eptid)を 利 用 した 属 性 情 報 の 取 得 に 対 応 することとした. 10サービス 開 始 9 応 答 8 応 答 6 確 認 5ID/PSWD 4 認 証 2 要 求 3 要 求 7 許 可 民 間 サービス RP (RelyingParty) SAML/OpenID Connect プロトコル 変 換 GW 学 認 IDプロバイダ IdP 図 2 プロトコルゲートウェイを 使 用 した 処 理 フロー Figure 2 Whole Flow with Proposed Protocol Gateway 利 用 者 (Browser) 5 属 性 提 供 4 属 性 提 供 民 間 サービス RP (RelyingParty) 1バックチャネル による 属 性 要 求 3 ユーザ 同 意 状 況 に 基 づく 提 供 可 否 判 断 属 性 提 供 状 況 の 確 認 SAML/OpenID Connect プロトコル 変 換 GW 2 属 性 要 求 の 転 送 (Shibboleth SP) 学 認 IDプロバイダ IdP 図 3 バックチャネルによる 属 性 送 信 状 況 の 確 認 Figure 3 Checking Status of Attribute Release with Backchannel 3
図 4 ゲートウェイにおける 処 理 のフロー Figure 4 Process flow at the Protocol Gateway 表 1 ゲートウェイに 実 装 した OpenID Connect の 機 能 Table 1 Implemented Functions in OpenID Connect 手 順 Authorization Access Token ( code ) Access Token ( refresh_token ) Check Session Userinfo 4.2 ゲートウェイ Specification 引 数 client_id: require redirect_uri: require response_type: support = token, code, id_token scope: require = openid support = edupersonaffiliation, PPID state: optional nonce: optional client_id: require client_secret: require redirect_uri: require code: require grant_type: require = authorization_code client_id: require client_secret: require redirect_uri: require refresh_token: require grant_type: require = refresh_token id_token: require access_token: require ゲートウェイでは,OpenID Connect による RP からの 要 求 を 受 け 付 け,それを SAML に 変 換 して IdP に 要 求 を 伝 え る 形 でプロトコル 変 換 を 実 現 する.ゲートウェイは,SAML IdP に 対 して, 同 期 した 属 性 情 報 送 信 と, 非 同 期 の 属 性 情 報 送 信 の 両 方 に 対 応 する. OpenID Connect における 属 性 情 報 の 取 得 は,いわゆるバ ックチャネル 的 方 式 によって 行 われる.OpenID Connect (OAuth 2.0) において 属 性 情 報 の 取 得 を 行 うには 認 証 の 結 果 返 される access_token が 必 要 となる.また,access_token と 共 に 返 される refresh_token を 用 いることで access_token の 再 取 得 が 可 能 となっている.access_token の 有 効 期 間 は 比 較 的 短 いが, 継 続 的 なアクセスを 実 現 するために, refresh_token を 用 いた 更 新 機 能 が 提 供 されている.プロト コルゲートウェイには,RP からのアクセス 頻 度 に 応 じて, 適 当 な 有 効 期 限 を 設 定 したこれらのトークンを 発 行 する 機 能 を 持 たせる. まず, 同 期 した 属 性 情 報 提 供 時 の 具 体 的 な 認 証 フローを 説 明 する( 図 4). 最 初 に,プロトコルゲートウェイでは 受 け 取 った RP からの OpenID Connect による Authrization 要 求 を SAML の Authrization 要 求 にプロトコル 変 換 を 行 い, SAML の IdP に 対 する 認 証 を 要 求 する.SAML の 認 証 が 完 了 しアサーションを 受 け 取 ると,それに 含 まれる 属 性 情 報 を 保 持 した 上 で,RP には OpenID Connect の Authrization 応 答 として code と id_token がユーザのブラウザを 経 由 して 返 される( 今 回 の 実 装 では response_type として code id_token を 指 定 している).RP は, 受 け 取 った code と 登 録 済 みのク ライアント 情 報 に 含 まれる Token エンドポイントを 用 いて access_token と refresh_token,および eptid に 対 応 するユー ザ 識 別 子 である PPID (Pairwise Pseudonymous Identifier)を 取 得 する.さらに RP では,OpenID Connect の Check Token エンドポイント(OpenID Connect の 現 仕 様 には 含 まれない 独 自 機 能 )により id_token を 検 証 することで 正 しい 接 続 で ある 事 を 確 認 する.RP が access_token を 正 しく 取 得 できた ならば, 後 は OpenID Connect の UserInfo エンドポイントよ り 属 性 を 取 得 することで 処 理 が 完 了 する.UserInfo エンド ポイントを 用 いた 操 作 以 降 は OpenID Connect( 正 確 には OAuth 2.0)の 標 準 的 な 操 作 である. 一 度,ゲートウェイが IdP に 対 して 認 証 を 行 った 後 は, ゲートウェイにおいて 取 得 したトークンと 対 応 する eptid をデータベースに 保 存 しておくことで,その 後 の 非 同 期 な 属 性 情 報 取 得 に 備 える.RP より access_token(さらに 必 要 に 応 じて refresh_token による access_token の 再 取 得 )を 用 いた 非 同 期 の 属 性 情 報 取 得 要 求 が 来 れば,ユーザ 認 証 なし に 属 性 情 報 の 取 得 が 可 能 になる. IdP においては, 非 同 期 の 属 性 情 報 取 得 を 実 現 するため に,ePTID を 識 別 子 とした 属 性 情 報 の 取 得 に 対 応 するよう 設 定 を 行 う.これについては, 既 存 の Shibboleth IdP におい て 設 定 の 調 整 のみで 対 応 可 能 である. 今 回 の 実 装 では,access_token の 有 効 期 限 は 1 時 間 とし ている. 一 方,refresh_token の 有 効 期 限 はある 程 度 長 くと る 必 要 があるため, 今 回 はデフォルトで 32 日 間 としている. これは,サービス 登 録 時 に 指 定 することで 変 更 可 能 となっ ている. 4
今 回 のゲートウェイ 実 装 は,Ruby 1.9.2p290,Rails 3.2.12, SQLite 3.6.20 を 用 いて 構 築 した.OpenID Connect の 仕 様 の うち 実 際 に 実 装 したものを 表 1 に 示 す. 4.3 バックチャネル 属 性 要 求 ハンドラ プロトコルゲートウェイは,SAML における SP の 機 能 を 持 ち, Shibboleth SP を 利 用 して 構 築 しているが, Shibboleth 標 準 の SP では,バックチャネルによる 非 同 期 な 属 性 情 報 取 得 のためのハンドラ(インタフェース)を 持 た ないため,プロトコルゲートウェイの 一 部 として 呼 び 出 す ことが 可 能 な, 属 性 情 報 要 求 ハンドラを 新 たに 用 意 した. 属 性 情 報 要 求 ハンドラは 既 存 の 他 の Shibboleth SP のハン ドラと 同 様 に, 以 下 に 示 すような URL をハンドラのパス としてアクセスすることで 呼 び 出 される.このパスは, 設 定 ファイル shibboleth2.xml の<Handler> 要 素 内 の Location 属 性 にて 変 更 可 能 である. https://sp.example.ac.jp/shibboleth.sso/attributequery?entity ID=https%3A%2F%2Fidp.example.ac. jp%2fidp%2fshibboleth&nameid=xxxxxxxxxxxxxx XXXXXXXXXXXXX%3D 属 性 情 報 要 求 ハンドラは,IdP に 対 する AttributeQuery を 行 うにあたり, 表 2 に 示 すパラメータを 受 け 取 る. 表 2 属 性 情 報 要 求 ハンドラが 受 け 取 るパラメータ Table 2 Parameters of handler for AttributeQuery パラメータ protocol 内 容 メタデータのIdP Role で 設 定 されている protocolsupportenumerationの 値 entityid IdPのentityID( 必 須 ) format SAMLのユーザ 識 別 子 のフォーマット nameid SAMLのユーザ 識 別 子 (eptid, 必 須 ) 属 性 情 報 要 求 ハンドラは, 以 下 に 示 す 要 領 で 処 理 を 行 い 応 答 を 返 す. 1. entityid で 指 定 された IdP に 対 して nameid に 紐 付 けら れたユーザに 関 する AttributeQuery を 行 い,SAML Response を 受 け 取 る. 2. SAML Response に 含 まれる AttributeStatement を JSON 形 式 に 変 換 する.JSON オブジェクトのキーおよび 値 は, attribute-map.xml および attribute-policy.xml の 定 義 に 従 う.もし,AttributeStatement が 含 まれていない 場 合 は, 空 の JSON({})とする. 3. 一 つの 属 性 が 複 数 の 属 性 値 をもつ 場 合 は, 属 性 値 をセ ミコロン(;)で 連 結 する. 4. 属 性 値 自 身 にセミコロン(;)が 含 まれる 場 合 は, 上 述 の 区 切 りのセミコロンと 区 別 するために,バックスラッ シュ( )でエスケープする. 5. 得 られた JSON オブジェクトをハンドラのレスポンス として 返 す. 表 3 ユーザに 対 して 求 める 同 意 の 選 択 肢 Table 3 Choices of User Consent for Release of Attributes 種 別, 略 称 メッセージ (a) 毎 回 確 認 (b) 保 存 する (c) 表 示 しない サービスに 送 信 する 情 報 を 毎 回 確 認 します. 今 回 は 情 報 を 送 信 することに 同 意 します. 次 回 からこのサービスではこの 画 面 を 表 示 しま せん. 今 後 このサービスに 対 して 同 一 の 情 報 を 自 動 的 に 送 信 することに 同 意 します. この 画 面 をもう 表 示 しません.ユーザ 情 報 を 今 後 すべてのサービスに 対 して 自 動 的 に 送 信 するこ とに 同 意 します. 送 信 する 情 報 は 表 示 以 外 のもの を 含 む 可 能 性 があります. 表 4 非 同 期 の 属 性 情 報 送 信 を 考 慮 した 同 意 選 択 肢 の 表 現 Table 4 Revised Choice of (b) to Support Asynchronous Back-channel Attribute Query 種 別, 略 称 メッセージ (b) 保 存 する 次 回 からこのサービスではこの 画 面 を 表 示 しま せん. 属 性 情 報 に 変 化 がない 限 り, 今 後 このサー ビスに 対 して 今 回 と 同 一 の 情 報 を 自 動 的 に 送 信 することに 同 意 します.また,サービスからの 問 合 せに 対 しても, 今 回 と 同 一 の 情 報 を 自 動 的 に 送 信 することに 同 意 します. 4.4 バックチャネルによる 属 性 送 信 を 考 慮 したユーザ 同 意 の 取 得 IdP における 属 性 情 報 送 信 に 関 してユーザの 同 意 を 得 る ためには,IdP のプラグインである uapprove を 利 用 するこ とができる.しかし,このプラグインはユーザ 認 証 と 同 期 した 属 性 情 報 の 送 信 にしか 対 応 していないため, 非 同 期 の 属 性 情 報 送 信 を 考 慮 した 同 意 の 選 択 肢 を 用 意 するとともに, ユーザによる 選 択 に 対 応 した 属 性 情 報 の 送 信 機 能 を 提 供 す る 必 要 がある. 既 存 の uapprove をそのまま 利 用 すると, 送 信 先 として 同 意 していない SP からの 要 求 に 対 しても 応 答 を 返 してしまうという 問 題 がある. ユーザに 対 して 提 示 する 選 択 肢 は, 既 存 の uapprove を 日 本 語 対 応 した uapprove.jp においては 表 3 に 示 すような 内 容 となっている.このうち(b)について, 非 同 期 の 属 性 情 報 送 信 を 考 慮 した 表 現 に 改 めた( 表 4). ユーザが(a) を 選 択 した 場 合,ユーザが 同 意 した 属 性 情 報 は 同 期 したログイン 時 にだけ 送 信 され,AttributeQuery への 応 答 では 一 切 の 属 性 を 送 信 しない. 従 って, 非 同 期 の 5
属 性 情 報 送 信 を 用 いるサービスは 利 用 できない.(b) を 選 択 した 場 合, 送 信 に 同 意 した 属 性 情 報 は 将 来 の 照 合 のため に,ストレージに 保 存 される. 送 信 を 同 意 した SP からの 属 性 情 報 要 求 があった 際 に, 保 存 してある 属 性 情 報 と 比 較 を 行 い, 一 致 しているものについてのみ,SP に 応 答 する. これは, 取 得 した 最 新 の 属 性 値 がユーザの 同 意 した 時 点 の 属 性 値 と 異 なっている 場 合,ユーザが 送 信 に 同 意 した 情 報 とは 見 なせないためである.このような 場 合 は,ユーザが 次 回 のログイン 時 に 再 同 意 しない 限 り, 変 更 のあった 属 性 の 属 性 情 報 を 提 供 することができない.IdP 側 における 非 同 期 の 属 性 情 報 送 信 では,このような 形 でプライバシー 保 護 に 配 慮 する. なっている.また,すべての 同 意 を 一 括 で 取 消 すた めのボタンも 用 意 している. 表 5 属 性 情 報 送 信 状 況 としてユーザに 提 示 される 情 報 Table 5 Information Shown as Status of Released Attributes 項 目 値 サービス 名 エンティティID 属 性 送 出 同 意 日 時 バックチャネルによる 最 新 属 性 取 得 日 時 バックチャネルによる 属 性 取 得 回 数 文 字 列 文 字 列 日 時 日 時 数 値 4.5 属 性 情 報 送 信 状 況 の 確 認 機 能 非 同 期 での 属 性 情 報 送 信 では,ユーザに 属 性 情 報 が 送 信 されるタイミングが 分 からないことから,ユーザが 定 期 的 に 属 性 情 報 の 送 信 状 況 について 確 認 できる 手 段 を 別 途 提 供 することが 望 ましい. 本 試 作 では, 属 性 情 報 の 提 供 状 況 の 確 認 のために,IdP 上 にユーザが 参 照 可 能 な 属 性 送 信 済 み SP 一 覧 ページを 用 意 した. 属 性 送 信 済 み SP 一 覧 ページは,IdP 上 に,SP と しての 機 能 として 実 現 しているため,ユーザが IdP におい て 認 証 を 要 求 されるタイミングではなく, 直 接 当 該 ページ にアクセスする 形 で 参 照 することができるようになってい る. 実 装 としては,IdP のプラグインではなく,JSP による 独 立 したアプリケーションとなっている.このページは, この SP には 当 該 IdP にアカウントを 持 つユーザのみしか アクセスしないため, 認 証 フェデレーションには 参 加 する 必 要 はない. ユーザに 提 示 される 情 報 を 表 5 に 示 す.サービス 名 は entityid やメタデータに 定 義 されたサービスの 表 示 名, 属 性 送 出 同 意 日 時 はユーザが 属 性 を 自 動 的 に 送 信 することに 同 意 して 送 信 ボタンを 押 したときの 時 刻,バックチャ ネルによる 最 新 属 性 取 得 日 時 および 属 性 取 得 回 数 は,SP が IdP の AttributeQuery プロファイル 用 いて 属 性 情 報 を 取 得 したときの 時 刻 と,その 通 算 回 数 を 示 す. 表 示 対 象 とな る SP は, 前 述 のユーザ 認 証 時 の 属 性 情 報 送 信 同 意 の 選 択 肢 において, (b) 保 存 する または (c) 表 示 しない を 選 択 したものとなる. (c) 表 示 しない を 選 択 し た 場 合 は, 個 別 の SP 名 ではなく すべてのサービス としてまとめられた 1 件 だけが 表 示 される. (a) 毎 回 確 認 を 選 択 した 場 合 は,バックチャネルによる 属 性 送 信 には 同 意 していないことになるため, 一 覧 には 表 示 されない.IdP では,これらの 情 報 をユーザに 提 供 するために,データベースにアクセス 記 録 を 格 納 する. 属 性 送 信 済 みSP 一 覧 ページには, 表 示 したSP ご とに, 同 意 を 取 り 消 すための 削 除 ボタンが 用 意 され ており, 個 々のSPごとに 同 意 を 取 消 すことが 可 能 と 5. おわりに 本 報 告 では,SAML を 用 いて 認 証 連 携 を 行 う 学 術 フェデ レーションと,OpenID を 用 いて 認 証 連 携 を 行 う 民 間 のフェ デレーションとが 連 携 し, 学 術 機 関 が 提 供 するユーザに 関 する 属 性 情 報,その 中 でも 特 に 身 分 ( 学 生, 教 員, 職 員 等 ) の 情 報 を 活 用 して, 民 間 による 学 割 サービスを 提 供 するた めの 仕 組 みを 設 計 し 試 験 実 装 を 行 った. 認 証 フェデレーシ ョンの 枠 組 みを 活 用 することで,ユーザの 自 己 申 告 によら ない 確 実 な 情 報 を 提 供 することができ,サービス 提 供 側 も 安 心 して 割 引 等 の 措 置 を 実 施 することが 可 能 となる. 提 供 される 情 報 はプライバシーにもかかわるものとなる 可 能 性 もあるため,このような 連 携 を 実 現 する 際 に 義 務 づけられ るポリシーについても 平 行 して 検 討 し, 実 サービスの 実 現 につないでいきたいと 考 えている. 謝 辞 本 報 告 の 内 容 は, 総 務 省 戦 略 的 国 際 連 携 型 研 究 開 発 推 進 事 業 ( 平 成 24 年 度, 情 報 セキュリティに 関 する 研 究 開 発 課 題 の 委 託 )による 支 援 を 受 けて 情 報 流 通 連 携 の ためのオープンな ID 連 携 プラットフォームにおけるプラ イバシー 保 護 機 能 の 高 度 化 の 研 究 開 発 として 実 施 したも のの 一 部 である. 参 考 文 献 1) 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. 2) OpenID Foundation, OpenID Foundation website, http://openid. net/, last visited Apr. 1, 2013. 3) REFEDS (Research and Education Federations), REFEDS Federation Survey, https://refeds.terena.org/index.php/federations, last visited Apr. 1, 2013. 4) 西 村 健, 中 村 素 典, 山 地 一 禎, 大 谷 誠, 岡 部 寿 男, 曽 根 原 登 : 日 本 における 学 術 認 証 フェデレーションとその 役 割 および 効 果, 信 学 技 法, Vol. 111 No. 375, IA2011-55 pp.5-8, 2012. 5) 島 岡 政 基, 西 村 健, 古 村 隆 明, 中 村 素 典, 佐 藤 周 行, 岡 部 寿 男, 曽 根 原 登 : 学 術 機 関 のためのサーバ 証 明 書 発 行 フレームワーク (ネットワーク 管 理 オペレーション, < 特 集 > 若 手 研 究 者 のための フロンティア 論 文 ), 電 子 情 報 通 信 学 会 論 文 誌, Vol.J54-B, No.7, 6
pp.871-882, 2012. 6) OpenID Foundation, Surprise! You may already have an OpenID, http://openid.net/get-an-openid/, last visited Apr. 1, 2013. 7) Google Apps for Education, http://www.google.com/intl/ja/ enterprise/apps/education/, last visited Apr. 1, 2013. 8) マイクロソフト, Office 365 導 入 事 例, http://www. microsoft.com/ja-jp/office/365/showcase.aspx, last visited Apr. 1, 2013. 9) Yahoo! Japan, Yahoo!メール Academic Edition, http://business. yahoo.co.jp/ymacademic/, last visited Apr. 1, 2013. 10) M. Wahl, T. Howes, S. Kille, Lightweight Directory Access Protocol (v3), The Internet Society, RFC2251, 1997. 11) Shibboleth Consortium, http://shibboleth.net/, last visited Apr. 1, 2013. 12) SimpleSAMLphp, http://simplesamlphp.org/, last visited Apr. 1, 2013. 13) 国 立 情 報 学 研 究 所, 学 術 認 証 フェデレーション システム 運 用 基 準 (Ver.1.2), 2011. 14) Internet2, eduperson & eduorg Object Classes, http://middle ware.internet2.edu/eduperson/, 15) OpenID Foundation, OpenID Authentication 2.0 - Final, 2007. 16) OpenID Foundation, OpenID Attribute Exchange 1.0 Final, 2007. 17) D. Hardt, Ed., The OAuth 2.0 Authorization Framework, RFC6749, Internet Engineering Task Force (IETF), 2012. 18) OpenID Foundation, Welcome to OpenID Connect, http://openid.net/connect/, last vidited Apr. 1, 2013. 19) Yahoo! Japan, YConnect(OAuth2.0/OpenID Connect)をリリー スしました!, http://techblog.yahoo.co.jp/web/auth/yconnect/, 2012. 20) 総 務 省, 個 人 情 報 の 保 護 に 関 する 法 律, 法 令 データ 提 供 シス テム, http://law.e-gov.go.jp/htmldata/h15/h15ho057.html, 2003. 21) 総 務 省, 独 立 行 政 法 人 等 の 保 有 する 個 人 情 報 の 保 護 に 関 する 法 律, 法 令 データ 提 供 システム, http://law.e-gov.go.jp/ htmldata/h15/h15ho059.html, 2003. 22) L. Hämmerle, "SWITCHaai: shibboleth-based federated identity management in Switzerland," Proceedings of CESNET 2006 Conference, 2006. 23) The SWITCH Foundation, "uapprove," http://www.switch.ch/aai/ support/tools/uapprove.html, last visited Apr. 1,2013. 24) Tananun Orawiwattanakul, Kazutsuna Yamaji, Motonori Nakamura, Toshiyuki Kataoka, Noboru Sonehara: User Consent Acquisition System for Japanese Shibboleth-based Academic Federation (GakuNin), International Journal of Grid and Utility Computing (IJGUC), Vol. 2, No. 4, pp. 284-294, 10.1504/IJGUC.2011.042944, 2011. 25) 国 立 情 報 学 研 究 所, 産 学 の ID をつなぐ 世 界 初 のトラストフ レームワークの 研 究 に 着 手 ~ 利 用 者 情 報 の 安 全 な 流 通 を 目 指 し, 学 生 向 けサービスの 提 供 を 支 援 ~, http://www.nii.ac.jp/ news/2011/0305/, 2012. 26) UQ コミュニケーションズ, モバイル WiMAX キャンパスネ ットワーク 接 続 サービス, http://www.uqwimax.jp/service/corporate/ campusconnect.html, last visited Apr. 1, 2013. 7