特集

新義塾基盤認証システム（keio.jp）の構築とサービス開始について

旧keio.jpの抱えていた問題と改善要望

2005年に、慶應義塾はkeio.jpと呼ばれる認証システムを中心とした全塾的サービスを開始した。以来、このシステムを基礎として様々なサービスを展開されてきたが、サービス開始から10年近くを経て、さまざまな問題が明らかとなってきていた。

• 独自の認証方式を採用していたため、標準で対応しているソフトがなく、パッケージソフトなども必ず大きな改修が必要となってしまう（改修する側も、その改修が他の案件で役に立たない）
• ネットワークの構成に制約が多かったため、クラウドをはじめとして、塾外にサーバを置くことが困難であった
• 特に、採用を検討していたクラウド上のメールシステム（G Suite（旧 Google Apps）やOffice365等）を、独自の認証方式でシングルサインオンさせることが難しい
• シングルサインオンを用いるURL間の移動に制約が多かったため、現在の標準的なシステムで可能な形のユーザ動線を実現できなかった

さらに、認証システムに対する次のような要望もあった。

• ID・パスワードのみの認証に限界が見え始めているので、何らかの多要素認証に対応したシステムとしたい
• アカウントのライフサイクルを実現するための個人データの流れが複雑化しすぎていたので、これを単純化したい
• 卒業生に対しても何らかのサービスを提供したい

認証システムの移行に関しては、次のような問題もあった。

• 既に展開されている多くのアプリケーションを、新しい認証システムに一気に対応させることは難しい

これらの問題を解決するため、keio.jpシステムの全面的改修を行った。構想は数年前から行ってきたが、実際に改修作業を行ったのは2014年6月から3月にかけてである（一般公開はその期間内の2014年11月11日）。

ShibbolethとRFC 6238 TOTPを採用した認証システムの実現

メールシステムとしてG Suite for Education（旧 Google Apps for Education）（以下GSfE）を採用することを決定した後、これらの問題点を解決するため、新しい認証システムとGSfEとの連携に関する提案を業者に募り、最終的に次のような提案が採用された。

• 認証システムとしてはShibbolethを利用する
• Shibbolethの認証バックエンドはLDAPを利用する（LDAPまでは義塾側が提供）
• G Suite（旧 Google Apps）アカウントのライフサイクルはShibboleth用LDAPのデータを元に、Google社の提供するGoogle Cloud Directory Sync（旧 Google Apps Directory Sync）で実現する
• RFC 6238に基づくTOTP（Time-based One Time Password）を、多要素認証システムとしてShibboleth用に実装する

最初に上げた多くの問題は、シングルサインオンシステムとしてShibbolethを採用することによってほぼすべてが解決された。Shibbolethは国立情報学研究所による学術認証フェデレーション（以下、学認）でも利用されている、学術分野での標準的なオープンソース・ソフトウェア（以下 OSS）の認証システムである。認証はSAML（Security Assertion Markup Language）標準を用いて行われ、シングルサインオンを提供する際に、ネットワーク構成やホスト名・ドメイン名にも制約はないため、クラウドサービスに対する親和性も高い。

ITCでは2011年ごろから、学認への参加に向けてShibboleth関連の開発・運用を行っていたこともあり、Shibbolethによる認証インフラの実現は好ましいものと言えた。また、認証バックエンドのLDAPサーバも、学認用のLDAPサーバを改修することで実現することが可能であったため、義塾側で短期間で提供することが可能であった。

さらに結果として、認証システムが利用するほとんどのソフトウェアがOSSとなった。これによって、卒業生のように非常に多数のユーザにサービス対象を拡大する時にライセンス費用を心配する必要がなくなり、多要素認証など機能拡張の開発を行うことも容易となった。

多要素認証（近日中に一般ユーザに公開予定）は、オープンな規格であるRFC 6238を採用することで、高価な専用のデバイスを必要とすることなく、スマートフォンの一般的な無料アプリ（例：Google Authenticator）等を利用して多要素認証が可能となった。

ITCにおける認証基本データ関連の開発

LDAPサーバ以下の部分はITCの内部で開発を行った。まず、学認用に開発された高速全件更新可能なLDAPサーバに対して、ITCアカウントのユーザデータを元に、ShibbolethとGADSで用いるためのデータに変換して格納するシステムの開発（実際は学認用に開発されたシステムの大規模改修）を行った。この過程で、最初に挙げた認証システムに対する要望の一つであった、個人データの流れの複雑さをかなり簡略化することが可能となった。

また、シングルサインオンを行いたくないサービスや、パブリックのネットワークにアクセスできない環境に対するサービスも存在しており、そのようなサービスに対してはShibbolethの認証は不適当である。これに対応するため、REST風の認証APIを開発し、一部のサービスに対して提供している。

サービスの認証がShibbolethに対応したとしても、Shibbolethはユーザ本人以外の属性をアプリケーションが取得することが困難であり、そのような場合は多くのアプリケーションでLDAPを属性情報の取得先として利用可能となっている。また、LDAPでのみ認証が可能でカスタマイズが困難なパッケージソフトやアプライアンスなども多数存在している。

このようなサービスのために、アプリケーションごとに異なった形で、属性やユーザ毎のデータ取得制限、属性データの自由な加工が可能なLDAPプロキシサーバを開発した。これによって、アプリケーションにおけるユーザデータの処理を大きく簡略化することが可能であり、またアプライアンスなどの認証にも（シングルサインオンは不可能であるが）新義塾認証システムを利用することが可能となっている。

今後の計画

新義塾認証システムに関しては、以下の機能拡張を計画している。

• keio.jpの生涯メール化や、より多くのWebアプリケーションの提供に対応した、対象ユーザの拡大
• 多要素認証に関するユーザビリティ改善
• さらに多くの多要素認証の提供