コンテキスト定義での認証の設定例

5.9.2 コンテキストで認証を必要にする

Webアプリケーションで認証を行い認可を適用させるには，定義ファイルに設定を記述する．コンテキスト に記述することでコンテキストごとに異なる設定が可能だが，定義ファイル内のすべてのコンテキストに共 通の設定を適用することもできる．コンテキストごとの設定例をリスト5.3に示した．設定はauthentication キーに記述する．定義ファイル全体に適用させる場合には，同様にauthenticationキーの記述を，定義ファ イルに記述するIM_Entry関数の2つ目の引数の要素に記述する．

5.9. 認証と認可の実装 65 nameキーの値がmessage4のものは，クエリーの対象はviewキーで指定された「message」テーブルであ り，更新，新規レコードおよびレコード削除を行うのがtableキーの「non-exist-table」テーブルのように，

読み出しと書き込みのエンティティを別々に指定している．「non-exist-table」テーブルは，その名前のテー ブルがあるということではなく，現実には存在しないテーブル名を記述する．こうすれば，更新，新規レ コードおよびレコード削除はすべて存在しないテーブルに対して行うためエラーになる．したがって，最小 限の設定として，loadキーつまりクエリー時の認証だけを設定することで，意図しないデータベース処理 を防ぐことができる．

認証が必要になると，図5.7のような認証パネルが表示される．これは別のページにリダイレクトしてい るのではなく，現在のページのウインドウ上に，オーバーラップしてパネルを表示させている．読み込み時 に認証が必要な場合には，ページを開いた直後に表示される．読み込みは認証が必要なものの修正時に認 証が必要になると，修正直後にこのログインパネルが表示される．ログイン状態は時間を決めて保持した り，あるいは保持できないようにも可能である．

図5.7:コンテンツサイトの認証画面

以上のような仕組みの認証に構造的な欠陥がないかどうかは重要な点である．JavaScriptの場合，クライ アントサイドのグローバル変数は，ブラウザのアドレスバーから変更できてしまうため，クライアント側 で保持したデータは改変される可能性がある．もちろん，改変の度合いによっては動作不良になる可能性も あるが，それはすべてのJavaScriptプログラムが持つ問題点でもある．

そうした改変がなされたとしても，認証や認可の限定範囲を変えられないことが必要である．そのことを 担保する手法として，すべての設定と処理をサーバー側で完結させるようにし，クライアントサイドは結 果を得てユーザーインタフェースを提供するだけに留めた．定義ファイルはサーバーにあり，認証の設定や 検索条件式の適用はサーバーサイドで行う．クライアントサイドでのグローバル変数の値を変えるようなこ とが仮にあったとしても，認証の動作自体は変更できないため，意図しない認証認可の設定が与えられるこ とはない．潜在的なバグがあればそこはセキュリティホールになる可能性があるが，バグがないとすれば記 述通りに動作する．

クエリーを行う時のプロトコルを，図5.8にシーケンス図で示した．その他のデータベース操作も，同様 な手順になる（以下の丸数字はメッセージの番号）．

!ページの合成を開始し，1 !内容に応じてデータベースのデータを要求する．最初は認証がないものと仮2

定してアクセスをする．!クライアントがサーバーに通信を行い，3 !サーバー側ではデータベース処理を行4

う前に認証や認可の適用があるかどうかを調べる．ここでは認証が必要だが，ログイン処理を一切行って いないので，エラーを返す．!通信モジュールは認証が必要であることを示すエラーを受けて，6 !フレーム6

ワークにログインパネルの表示を促し，!ログインパネルが表示され，7 !ユーザーはログインパネルを見る．8

!ユーザーがログインパネルで正しいユーザー名とパスワードを入力し，9 !「ログイン」ボタンをクリッ10

クしたとする．11!フレームワークはログインパネルを消去し，12!から!までの一連の流れで，サーバーから14

チャレンジとクライアントID，そしてログインしようとしているユーザーのソルトを取得する．それをも

5.9. 認証と認可の実装 67

図5.8:認証や認可を伴うデータベースアクセス

とにして，!より実際のデータベースアクセス処理を行う．サーバーサイドで15 17!認証が成功し，!認可によ18

り許可された状態なら，19!データベース処理を行うという流れになる．データベース処理を行った結果に は，新たなチャレンジが得ており，次回のデータベースアクセスはそのチャレンジを利用するので，12!から

14!のチャレンジの取得のみのアクセスは，認証直後の1回だけになる．

認証に絡んだデータの以下に説明する．まず，各データを以下の変数名で記述することにする．

user = ユーザー名 (5.1)

pw = 本来のパスワード (5.2)

salt = ユーザーごとに異なるソルト（4バイトのAS CII文字） (5.3) hpw = データベースに保存されているパスワードのハッシュ値 (5.4)

pw^′ = 入力したパスワード (5.5)

cid = クライアントid (5.6)

ch = サーバーから送られるチャレンジ (5.7) res = クライアントから送られるレスポンス (5.8) res^′ = サーバー側の情報から得られるレスポンスの期待値 (5.9)

S HA1(m) = S HA−1[72]によるmのハッシュ値を求める関数 (5.10)

HMAC(k,m) = HMAC−S HA256[6][73]で求められるMAC値を求める関数 (5.11) ハッシュ関数はS HA−256，鍵がk，メッセージがm (5.12)

+演算子 = 文字列の結合 (5.13)

データベースに保存されるハッシュ値hpwは，本来のパスワードpw，ソルト値saltより以下の式で求め たものを利用している．ソルトがASCII文字であるのはJavaScript側での計算が必要になる場合があり，文 字列処理の関係上ASCII文字のみとした．

hpw=S HA1(pw+salt)+salt (5.14)

表5.4には，認証に関わるチャレンジとレスポンスの手順を示した．チャレンジ要求があると，そのユー ザーのhpwの最後の4バイトよりsaltが求められる．最初のチャレンジ取得ではクライアントidとチャレン ジ値は両方とも乱数で求められる．クライアントidはその後のやりとりでは同一のものを利用する．user，

cid，ch，現在の日付時刻を表5.3に示した「チャレンジ記録」のテーブルに新たなレコードを生成して残

しておく．salt，cid，chをクライアントに返す．

クライアント側では次の式でレスポンスを求める．サーバーから返された値以外は，ユーザーが入力した パスワードを使用している．

res=HMAC(S HA1(pw^′+salt)+salt+cid,ch) (5.15)

5.9. 認証と認可の実装 69

表5.4:認証のために転送されるデータと動作 クライアント側での処理 転送される認証情報 サーバー側での処理

チャレンジ要求 →user→ データベースよりhpwを取得しsaltを求める chを乱数より生成，cidが未発行なら乱数で生成 user, cid, ch,日付時刻をデータベースに記録 resを求める ←salt, cid, ch←

データベース要求 →cid, user, res→ データベースより，cidからチャレンジを取得

データベース要求に，resおよびcid，userを含めてサーバーに送信する．受け取ったサーバー側は，user とcidの値を元に，「チャレンジ記録」テーブルより検索し，レコードが存在し，指定された時間内での応答 であるかどうかを確認する．条件に合えば，チャレンジ記録にある該当するレコードは削除される．そし て，以下の式で求めたレスポンスの期待値res’とクライアントが返したresが一致していれば認証したとみ なす．

res^′ = HMAC(hpw+cid,ch) (5.16)

= HMAC(S HA1(pw+salt)+salt+cid,ch) (5.17) データベース処理した結果を返すときには，チャレンジ要求で行ったことと同一の処理を行う．ただし，

cidは要求に含まれたものをそのまま利用する．こうして，次回のデータベース要求のためのチャレンジを 応答の段階でクライアントに送り届ける．

ネットワーク上を飛び交うデータは，user，salt，cid，ch，resであり，パスワードから求められるものは resのみである．しかしながら，ハッシュ値なので，resからはパスワードは合理的な時間内での解析はでき ない．MAC値を求める鍵は，パスワードをもとに求められるものなので，交換済みの秘密鍵としての機能 がある．一度レスポンスを返したチャレンジは2度と使われない．チャレンジの値が毎回違うので，レス ポンスの値も毎回異なり，これらの値をネットワーク経路上などで横取りをして同じリクエストを送ったと しても，そのときはチャレンジは無効になっている．従って，パスワードを得ない限りは認証処理を通すこ とはできない．

この節では，アプリケーションでよく利用されるような一覧と詳細を行き来するようなユーザーインタ フェースを作成する機能や，検索機能を宣言的な記述のみで実現する機能，メール送信の機能をどのように 実装しているのかについて解説をする．