web.xmlファイルのセキュリティ設定
|
|
|
|
web.xmlファイルのセキュリティ設定
各アプリケーションのセキュリティはweb.xmlファイルで以下の手順に基づき設定する。
1. URLパタンをベースにしてリソースに制約を設定する
2. そのリソースにアクセスできるセキュリティ・ロール指名する
3. このウェブ・アプリケーションの全てのセキュリティ・ロールを指名する
4. そのロール内の全てのグループやユーザを指名する
以下、このステップに従って設定法を説明する。
ステップ１: URLパタンをベースにしてリソースに制約を設定する
セキュリティ制約のタグ<security-constraint>のなかの<web-resource-collection>タグ内の要素を見る。Tomcatについているテンプレートは次のようになっている。
|
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name> <!-- Define the context-relative
URL(s) to be protected -->
<url-pattern>/jsp/security/protected/*</url-pattern> <!-- If you list http methods, only
those methods are protected --> <http-method>DELETE</http-method>
<http-method>GET</http-method>
<http-method>POST</http-method> <http-method>PUT</http-method> </web-resource-collection> |
web-resource-name要素は次の要素から構成される。
|
web-resource-name |
この保護領域の名前 |
|
description |
このリソース名の記述 |
|
url-pattern |
このコンテキストに相対なこの保護領域のURLパタン。ユーザがこのURLパタンのページにアクセスしようとしたときは、エンジンはこのユーザにアクセスを許容する前に、このユーザが認証されているかの確認をする。 |
|
http-method |
適用されるHTTPメソッド。これを指定しないときは全てのHTTPメソッドに対して適用される。 |
ステップ2: このリソースにアクセスが許容されるセキュリティ・ロールを指名する
この要素に対するTomcatのテンプレートは次のようである。
|
<auth-constraint> <!-- Anyone
with one of the listed roles may access this area -->
<role-name>tomcat</role-name> <role-name>role1</role-name> </auth-constraint> |
この要素に含まれる要素は<description>と<role-name>のみである。<role-name>にはロールの名前（複数あれば、その分）を含める。
ステップ3: このウェブ・アプリケーションのセキュリティ・ロールの全てを挙げる
Tomcatのテンプレートにはこの<security-role>要素は入っていない。この要素に含まれる要素は<description>と<role-name>のみである。<role-name>にはこのwebアプリケーションに含まれるロールの名前（複数あれば、その分）を含める。
ステップ4: このロールごとにプリンシパルを設定する
WebLogicサーバなどでは、<security-role-assignment>タグによりロールごとにプリンシパル名が設定できるようになっている。Tomcatの場合はtomcat-users.xmlファイルにユーザ名毎にパスワードとロールを指定するだけである。
ステップ5: 認証のオプションを選択
Tomcatのweb.xmlテンプレート・ファイルをみるとBASICとFORMが選択できるようになっている。
|
<!-- Default login configuration uses BASIC
authentication --> <!-- <login-config>
<auth-method>BASIC</auth-method> <realm-name>Example Basic
Authentication Area</realm-name> </login-config> --> <!-- Form-based login is enabled by
default. If you wish to try Basic
authentication, comment out the <login-config> section below
and uncomment the one above. --> <login-config>
<auth-method>FORM</auth-method> <realm-name>Example
Form-Based Authentication Area</realm-name> <form-login-config>
<form-login-page>/jsp/security/login/login.jsp</form-login-page>
<form-error-page>/jsp/security/login/error.jsp</form-error-page> </form-login-config> </login-config> |
デフォルトである基本(BASIC)認証を選択したときは、これに含める要素は<realm-name>のみである。基本認証はそれだけで済むが、フォーム・ベースの認証手順を選択したときは、さらに次のステップを踏むことになる。
ステップ6: web.xmlの設定をする
ここでは前のステップで示した<login-conf>要素のコメントアウトを外し、レルム名、ログイン・ページやエラー・ページを指定する。ログインやエラーのページはjsp、サーブレット、HTMLいずれでも構わない。
ステップ7: ログイン・フォームのページを作成する
例えばlogin.htmlページは次のようなformのHTMLタグを含むことになる。
|
<form method=”POST” action=”j_security_check”>
Username: <input type=”text” name=”j_username”><br />
Password: <input type=”password” name=”j_password”><br />
<input type=”submit” value=”Login”>
<input type=”reset” value=”Reset”> </form> |
フォーム・ベースの認証では、エンジンは次のように処理する：
1. そのリソースが保護されていたら、login.jspなどのログイン用のページをクライアントに返す。
2. クライアントからのユーザ名とパスワードが帰ってきたら、これを検証し、失敗すればerror.jspなどのエラー・ページを返す。
3. 認証されたユーザが認証ロールに含まれておれば、当初要求されていたリソースをクライアントに送る。そうでなければエラー・ページを返す。
以上でセキュリティの設定は終了である。
ステップ8: サーブレットやJSPのレビュー
サーブレット・エンジンが行う認証の手順にはクッキーを使ったセッションが使われる。これは皆さんが自分のブラウザに、クッキー受付を拒否させると、ログインできなくなることで確認できる（これまでのレッスンで紹介したサーブレットは、クッキーを受け付けないブラウザでも問題が生じないようにプログラミングされていた）。従って認証が終了したHTTP要求は既にセッションが張られている。このユーザが最初に訪問したか否かの判断にHttpSession.isNew()メソッドは使えなくなる。従ってSessionの属性やデータベースを使ったきちんとしたセッション状態管理に変更しなければならない。
またセキュリティがからむアプリケーションにおいては、何時誰が何をアクセスしたかのログを（例えばTomcat_home\logsのディレクトリ内に）きちんと残すことが好ましい。このチュートリアルではプログラムを示さないが、各自試されると良い。
SimpleMessageReceptionistクラスにあるRequestDumpメソッドを使って認証されたあとのセッションやクッキーがどうなっているかを調べるのも皆さんの宿題にしよう。