旧keio.jpの抱えていた問題と改善要望2005年に、慶應義塾はkeio.jpと呼ばれる認証システムを中心とした全塾的サービスを開始した。以来、このシステムを基礎として様々なサービスを展開されてきたが、サービス開始から10年近くを経て、さまざまな問題が明らかとなってきていた。Apps)やOffice365等)を、独自の認証方式でシングルサインオンさせることが難しいシングルサインオンを用いるURL間の移動に制約が多かったため、現在の標準的なシステムで可能な形のユーザ動線を実現できなかったさらに、認証システムに対する次のような要望もあった。ID・パスワードのみの認証に限界が見え始めているので、何らかの多要素認証に対応したシステムとしたいアカウントのライフサイクルを実現するための個人データの流れが複雑化しすぎていたので、これを単純化したい卒業生に対しても何らかのサービスを提供したい認証システムの移行に関しては、次のような問題もあった。展開されている多くのアプリケーションを、新しい認証システムに一気に対応させることは難しいこれらの問題を解決するため、keio.jpシステムの全面的改修を行った。構想は数年前から行ってきたが、実際に改修作業を行ったのは2014年6月から3月にかけてである(一般公開はその期間内の2014年11月11日)。Education)(以下GSfE)を採用することを決定した後、これらの問題点を解決するため、新しい認証システムとGSfEとの連携に関する提案を業者に募り、最終的に次のような提案が採用された。Password)を、多要素認証システムとしてShibboleth用に実装する最初に上げた多くの問題は、シングルサインオンシステムとしてShibbolethを採用することによってほぼすべてが解決された。OSS)の認証システムである。Language)標準を用いて行われ、シングルサインオンを提供する際に、ネットワーク構成やホスト名・ドメイン名にも制約はないため、クラウドサービスに対する親和性も高い。ITCでは2011年ごろから、学認への参加に向けてShibboleth関連の開発・運用を行っていたこともあり、Shibbolethによる認証インフラの実現は好ましいものと言えた。認証バックエンドのLDAPサーバも、学認用のLDAPサーバを改修することで実現することが可能であったため、義塾側で短期間で提供することが可能であった。結果として、認証システムが利用するほとんどのソフトウェアがOSSとなった。これによって、卒業生のように非常に多数のユーザにサービス対象を拡大する時にライセンス費用を心配する必要がなくなり、多要素認証など機能拡張の開発を行うことも容易となった。Authenticator)等を利用して多要素認証が可能となった。ITCにおける認証基本データ関連の開発LDAPサーバ以下の部分はITCの内部で開発を行った。学認用に開発された高速全件更新可能なLDAPサーバに対して、ITCアカウントのユーザデータを元に、ShibbolethとGADSで用いるためのデータに変換して格納するシステムの開発(実際は学認用に開発されたシステムの大規模改修)を行った。この過程で、最初に挙げた認証システムに対する要望の一つであった、個人データの流れの複雑さをかなり簡略化することが可能となった。シングルサインオンを行いたくないサービスや、パブリックのネットワークにアクセスできない環境に対するサービスも存在しており、そのようなサービスに対してはShibbolethの認証は不適当である。これに対応するため、REST風の認証APIを開発し、一部のサービスに対して提供している。サービスの認証がShibbolethに対応したとしても、Shibbolethはユーザ本人以外の属性をアプリケーションが取得することが困難であり、そのような場合は多くのアプリケーションでLDAPを属性情報の取得先として利用可能となっている。LDAPでのみ認証が可能でカスタマイズが困難なパッケージソフトやアプライアンスなども多数存在している。このようなサービスのために、アプリケーションごとに異なった形で、属性やユーザ毎のデータ取得制限、属性データの自由な加工が可能なLDAPプロキシサーバを開発した。これによって、アプリケーションにおけるユーザデータの処理を大きく簡略化することが可能であり、またアプライアンスなどの認証にも(シングルサインオンは不可能であるが)新義塾認証システムを利用することが可能となっている。新義塾認証システムに関しては、以下の機能拡張を計画している。