特集
 | 慶應義塾ITC

## 学術認証フェデレーション（学認）への慶應義塾大学の参加

ITC本部　細川 達己

##### 学術認証フェデレーション

近年、教育・研究組織における認証システムのデファクトスタンダードとしてShibbolethというシステムが広く利用されており、これを用いて各国で多数の教育・研究組織による「認証フェデレーション」が組織されている。

この「認証フェデレーション」とは、共通のポリシーに同意した管理を行う認証システムを提供する多数の組織が、それらの認証システムで乗り入れが可能なサービスを共有する枠組みである。サービス提供側は、その共通ポリシーの運用を信用してサービスを提供する。

日本では、国立情報学研究所を中心とした「学術認証フェデレーション」（以下、学認）が、教育・研究組織における認証フェデレーションの代表である。多くの電子ジャーナル等がこのシステムで利用できるようになっていることなどから、義塾の学認の参加に関しては以前から多くの要望があった。

##### 義塾における認証システムの沿革

慶應義塾における認証システムは、2005年に導入されたkeio.jpで、一応「特定のサービスやキャンパス・学科などに依存しない」ものとなっていたが、標準技術を用いていないためにアプリケーションの作成が難しく、またパッケージソフトのサポートなどが期待できないなどの問題点があった。ユーザの視点から見ても、ボタンクリック以外の手段でシングルサインオンを実現できないなど、多くの問題を抱えていた。

また、PC室の認証は2011年のITCアカウントの導入によって全キャンパスで統一された（ただし湘南藤沢キャンパスではSFC-CNSアカウントが主に利用されており、ITCアカウントはほとんど利用されていない）が、このITCアカウント認証は、技術的な問題で結局keio.jpとは別体系のものとなった。

このような経緯から、義塾の統合認証システムを標準技術で再構築することや、ITCアカウント・SFC-CNSなどとの将来的な関係などは、大きな課題となっていた。

##### 認証システム更新計画と学認

ITCアカウントが軌道に乗った2011年度後半から、認証システムの再構築に関する具体的な動きがITC内で始まった。そして学認への参加は、義塾の認証システムをよりよい姿に持っていくための試験的な実装としての位置づけとなった。

まず、keio.jpの最大の問題点の一つとしてITC内で認識されていたのは（ユーザからは見えにくいが）ユーザ属性データの持ち方であり、これはITCアカウントのシステム構築時に大きな改良がなされていた。そのため、2011年度の時点では、新認証システムの基本的なデータはITCアカウントとなり、ログインもkeio.jpのアカウントではなくITCアカウントでログインすることを想定していた。

もちろん、ある日突然keio.jpのアカウントでログインできなくなり、以後ITCアカウントでログインして欲しい、というような移行を行った場合、大きな混乱が予想される。そのため現行のkeio.jpのシステムをITCアカウントでもログインできるような改修を行うことで、新システムへの移行をスムーズに行うことなどが検討された。

##### アカウントエイリアス化機能の開発

ところが、学認の認証を提供するIdP（Identity Provider）の開発中に、そのような移行をする必要がないことがわかってきた。学認が利用している認証システムであるShibbolethにおいては、ユーザを識別するIDにいくつかの種類がある。

ログインに利用するID（uid）： ログイン画面でユーザが入力するID。
フェデレーション内固有ID（ePPN）：フェデレーション内部で一意にユーザを識別するID。IdPがユーザに割り当てる。
アプリケーション固有ID（ePTID）：フェデレーションとサービスという組み合わせ内で一意にユーザを識別するID。IdPがユーザに対してサービス毎に別のIDを割り当てる。サービス間での名寄せは不可能であり、高いプライバシーを実現できる。

多くのShibboleth利用組織では、uidとePPNには同じ文字列を割り当てているが、そのようにしなくてはならないという規則はない。また、Shibbolethは同一ePPNに対して複数のuidが対応することを禁止していない。

このことを利用すると、「次期システムではITCアカウントのみでのログインとなる」ことを前提とするのとは別の方法で、アカウントの乗り入れを実現することができる。つまり、同じePPNに対する複数のuidとして、keio.jpのIDとITCアカウントのIDを位置づければよい。

このようなシステムを構築することで、以下の特徴を実現できる。

ユーザは、keio.jpのIDとITCシステムのIDの双方でログインすることができる。
どちらでログインしても、サービスには同一のePPNもしくはePTIDが渡されるため、サービスからは同一ユーザであると認識される。

この仕組みを、アカウントのエイリアス化と呼ぶこととした。

##### SFC-CNSのID乗り入れ

この仕組を用いることで、他のIDを取り込むことも可能となる。その候補として第一に考えられるのはSFC-CNSアカウントである。

湘南藤沢キャンパスでは学生・教員共に、keio.jpやITCアカウントよりもSFC-CNSアカウントを中心に生活しており、keio.jpアプリケーションの一部は個別にSFC-CNSアカウントで認証できるように改修されている。SFC-CNSを次期共通認証システムのテストベッドでもある学認の認証システムに取り込むことは、次期共通認証システムに対応した全てのアプリケーションにおいて、改修なしでSFC-CNSアカウントでの認証が可能となることを意味する。

以上のID体系の全体を図に示すと次のようになる。

ログイン用ユーザ名としてkeio.jpアカウント、ITCアカウント、SFC-CNSアカウントの3つが利用可能であり、そのどれでログインしても共通のePPNが得られる。そしてサービス毎にePPNとサービスIDから生成されるePTIDが割り当てられるが、これもどのuidでログインしたかに依存しない。つまり、アプリケーションからはどのuidでログインしたかに関わらず、必ず同一ユーザであると扱われることとなる。

##### Shibboleth用LDAPサーバの開発

これらの複雑な情報を高頻度で安定して更新するため、Shibblethのバックエンドとして必要となるLDAPサーバも、OpenLDAPの標準的なBDBバックエンドではなく、SQLバックエンド（back-sql）を採用した。一般的にback-sqlは性能面に問題が多いと言われるが、大幅なチューニングを施した結果、問題ない性能で動作させることができるようになった。

現行のkeio.jp、ITCアカウントやSFC-CNSなどのデータを元に、このSQLバックエンドにデータを投入するID連携システムは今回独自に開発を行った。この中で、ウエイトフリーなパスワード更新の高速同期や、高速全件更新など、さまざまな機能を開発した。

##### Shibbolethサーバの構築

Shibbolethサーバには、外部サーバに個人属性を渡す際に許可を求めるプラグインであるuApprove.jpを追加し、個人情報の流れをユーザに対して可視化した。

また、MicrosoftのDreamsparkのように、ライセンス的には学生のみが利用可能であるにもかかわらず、教職員も利用できてしまう一部のサービスに関しては、FPSP（Filter Per Service Provider）というプラグインを入れることで対応した（配布状態では致命的なバグや仕様の問題点が多かったので、独自の改良版を利用している）。

##### 学認への加入

以上のようなシステムを整えて、2014年2月に学認への加入申請を行い、認められた。ただし、学認への加入資格は大学などに限定されたものとなるため、慶應義塾としての加入ではなく、慶應義塾大学としての加入となった。関連規程の整備や関連部署との調整を行った上で、平成26度中の公開を予定している。

##### 結論

今回の学認への参加は、今後の義塾における新認証システム開発におけるテストケースとしての位置づけとなっており、アカウントのエイリアス化や独自のID連携システムを始めとする、今後につながる様々なシステムの開発がなされた。

なお、より詳細な技術的内容で公開可能なものを以下のURLにまとめている。
「学認|慶應義塾ITC本部・技術メモ」 http://memo.itc.keio.ac.jp/blog/?cat=4