特集

keio.jp認証システムの大幅改修について

慶應義塾の認証基盤であるkeio.jpは、しばしば大小様々な改修を加えられているが、2016年度中には2014年まで利用されていた旧keio.jpシステムからのシステム移行に関連する、大きな改修が行われた。

2014年に、慶應メールがDeepMailからGoogle Apps（現G Suite）に移行する際に、認証システムも独自システムからShibboleth IdPに移行した。

ただし、旧システム上で動作していた多数のシステムを、一気に新システムに移行することは難しかった。様々な部署が開発した旧システム対応の全てのアプリケーションを、タイミングを合わせて一気に新システムに移行することは技術的に困難であり、また改修予算の観点から見てもかなり難しい。

そこで、2014年のシステム移行時に、旧keio.jpにおいてシングルサインオンの機能を提供していた旧ポータルサイトの機能の一部と、そのバックエンドとなっていた旧keio.jpのデータベース、認証用のAPIサーバ等をまとめて、新keio.jpであるShibbolethのアプリケーションとして再構築した。これによって、旧システム対応のアプリケーションをほとんど改修することなしに、新keio.jp認証への対応が可能となった。

この移行手法に関しては、大学ICT推進協議会（AXIES）2016年度年次大会で発表したため、詳細はその資料を参照していただきたい（資料はhttps://reg.axies.jp/pdf2016/WD15.pdfで公開されている）。

ただし、この対応に関しては、旧keio.jpのデータベースをそのまま残置したため、それらのデータをメンテナンスする処理などが、システムを複雑化していたりするなどの問題があった。

特に旧keio.jpで利用されていたユーザ管理用のIDと、新keio.jpのユーザ管理用に用いられているID（ITCアカウントの管理番号）の体系が全く異なることや、アカウントの有効無効を判断するパラメータの扱いなどが異なっていることなどが、特にシステムを複雑化しており、ユーザ管理上の問題を発生させる原因の一つとなっていた。さらに、この旧keio.jpアプリをサポートする仕組みでは、提供されるシングルサインオンの機能が限られることや、この機能を用いるアプリ全てが、認証システムからは1つのアプリとして見えてしまう点も問題であったため、できるだけ早い移行を考えていた。

しかし、本来の移行期限の3ヶ月近く前である2016年10月に調査を行った所、この機能を用いたアプリケーションが未だ20以上残っていた。これにはITC内部で開発したアプリケーションも、他部署が開発したアプリケーションも含まれていたが、2017年1月末までの移行を目指し、ITC内部開発のアプリに関しては早急な移行を促し、他部署に関しては移行に関する支援を強化することとした。

その結果、本来の予定から1ヶ月以上遅れたものの、2017年3月3日までにすべてのアプリケーションの移行が完了した。keio.jpのユーザ管理システムから旧keio.jpの切り離しが2017年3月13日に行われ、ユーザ管理のロジックが大幅に単純化されることで、問題発生の可能性を大幅に下げることができた。また、旧keio.jpのシステムを実現していた多くのサーバを停止することで、システム構成も大幅に単純化された。

このように、2014年の認証システム更新から2年3ヶ月をかけて、旧keio.jp対応アプリの全てを徐々に新keio.jpに移行することが可能となった。これは、同様に多くのアプリケーションから利用されているインフラシステムを更改するときにも応用できる手法であると考えられる。反省点としては、最後の数ヶ月に作業が集中しすぎてしまったことだが、今後同様のシステム更改を行う際には、もう少しこまめに、ITC内および各部署での作業状況を把握・管理するべきであろう。