MediaNet No.17（2010.11）〈特集〉KOSMOS Ⅲ―新図書館システムの導入―：第 2 部

KOSMOS―keio.jp 認証連携と認証サービスの今後
たなべみのる田邊稔（メディアセンター本部課長代理）

1 keio.jp 認証サービスと My Libraryと keio.jp が直接連携する形ではなく，先行事例としこれまで，図書館が提供する keio.jp 認証サービスて実績のあ る EJ!
DB リ モ ー ト ア ク セ ス（以 下。

としては，『図書利用状況照会』と『EJ!
DB リモートKRAS）のサーバが仲介する方式を採用した。おかげアクセス』の 2 つがあった。今回の『KOSMOS Myで，インフォメーションテクノロジーセンター（以Library』は，第 3 のサービスというよりも，図書利下。ITC）・メディアセンターとも効率よく開発する用状況照会の機能拡張版サービスという位置づけことができた。なお，PDS⇔KRAS⇔keio.jp 間はすべに近い。図書利用状況照会では，自分の貸出・予約・て SSL 通信とし，経路上セキュアな通信を確保する未収金の状況を照会するだけのサービスだったが，こととした。

My Library では，利用者自らがリアルタイムで予約・更新（貸出期限延長）できる機能が加わった。
KOSMOS を開始した 4 月以降，My Library 経由で3 PDS と keio.jp との連携ポイント
まず，KOSMOS の認証サービスへ入る基本導線の予約・更新の利用数が急速に伸びたことから考えを以下の 4 つと想定した。ても，利用者が長年待ち望んでいた機能であったこ（1）KOSMOS トップの「ログイン」ボタンからとが分かる（図 1）。さらに，認証さえ受けていれば，（2）KEIO-OPAC 書誌一覧の「リクエスト」リンクタグやレビューなども登録できる。もう一つ大きな違いは，従来の 2 つのサービスと異なり，慶應 IDを持っていなくとも，図書館に利用者登録を行い，から（3）図書館 HP やお気に入り（ダイレクトリンク）
からID!
Password を取得すれば，サービスを利用できる（4）keio.jp のアプリケーションメニューからという点である。

今回の実装に際し，最大のポイントだったのは，「慶應 ID 保持者と慶應 ID 非保持者へのシームレス

2 PDS の機能とセキュリティの確保な対応」
である。つまり，慶應 ID を持っている人にEx Libris（以下。E 社）の Primo パッケージに標も，持っていない人にも，同じ認証画面，同じ画面

準 装 備 さ れ て い る『PDS（Patron Directory Serv-遷移でサービスを提供することを我々の最重要課題ice）』には，Aleph パッケージの利用者データ（Pa-と捉えた。そのため，E 社への基本要件として，以下tron）と直接連携できる独自の認証機能の他に，の 2 つを提示した。

「Remote-LOGIN」や「Remote-SSO」と呼ばれる機能（1）認証ログイン画面は慶應側が提供するものとがあり，外部の認証サービスと連携することができし，慶應 ID 保持者用と非保持者用を共通のる。但し，セキュリティの観点から，KOSMOS（PDS）ものとする。

図 1.

更新/予約
［カウンター vs Web（My Library）経由］統計の推移

37

MediaNet No.17（2010.11）〈特集〉KOSMOS Ⅲ―新図書館システムの導入―：第 2 部

図 2.

My Libary の認証フロー（2）図書館システム側では慶應 ID を保管しないこと。
慶應 ID は ITC が管理する ID であるため，入力ことだ。そもそも，OPAC 端末は強固にフィルターされており，蔵書検索以外何もできない（させない）極端に自由度の低い端末 である。そこに，認証サーされた ID!
Password を一時的にせよ，図書館システビスを載せることは，当然ながらム上を通過することも，保管することも許されるもい込んでいた。しかし，ITC に相談したところ，ITCのではない。そのため，ITC が用意した keio.jp ログ

端末でも ITC アカウントで認証利用させているこ

イン画面を使うことを必須要件とした。但し，ログともあり，きちんと利用指導を行い，システム面・イン画面は共通でも，慶應 ID でログインされた場運用面でリスクをカバーできるのであれば，問題な合と非慶應 ID（図書館利用者 ID）でログインされたかろうとの見解だった。

御法度だと思場合では，裏側の仕組みは大きく異なる。この実装

OPAC 端末で認証サービスを提供するにあたり，にはかなり手を焼いたが，具体的な実装方法として最大の問題となったのが，「サービス利用後，いかには，大きく下記の通りとなる。
（図 2）

ログアウトしてもらうか」と「ログアウトされなかっ（1）入力された ID 体系で判別する。

た場合のリスクをどこまで最小化できるか」という（2）慶應ID体系の場合は，keio.jpに認証を要求する。

ことだった。そこで工夫したこととして，運用面で（3）それ以外（図書館利用者 ID）の場合は，X-はログアウトを促すために，端末そのものに大きくService の認証 API を使って，Aleph 利用者「利用後は必ずログアウトしてください。
ログアウト情報に直接認証を要求する。

しない場合，誤って次の利用者があなたの ID を（4）認証エラー処理は，（2）と（3）それぞれで行う。

使ってしまう恐れがあります。
」といった注意喚起の（5）認証通過後の動きは，（2）と（3）で共通とする。

シールを張ることにした。システム面では，3 分間未操作状態の場合に端末を自動ログアウトする仕掛け

4 KOSMOS ログイン端末の誕生
今回の keio.jp 連携でもう一つ大きな進展があっを作った。もちろん，未ログイン状態で 3 分間の間に次の利用者が飛び込んだ場合のリスクはあるが，たのは，従来の OPAC 端末が「蔵書検索に特化したそれは一種の専用端末」という位置づけだったものが，館や設置開始するに至った。

ゾーンによっては，ログイン認証して予約・更新ができる端末「KOSMOS ログイン端末」を用意できた

38

事故と割り切ることとし，運用をMediaNet No.17（2010.11）〈特集〉KOSMOS Ⅲ―新図書館システムの導入―：第 2 部

図 3.

今後の認証サービスく，慶應内のサーバにモジュールを置くモデルか，5 認証サービスにおける今後の課題
最後に，認証サービスとしての今後の課題を 5 点ほど掲載する。

API 化して提供する必要がある。
5）電子学術書利用実験プロジェクトとの連携

1）中継サーバの信頼性向上

現在進行中の「電子学術書利用実験プロジェクト」

KOSMOS My Library と keio.jp と の 連 携 にについて，2010 年 12 月より利用実験を開始する予

KRAS を中継させることで，KRAS そのものの役割定である。利用範囲を慶應所属者に限定したり，コが重要となり，サーバの強化が急務となっている。

ンテンツ利用ログを取得するなど，本人認証が必須

具体的には，もう 1 台ミラーセットを用意し，最低となるため，KOSMOS⇔keio.jp⇔電子書籍アプリの限コールドスタンバイ構成を取り，万一の場合，最連携を実装する必要がある。

短のダウンタイムで切り替えられるよう，構築を急ぐ予定である。

注2）keio.jp への図書館サービスの見せ方

1）「学術認証フェデレーション（愛称：GakuNin）」とは，学現状，keio.jp ログイン後のアプリケーション一覧

術 e―リソースを利用する大学，学術 e―リソースを提供には「KOSMOS My Library」という 1 つのアプリとする機関・出版社等から構成された連合体のこと．各機して実装しているが，今後，キラー的なアプリは「粒」

関はフェデレーションが定めた規程（ポリシー）を信頼で見せるなど工夫が必要だと思われる。

しあうことで，相互に認証連携を実現することが可能と

注1

3）『学認（愛称：GakuNin）』 との連携Primo の PDS や KRAS の EZproxy
leth

注3

注2

なる．

は，Shibbo-

2） 「サイト契約の電子ジャーナルを遠隔地から利用させ認証にも対応しているため，数年後には NII-る」という目的に特化して開発されたソフト．現在はUPKI が提供している GakuNin と連携したコミュニティサービスを実装することになろう。
（図 3）4）モバイル版 OPAC からの予約・更新
現在，携帯電話向けのモバイル版 KOSMOS（参照系のみ）は外部 ASP にて提供しているが，今後，認OCLC が販売，維持管理している．
3） 米国 EDUCAUSE!Internet2 にて 2000 年に発足したプロジェクトで，SAML，eduPerson 等の標準仕様を利用した認証・認可のための標準仕様策定とオープンソース提供を行っている．

証付きサービスを載せるためには，ASP 版ではな

39