第11章　セキュリティ (Security)

第11章　セキュリティ (Security)

ウェブアプリケーションは開発者(Developer)によって作られる。開発者はそれを次に与えるとか売るとか、さもなければそのアプリケーションをデプロイヤ(導入者：Deployer)に渡しランタイムの環境内にインストールされる。開発者にとって、デプロイメント（導入）されるアプリケーションに如何にセキュリティがセットアップされるべきかの属性をやりとりできると有用である。

ウェブアプリケーションのディレクトリレイアウトとデプロイメントディスクリプタにより、本章の各要素はデプロイメントのリプレゼンテーションにのみ必要であり、ランタイムのリプレゼンテーションでは必要としない。しかしながら、ランタイムのリプレゼンテーションの一部としてこれらの要素をコンテナが実装することを推奨する。

11.1　イントロダクション (Introduction)

ウェブアプリケーションは、多くのユーザからアクセスされる多くのリソースを含む。重要な情報がしばしばインターネットなどの保護されていないオープンなネットワークを通過する。そのような環境にあっては、あるレベルのセキュリティのが要求されるウェブアプリケーションが相当数存在する。ほとんどのサーブレットコンテナがこれらの要求を満たすためのそれぞれのメカニズムとインフラストラクチャを備えている。品質保証と実装の詳細はおのおの異なるが、それらのメカニズムの全てが以下の機能の幾つかを共有している：

- 認証：　通信エンティティ同士が、互いに特定のエンティティに代わって動作していることを証明するためのメカニズム。

- リソースへのアクセス制御：　取得性、保全性、または秘匿性の適用実施のために、ユーザやプログラムの集まりに対して、リソースへの関与を制限するメカニズム。

- データ保全性：　その情報が通過する間に、第3者によって変更されていないことを証明するメカニズム

- 機密性またはデータのプライバシー：　その情報がそれをアクセスする為にオーソライズされたユーザに対してのみ取得可能であり、伝送の際不信をまねくことになっていないものであることを確たるものとするメカニズム。

11.2　宣言型セキュリティ (Declarative Security)

宣言型セキュリティは、ロール、アクセス制御、認証の要求事項などを含むアプリケーションのセキュリティの構造をフォームとしてそのアプリケーションの外部に表記する手法をいう。ウェブアプリケーションにおいて、デプロイメントディスクリプタが宣言型セキュリティの主たる手段となる。

デプロイヤは、そのアプリケーションの論理的なセキュリティの要求をランタイムの環境ごとに固有のセキュリティポリシーのレプレゼンテーションにマッピングする。ランタイム時は、サーブレットコンテナはそのセキュリティポリシー、即ちデプロイメントディスクリプタから導き出され、デプロイヤによって認証を施行するように設定されたセキュリティポリシーを使用する。

11.3　プログラマティック セキュリティ (Programmatic Security)

プログラマティックセキュリティは、セキュリティが必要とされるアプリケーションで、宣言型セキュリティのみではそのアプリケーションのセキュリティモデルを十分に記述できないようなときに用いられる。プログラマティックセキュリティは、HttpServletRequestインターフェイスの以下のメソッドからなる：

- getRemoteUser

- isUserInRole

- getUserPrincipal

getRemoteUserメソッドは、クライアント認証を受けたユーザ名をかえす。isUserInRoleは、そのユーザがある与えられたセキュリティロール内にあるかどうかを、そのコンテナで使われているセキュリティのメカニズムに問い合わせる。getUserPrincipalメソッドは、java.security.Principalオブジェクトを返す。

これらのAPIにより、サーブレットはリモートのユーザの論理的なロールに基づくビジネスロジックの判断ができる。またこれらにより、サーブレットは現在のユーザのプリンシパル名を求めることができる。

getRemoteUserがnullを返すときは（即ち認証されたユーザが存在しない）、isUserInRoleメソッドは常にfalseを返し、getUserPrincipalメソッドは常にnullを返す。

11.4　ロール (Roles)

ロール（職務とか役割）というのは、アプリケーション開発者またはアセンブラが定めた抽象的なユーザの論理グルーピングのことである。そのアプリケーションがデプロイメントされたら、これらのロールはデプロイヤにより、ランタイムの環境下に、プリンシパルとかグループなどのセキュリティのエンティティにマッピングされる。

到来した要求に結び付けられたプリンシパルへの宣言型またはプログラマティックのセキュリティを、呼び出しプリンシパルのセキュリティの属性にもとづき、サーブレットは実施する。例えば、

1. デプロイヤがセキュリティのロールをその運用環境においてあるユーザグループにマッピングするとき。呼び出しプリンシパルが属しているユーザグループが、そのセキュリティの属性から検索される。そのプリンシパルのユーザグループが運用環境においてそのセキュリティロールがマッピングされているユーザグループと一致するときは、そのプリンシパルはそのセキュリティロールの中にいることになる。

2. デプロイヤがあるセキュリティロールをあるセキュリティポリシードメインのプリンシパル名にマッピングしたときは、その呼び出しプリンシパルのプリンシパル名がそのセキュリティ属性から検索される。そのセキュリティロールにマッピングされているプリンシパルと同じプリンシパルのときは、呼び出しプリンシパルはそのセキュリティロールの中にいる。

11.5　認証 (Authentication)

ウェブクライアントは、以下のメカニズムを使ったウェブサーバへのユーザ認証ができる：

- HTTP基本認証 (HTTP Basic Aythentication)

- HTTPダイジェスト認証 (HTTP Digest Authentication)

- HTTSクライアント認証 (HTTPS Client Authentication)

- フォームベース認証 (Form Based Authentication)

11.5.1　 HTTP基本認証 (HTTP Basic Aythentication)

HTTP基本認証はHTTP/1.1仕様書で規定されている認証のメカニズムである。このメカニズムはユーザ名とパスワードに基づいている。ウェブサーバはウェブクライアントにユーザ認証を要求する。要求の一部として、ウェブサーバはその中でユーザが認証されるその要求のレルム(realm)と呼ばれる文字列を渡す。基本認証メカニズムのレルムの文字列は、特定のセキュリティポリシードメインを反映（混乱を生じやすいが、これもレルムと呼ばれる）しなければならなくは無いことに注意のこと。ウェブクライアントはユーザ名とパスワードをユーザから取得し、これをサーバに送信する。ウェブサーバは次に指定レルム内でそのユーザを認証する。

基本認証は、ユーザのパスワードが単純なbase64エンコードで送信され、ターゲットのサーバは認証されないので、セキュアな認証プロトコルではない。しかしながら、セキュアなトランスポートメカニズム(HTTPS)、あるいはネットワークレベル（IPSECプロトコルやVPN戦術など）でのセキュリティなどの付加の保護により、これらの心配を緩和することができる。

11.5.2　HTTPダイジェスト認証 (HTTP Digest Authentication)

HTTP基本認証と似て、HTTPダイジェスト認証はユーザ名とパスワードに基づいて認証を行う。しかしながらこの認証では、基本認証で使われていた単純なbase64エンコーディングよりはもっと安全な暗号化によりパスワードを送信して認証を行う。この認証はHTTPSクライアント認証のようなプライベート鍵のスキームほどセキュアではない。ダイジェスト認証は、現在広く使われてはいないので、サーブレットコンテナはこれをサポートすることは要求はされていないが、推奨はされている。

11.5.3　フォーム ベース認証 (Form Based Authentication)

ブラウザの組込み認証メカニズムでは、「ログイン画面」の見た目と感じを制御することは出来ない。従ってこの仕様では開発者がログイン画面の見た目と感じを制御できるフォームベースの認証を定めている。

ウェブアプリケーションのデプロイメントデスプリプタには、このメカニズムで使われるログインフォームとエラーページのエントリを含む。ログインフォームはユーザがユーザ名とパスワードを指定するフィールドを含んでいなければならない。これらのフィールドは、各々’j_username’と’j_password’と名前が付されていなければならない。

ユーザがプロテクトされたウェブのリソースにアクセスしようとした場合は、コンテナはそのユーザが認証されているかをチェックする。認証されており、かつそのリソースへのアクセスがそのユーザに許可されていれば、要求されたリソースが起動され、返される。ユーザが認証されていなければ、以下のステップ全部が生じる：

1. そのセキュリティ制約に対応したログインフォームがクライアントに返される。認証のトリガーとなったURLパスはコンテナに蓄積される。

2. クライアントは、ユーザ名とパスワードのフィールドを含んだそのフォームを埋める。

3. そのフォームはサーバにポストで戻される。

4. コンテナはそのユーザの認証するため、このフォームを処理する。もし認証に失敗すれば、エラーページが返される。

5. 認証されたプリンシパルは、元のウェブ要求をアクセスするためにオーソライズされたロール内にあるかどうかがチェックされる。

6. クライアントは蓄積されている元のURLパスを使ってオリジナルのリソースにリダイレクトされる。

ユーザ認証が成功しなかった場合には、エラーページがクライアントに返される。ユーザが失敗したオーソライゼーションが判るような情報をそのエラーページに含めることを推奨する。

基本認証と似て、ユーザのパスワードがプレインなテキストとして送信され、またターゲットのサーバが認証されないので、これはセキュアな認証プロトコルとはいえない。しかしながら、セキュアなトランスポートメカニズム(HTTPS)を適用したり、またはネットワークレベルでのセキュリティ(IPSECまたはVPN)を使ったりして保護を追加することで、これらの懸念がある程度軽減される。

11.5.3.1　ログイン フォームに関する注 (Login Form Notes)

フォームベースのログインとURLベースのセッショントラッキングは実装に際して問題を生じやすい。フォームベースのログインは、そのセッションがcookiesかSSLセッション情報によって維持されているときにのみ使われるようにすることを強く推奨する。

認証が適正になされるよう、ログインフォームのアクションは常に”j_security_check”でなければならない。この制約は、それが要求するリソースがなんであれこのログインのフォームがいつも機能し、またサーバが下りのフォームをアクションフィールドを訂正するようサーバに要求してしまうことを防止するために設定されている。

ここに、このフォームがどのようにHTMLページにエンコーディングされるかのさんプルを示す：

</form>

11.5.4　HTTPSクライアント認証 (HTTPS Client Authentication)

HTTPS（SSL上のHTTP）を使ったエンドユーザ認証は強力な認証メカニズムである。このメカニズムではユーザは公開鍵認定(PKC: Public Key Certificate)を持つことが要求される。PKCはe-コマースのアプリケーションでは有用であり、また企業内でのブラウザの単一のサインオンとしても有用である。J2EE対応でないサーブレットコンテナでは、HTTPSプロトコルのサポートは要求されていない。

11.6　サーバによる認証情報のトラッキング (Server Tracking of Authentication Information)

ランタイム環境においてロールがマッピングされるセキュリティの識別（ユーザーズとかグループなど）は、アプリケーション依存というよりは環境依存であるので、以下のことが好ましい：

1. ログインのメカニズムやポリシーは、そのウェブアプリケーションが導入される環境のプロパティとすること。

2. 同じ認証情報が、同じコンテナに導入される全てのアプリケーションに対して、プリンシパルをリプレゼントするのに使えるようにする。

3. ユーザがセキュリティポリシードメインをまたぐときにのみ、そのユーザに最認証を要求すること。

従って、サーブレットコンテナには、ひとつのウェブアプリケーションで認証を受けたユーザが、同じセキュリティのアイデンティティで制約されたコンテナによって管理された他のどんなリソースにもアクセス出来るように、ウェブアプリケーションレベルではなくコンテナレベルでの認証情報のトラッキングすることが要求される。

11.7　セキュリティ制約の指定 (Specifying Security Constrains)

セキュリティ制約は、ウェブコンテンツに意図するプロテクションを注釈する宣言型の手法である。制約には以下の要素が含まれる：

- ウェブリソースのコレクション

- オーソライズの制約

- ユーザデータの制約

ウェブリソースのコレクションとはプロテクトされるべきリソースのセットを記述するための、URLパタンとHTTPメソッドのセットである。ウェブリソースのコレクションに記述されたURLパタンに一致する要求が含まれる全ての要求がこの制約の対象となる。

オーソライズの制約とは、そのウェブリソースのコレクションで記述されたリソースにアクセスするためには、その一部でなければならないユーザのロールのセットを言う。もしそのユーザが許可されたロールの一部でない場合は、そのユーザはそのリソースへのアクセスが拒否される。

ユーザデータの制約とはクライアントとサーバの通信プロセスのトランスポート層が、コンテンツの完全性（送信中の改変の防止）を保証しているか、または信頼性（送信中の盗聴の防止）を保証しているかのいずれかが満足しているとかをいう。

11.7.1　デフォルトのポリシー (Default Policies)

デフォルトでは、リソースのアクセスには認証は必要とされない。認証は、ディプロイメントデスクリプタで指定されている場合にのみ、その特定のリソースのコレクションの要求にのみ必要とされる。