古い認証システムの捨て方
細川達己 金子康樹
慶應義塾インフォメーションテクノロジーセンター本部{hosokawa,yasuki.kaneko}@keio.jp

How to Throw Away a Legacy Authentication System
Tatsumi Hosokawa, Yasuki Kaneko
Information Technology Center, Keio University
概要
慶應義塾においては、約 10 年前に構築した keio.jp という独自実装の全学基盤認証システムが存在し、その上で 50 以上のアプリケーションが動作していたが、クラウドメールの利用のため、この認証システムを Shibboleth ベースのものに置き換えることを決定した。
その後、認証システム自体の切替えから約 2 年半をかけて、ユーザにあまりシステムの変更を意識させることなく移行作業を続けており、現在はその最終段階にある。
本稿では、独自実装から Shibboleth を用いた認証方式への移行をする際の留意点や課題について、実例を挙げながら考察する。

1

1.

はじめにユーザを ID とパスワードで認証するとメニュー画面（ポータル）が表示される。

2.

慶應義塾では、2002 年に開発を開始し、2005

その画面からアプリケーションに遷移す

年に本格運用が始まった、keio.jp と呼ばれる独自るときに一時的なランダム文字列がアプ仕様の全学基盤認証システム（以下、旧 keio.jp）リケーションに渡される。
3.

が存在しており、これで認証を行う 50 を越えるア

アプリケーションは、渡されたランダム文字列を認証システムに対して照会し、ユープリケーションが存在していた。

ザの属性などを得る。

しかし、運用開始から 10 年近くを経て、特に独自仕様である点が既存のパッケージや SaaS のユーザ ID のフォーマットは、「ユーザが好きにクラウドサービスを導入する際などに大きな弊害付けられる文字列@サブドメイン.keio.jp」というとなっていた。

形式であり、サブドメインはシステム側でランダ

そこで 2014 年、全学メールシステムを、本学ムに割り振られるようになっていた。たとえば向けにカスタマイズされた DEEPMail ベースのシ「keio-taro@a2.keio.jp」のような形式である。これステムから、Google Apps for Education（現在 G Suiteが同時に導入された全学メールのメールアドレスfor Education）に移行するにあたり、認証システムとなっていた。

を、学術機関の認証システムとして広く利用されユーザの認証情報や属性は SQL のデータベーている Shibboleth による、SAML2 ベースの認証シスに保存され、認証や属性の取得、アカウント初ステム（以下、新 keio.jp）に移行することとした。

期化などの API は、データベースのストアドプロそして本年度末である 2017 年 3 月までを移行シージャとして実装されていた。アプリケーショ期間と定めて、既存のアプリケーションの全面移ンはこれらの API を Web サービス経由でアクセス行を行うこととした。

するように定められていた。
このような仕組みで認証を行うため、ポータル

本稿では、移行時に特に問題になった点とその解決策について、具体的に紹介していく。

を経由しないページ遷移では、シングルサインオンができない、などといった問題も存在していた。

2

旧 keio.jp のシステム
旧 keio.jp は、独自の実装がされたもので、次のような仕組みで認証が行われるものであった。

3

アプリケーションの移行
先述の通り、認証システムの移行を検討している時点で、様々な部門が開発したものを含む 50 をが自然であり、ランダムに割り振られるサブドメ越えるアプリケーションが旧 keio.jp 上で動作してインは、今後未知の弊害を起こす可能性も考えらいた。これら全てを、タイミングを合わせて一気れた。に新システムに移行することは技術的に困難であり、また大きなリスクでもある。

また以前から、このランダムに割り振られたサブドメインはユーザから不評であり、このサブドそこで、移行に関しては次の方針を立てた。

メイン部分を忘れたので教えてほしいという問い

l合わせがヘルプデスクに頻繁に寄せられていた。

旧 keio.jp のコアのデータベースと各種API は当面の間機能を維持する。

ll

以上のような理由から、新 keio.jp においては、

旧 keio.jp のログイン用 API と、旧アプリプライマリなユーザ名体系を「ユーザが好きに付ケーションに画面遷移するポータル機能けられる文字列@keio.jp」という、サブドメインをの一部を切り出して、Shibboleth SP として省く形に設定することとなった。

再実装する。このシステムによって、旧ア

ただし、先述の通り、旧 keio.jp を前提としたアプリケーションはあたかも新 keio.jp で認プリケーションは残り続けるため、旧形式のユー証しているかのように動作する。

ザ名もシステム内部に持ち続けることとした。まある程度（2017 年 3 月まで）の移行期間

た、システムの移行後にアカウントを取得したユを持たせて、その間に原則全アプリケーシーザは、新システムに対応したユーザ名しか認識ョンをネイティブな Shibboleth SP に移行していないが、システムの内部には旧形式のユーしてもらう。

ザ名を持ち続けることになっている。

この移行のための互換レイヤは、旧 keio.jp のロ

逆に、既存ユーザ名に関しても新形式のユーザグイン用 API のストアドプロシージャのソースを名を割り当てることが必要であったため、次の方読み、それを Shibboleth SP 上のスクリプトとして針で割り当てを行った。

再実装することで実現した。スクリプトは

lShibboleth SP による認証を信頼し、旧 keio.jp 本来重複していない場合は、そのままサブドメの認証プロセスをスキップして、偽の認証済みラインを外した文字列を新形式とする（旧形

ンダム文字列を旧 keio.jp のデータベースに書き込

式が「keio-taro@a2.keio.jp」であれば、新む。この処理が正常に終了した後、生成されたラ形式は「keio-taro@keio.jp」となる）。

ンダム文字列を自動的に POST しながら、ブラウザを旧アプリケーションに遷移させる。

@の左側の文字列が、全サブドメイン間でlサブドメイン間での重複がある場合は、全ての旧アプリケーションは、この偽データに「ユーザの割り当てた文字列.サブドメイよって問題なく動作することが検証できたため、ン名@keio.jp」を新形式とする（旧形式が旧アプリを十分な期間を設けて移行作業を行うこ「keio-taro@a2.keio.jp」であれば、新形式とが可能となった。

は「keio-taro.a2@keio.jp」となる）。

さらに、ポータルを経由しないページ遷移ではシングルサインオンが出来ないという問題点も、この機構によって解決することができた。

4

ユーザ名体系の移行l

割り当てられた新形式ユーザ名を、一度だけ好きな文字列に変更することができるシステムを一定期間提供する。
ログイン ID としては新形式・旧形式のどちらメールシステムを Google Apps for Education（現でも利用できるようにした。これは Shibboleth IdP

在 G Suite for Education）に移行するにあたって、のバックエンド LDAP 内に、新旧両形式を uid と旧 keio.jp のユーザ名体系が、データの共有などにして持つ 2 つのエントリを用意することで実現しおいて弊害となる可能性が、この移行作業を行った。新旧両形式のユーザ名は、uid とは別のユーザていたサイオステクノロジー社[1]から示された。

属性として、ログインに利用した uid の形式にか

具体的には、「ユーザが好きに付けられる名前かわらず、Shibboleth SP 経由で同一の値を取得す@サブドメイン.keio.jp」の「サブドメイン」の部ることが可能であり、アプリケーションは uid で分である。Google Apps の設計上、1 つのテナントはなくこれらの属性値をユーザ名として利用する。

は 1 つのドメイン内に収まるように設計すること

この仕組みによって、どちらの形式でログインしても同一ユーザとしてアプリケーションからは扱とで、その間に一度でも旧 keio.jp にログインしたわれることになる[2]。

ユーザに関しては、OpenLDAP で BIND 可能なハ

メールシステムに関しても、旧形式のメールアッシュが取得されていた。

ドレスをそのまま、受信先アドレスとしてだけでそのため、ほとんどのユーザに関しては、自動はなく、Web メールの送信元アドレスとしても使的に新 keio.jp にパスワードを引き継ぐ事が可能とい続けることができるようにシステムを構築した。

なった。それ以外のユーザに関しては、窓口で通5

パスワードハッシュの移行
旧システムは独自実装であったため、パスワードハッシュも独自形式のものであった。しかし、Shibboleth IdP で認証させるには、バックエンドの常のパスワード再発行の手続きを行うこととしたが、対象が少なかったこともあり、大きな混乱は生じなかった6

プロビジョニングシステムの移行

OpenLDAP が BIND（認証）可能なパスワードハ

旧 keio.jp は、構築時にあまりユーザプロビジョッシュ形式である必要があるため、平文パスワー

ニングについて深く考えられていなかったため、ドを保存していない状態では簡単には移行するこ

学事や人事のデータベースから提供されたデータとはできない。

を元に、非常に複雑な手順で反映される、独自の幸運なことに、学術認証フェデレーション（以システムで運用されていた。

下、学認）に正式加入することにした 2013 年に、この反省から、2011 年に導入された「ITC シス

将来的な Shibboleth での認証に備えて、旧 keio.jp

テム」という、学内設置 PC を利用する際に必要のログイン API に関するストアドプロシージャをとなるアカウント等のサービスを提供しているシ

改修し、正常にログインがなされた場合には、パステムでは、よりシステム化されたユーザのプロスワードとして入力された文字列を OpenLDAP でビジョニングが実現され、属性データもより実用BIND 可能な形式に再ハッシュ化し、データベー的な形式で格納されるようになっていた。

スに格納するようになっていた。
この形式で 1 年以上システムを運用し続けたこ

そこで新 keio.jp においては、この「ITC システム」のデータを元に、ユーザや各種属性のプロビ

図 1. keio.jp 用プロビジョニングシステムの移行（手順 2.〜3.の段階）

ジョニングを行う事を決定した。

通常はブックマークしてもうまくその後のログイ

一方で、keio.jp のユーザ名やパスワードの情報ンができない Shibboleth IdP のログイン画面をブは、旧 keio.jp システムにしか存在しなかったため、ックマーク可能にするハック[4]を加えることで、次のような手順でプロビジョニングシステムを移ユーザが旧 keio.jp の時と同様に、自然な手順でロ行することとした。

グイン画面をブックマークできるようにした。

1.

慶應義塾大学の学認 IdP 用のプロビジョ
ニングシステムは、旧 keio.jp と ITC シス

今後の課題

テムの双方からデータを得て、Shibbolethその他にも多くの課題・問題があったが、無事IdP のバックエンドの OpenLDAP にユーに本学全学基盤認証システムを。独自システムかザプロビジョニングを行っていた[3]。新ら Shibboleth ベースのシステムに、比較的スムー

keio.jp は Shibbolethズに移行することができており、周辺アプリケーIdP を利用することとなったので、まずはこの学認のプロビジョニングシステムをベースに新 keio.jp の2.

8ションの移行も順調に進んでいる。
現在直近の課題としては、作業のベースとなっための改修を加えることとした。

た学認の IdP を廃止し、新 keio.jp の中に学認 IdP

この新 keio.jp 用プロビジョニングサーバを取り込むことであるが、これは次のような要因に対して、学認には不要ではあるが新で細心の作業が必要であると考えている。

keio.jp に必要な属性や、様々な関連データ1.

を扱えるように改修を行い、その結果を新
keio.jp 用 LDAP にプロビジョニングするようにした、この LDAP をベースとする
Shibboleth IdP を、新 keio.jp として 2014年 11 月に公開した（図 1 左）。
3.

学認 IdP の entityID の変更を含む作業となる（ePPN 等の属性値は変化させない）。

2.

学認のポリシーに合わないユーザの属性を学認 SP に送信しないように設定することが必要である。

また、多くのユーザやアプリケーションに利用さらに改修を行い、旧 keio.jp の DB も新されている基盤システムであっても、スムーズにkeio.jp 用プロビジョニングシステムがプ更改することが可能であったというこの事例を、ロビジョニングを行うようになり、データ学内に多く残る他のレガシーな基盤システムの更の流れが単純化された。この変更は 2015改に向けて役立てていけたらと考えている。

年 3 月に行った（図 1 右）。
4.

2017 年 3 月に、全ての旧アプリケーショ
ンの Shibboleth SP 化が完了した時点で、不要となる旧 keio.jp のデータベースを廃止する予定となっている。

このようにして、学認用のプロビジョニングシステムをベースに、スムーズに新 keio.jp のプロビジョニングシステムを構築することができた。
現在は、最終段階の手順 4.の準備中である。

7

ログイン・ポータル画面の移行
旧 keio.jp においては、ログイン画面とポータル画面は同一の Web アプリケーションとして実装されていたが、これをほとんど変わらないデザインで、ログイン画面は Shibboleth IdP に、ポータル画面は新しいポータルアプリケーション（ShibbolethSP）に分離した。
旧 keio.jp のログイン画面をブックマークしていたユーザのために、旧 URL は新ポータルアプリ
ケーションへのリダイレクトを設定した。さらに、

参考文献[1] サイオステクノロジー株式会社「サイオスが開発したワンタイムパスワード認証システム、慶應義塾の認証基盤に採用 ～ Shibboleth（シボレス）認証用ワンタイムパスワードモジュ
ールとワンタイムパスワード用秘密鍵発行システムを提供～」, http://i.sios.com/news/press/20141022-otp.html, 2014[2] 慶應義塾 ITC 本部技術メモ「Shibboleth で複数の ID を同一人物としてログインさせる」,
http://memo.itc.keio.ac.jp/blog/?p=101, 2014[3] 慶應義塾 ITC 本部技術メモ「プロビジョニン
グの道具としての OpenLDAP back-sql」, htt
p://memo.itc.keio.ac.jp/blog/?p=88, 2014[4] 慶應義塾 ITC 本部技術メモ「Shibboleth のロ
グインページをブックマーク可能にする」, http://memo.itc.keio.ac.jp/blog/?p=416, 2014