Cambridge 大学の学内限定Webサイトは、IPアドレス認証ではなくて、学生IDとパスワードによるシングルサインオンになっている。仕組みが気になったので勉強した。最近流行りの、Twitter や Facebook を使ったシングルサインオンも似たような仕組みだと思う。
認証の流れ
認証を必要としている Web ページ(学生限定の講義資料とか)を単に「Webサービス」と呼ぶことにする。Web サービスは、複数ある。講義資料が載せてある学科ごとの Web サイトとか、全学共通の学籍管理システムなどがそうだ。認証を行うシステムを「認証局」と呼ぶことにする。これは大学全体で1つだけである。
このシステムにおける認証の流れは以下のとおり。
- Webサービスへ、クライアントがアクセスする。
- Webサービスのログインボタンを押す。
- Webサービスは、クライアントに対し、認証局にある認証用ページを表示するように要求する。これは Location: ヘッダと300番台のHTTPレスポンスコードを使って行われる。この時、認証用ページへのパラメータとして(GET リクエストの?以降)で、依頼主(=Webサービス)の URL と、認証結果を返すべきアドレスを含めておく。
- 認証局は ID とパスワードなどの情報を使って認証を行う。
- 認証結果を Webサービスに返す。これも Location: ヘッダによる転送で行われる。認証の成否は、URLパラメータとして返される。
- Webサービスは認証局からのパラメータを検証して、自サービスへのログインを認めるか判断する。ログイン後は、Webサービス側がセッションを維持管理する。
攻撃への対策
ステップ4は ID・パスワードのやりとりを含むので、HTTPSによる暗号化が必須だ。他のステップも暗号化することが望ましいが、必須ではない。ただしその場合は、Webサービスの Cookie が傍受され、セッションをハイジャックされるリスクがある。大学では、Web認証による、暗号化されていない無線LANアクセスポイントを提供しているので、特にリスクが高い。Webサービス側も極力 HTTPS を利用すべきである。
クライアントと認証局サーバとの HTTPS によるやりとりで Cookie を作成することで、認証局サーバへの認証状態を保持しておくことができる。これがシングル・サインオンを可能とする。つまり、2つ目以降の Webサービスから認証要求があった場合は、ステップ4でID・パスワードを再入力させることなく、認証局はただちに「認証成功」を返信できる(実際には「Webサービス2 が認証を要求している」という確認画面を表示するが)。この通信は暗号化されているので、Cookie 奪取によるセッション・ハイジャックは困難である。
ステップ5における認証局からの応答を盗聴して Webサービスに送りつける replay 攻撃に対抗するため、認証結果には ID とタイムスタンプを含めておき、同じ ID は1回だけ有効で、発行後数秒間だけ認めるようにする。ただし、これは「絶対」的な対策ではない。
認証局からの返事を別の Webサービスに転送するような攻撃を防ぐため、返事には呼び出し元 Webサービス URL も含めてある。
認証局からの応答には、所属コースや学年といった追加情報を含めることができる。学生だが他学部なので Webサービスにはログインさせないといった判断をWebサービス側で実装できる。
このように認証局からの応答には重要な情報がたくさん含まれている。応答には認証局の秘密鍵で署名がされており、Webサービス側が認証局の公開鍵を使って署名を確認する。このため、偽の「認証成功」レスポンスを Webサービスに送りつけられても検出できる。
Webサービスのセッション乗っ取りなどの攻撃が成功した場合、その Webサービスへの不正アクセスは行われるが、学生のID・パスワードは、認証局との暗号化通信でしかやりとりされないので安全である。したがって、同じ認証局を使う他の Webサービスは影響を受けない。
