Web アプリケーション認証の使用

認証では、アプリケーション開発者が Web アプリケーションに対して定義したロールを、アプリケーションを実行するサーバに適用する必要があります。このセクションでは、アプリケーションの開発時に、ロールとその他の認証情報をアプリケーションに設定する方法を説明します。

アプリケーションの開発とデプロイの一部として、次のアプリケーション認証を設定する必要があります。

  1. アプリケーションへのアクセスロール
  2. リソースの保護
  3. アプリケーションサーバ検証メソッド

Web アプリケーションのデプロイメントディスクリプタである web.xml には、アプリケーション認証を管理する設定が含まれています。このファイルは、/<JRun のルートディレクトリ>/servers/<サーバ名>/<アプリケーション名>/WEB-INF ディレクトリ内にあります。

アクセスロールとリソースの設定

Web アプリケーションへのアクセスは、ユーザーがアプリケーションやアプリケーションリソースにアクセスするときに必要なロールを設定することで制御します。リソースにアクセスするには、ユーザーはそのリソースへのアクセス権を持つロールに割り当てられている必要があります。

web.xml ファイル内の security-constraint 要素や web-resource-collection
要素を使用して、アプリケーション全体や、その中のリソースにアクセス制限を割り当てることができます。

次の表で、これらの要素のシンタックスを説明します。
要素
シンタックス
security-constraint
<security-constraint> 
  <(web-resource-collection*, auth-constraint†,
  user-data-constraint†)>
</security-constraint>
web-resource-collecti
on
<web-resource-collection>
  (web-resource-name, description, 
url-pattern‡, http-method‡)</web-resource-collection>

* サブ要素を 1 つ以上定義できます。
サブ要素をオプションで指定できます。
‡ サブ要素は指定しないことも、1 つ以上指定することもできます。

web-resource-name 要素は指定する必要があります。

認証ロールの例

次のアプリケーションの web.xml ファイルの抜粋では、Store アプリケーションにアクセスできるロールが定義されています。

<web-app>
  ...
  <security-constraint> 
    <web-resource-collection> 
      <web-resource-name>Store Application</web-resource-name> 
      <url-pattern>/store/*</url-pattern> 
      <http-method>GET</http-method> 
      <http-method>POST</http-method> 
      <description>販売情報リソース</description> 
    </web-resource-collection> 
    <auth-constraint> 
      <role-name>manager</role-name> 
      <description>管理者専用</description> 
    </auth-constraint> 
  </security-constraint> 
  ...
</web-app>

この例では、security-constraint 要素を使用して次の情報を定義しています。

アプリケーションにアクセスできるロールのリストを拡張できます。次の例では、アプリケーションにアクセスできるロールに developer のロールを追加します。

...
<auth-constraint>
  <role-name>manager</role-name> 
  <role-name>developer</role-name> 
  <description>管理者と開発者</description> 
</auth-constraint>
...

認証ロールの選択的な割り当て

アプリケーション内のすべてのリソースに認証を適用する代わりに、一部のアプリケーションリソースを選択して、認証ロールを割り当てることができます。次の例では、アプリケーションの inventory ディレクトリにあるサーブレットと、アプリケーションの pricing ディレクトリにあるリソースにのみ認証を割り当てます。

<web-app>
  ...
  <security-constraint> 
    <web-resource-collection> 
      <web-resource-name>Store Application</web-resource-name> 
      <url-pattern>/store/inventory/*</url-pattern> 
      <url-pattern>/store/pricing/*</url-pattern> 
      <http-method>GET</http-method> 
      <http-method>POST</http-method> 
      <description>販売情報リソース</description> 
    </web-resource-collection> 
    <auth-constraint> 
      <role-name>manager</role-name> 
      <description>管理者専用</description> 
    </auth-constraint> 
  </security-constraint>
  ...
</web-app>

検証メソッドの設定

アプリケーションサーバでアプリケーションへのユーザーのアクセス権を認証するには、このサーバでユーザーを識別できなければなりません。ユーザーを識別すると、サーバは、ユーザーに割り当てられているロールやユーザーのアクセス権を識別できます。

保護された Web アプリケーションリソースにユーザーが最初にアクセスしようとすると、アプリケーションサーバは、ユーザー名とパスワードを使用してログインするようにユーザーに要求します。このログイン情報から、サーバはユーザーのロールを判別できます。

アプリケーションの web.xml ファイルには、次の 2 通りの検証メソッドを設定できます。これらのメソッドによって、アプリケーションサーバからユーザーにログイン情報がリクエストされる方法が決まります。メソッドは次のとおりです。

メモ:  Java サーブレット API は、ユーザー検証を行う 4 つのメソッドを定義しています。今回の JRun リリースでは、BASICFORM の 2 つだけがサポートされます。

BASIC 検証の使用

BASIC 検証は、HTTP リクエスト/レスポンスのメカニズムを使用して現在のユーザーを認証します。このタイプの検証は、次の一連のイベントによって行われます。

  1. ログインしていないユーザーが Web アプリケーションへのアクセスを試みます。
  2. JRun がユーザーのブラウザに HTTP 401 (未認可アクセス) ステータスコードを返します。
  3. ブラウザに、ユーザー名とパスワードの入力を要求するプロンプトが表示されます。
    ブラウザには、次のようなログインプロンプトが表示されます。

    ユーザー名とパスワードの入力を要求する簡単なグラフィカルログインボックス。

  4. ユーザーはユーザー名とパスワードを入力します。
  5. ブラウザから JRun サーバにログイン情報が返され、認証が行われます。

    ユーザー名とパスワードが有効な場合、JRun サーバは、ユーザーがそのアプリケーションへのアクセス権を持っていることを認証し、リクエストされたページを返します。無効な場合、JRun は HTTP 403 (禁止) ステータスコードをユーザーに返します。

    ユーザーが認証処理をキャンセルすると、サーバから HTTP 401 (未認可) ステータスコードが返されます。

「認証の例」 の図でもこの手順を示しています。

アプリケーションが BASIC 認証を使用することを指定するには、Web アプリケーションの web.xml ファイル内の login-config 要素と auth-method サブ要素を使用します。次の例では、Sales 領域内の認証メソッドを BASICに設定します。

<web-app>
  ...
  <login-config> 
    <auth-method>BASIC</auth-method> 
    <realm-name>Sales</realm-name> 
  </login-config> 
  ...
  <security-constraint> 
  ... //security contstraints
  </security-constraint> 
  ...
</web-app>

各 Web アプリケーションに設定できる認証メソッドは 1 つだけです。

realm-name プロパティを省略すると、アプリケーションのホストであるサーバ名が領域名として使用されます。

ステータスコードの処理

Web サーバからクライアントに HTTP 401 (未認可) や 403 (禁止) のステータスコードが返されると、一部の Web サーバはデフォルトでエラーページを送信します。Web サーバによるステータスコードの処理方法は、Web アプリケーションの web.xml ファイルで無効にすることができます。これよって、ログインを処理するページをカスタマイズすることができます。

次の例は、無効にされたエラーコードと、ログインに失敗したユーザーに転送されるカスタムのエラーページを示しています。

<web-app>
...
<error-page>
  <error-code>401</error-code>
  <location>/errorPages/unauthorized.jsp</location>
</error-page>
<error-page>
  <error-code>403</error-code>
  <location>/errorPages/forbidden.jsp</location>
</error-page>
...
</web-app>

FORM 検証の使用

FORM 検証では、HTML フォームを使用してユーザー名とパスワードを取得できます。
次の図に、FORM 検証の手順を示します。

ユーザーがログインしようとします。JRun は 401 エラーを返します。ユーザーは再びログインし、今回は成功します。JRun はページを返します。

次の例に示すように、web.xml ファイルには、ログインフォームとエラーフォームの両方を指定できます。

<web-app>
  ...
  <login-config> 
    <auth-method>FORM</auth-method> 
    <form-login-config> 
      <form-login-page>/login.htm</form-login-page> 
      <form-error-page>/loginerror.htm</form-error-page> 
    </form-login-config>
  </login-config> 
  ...
</web-app>

ユーザーが Web アプリケーションをリクエストすると、JRun サーバは
form-login-page 要素で指定されているページにユーザーを転送します。次の HTML ページ login.htm は、ログインページの例です。

<html><head><title>ログインページ</title></head>
<body>
<center><h2>保護されているページがリクエストされました。ログインしてください。</h2>
<form method="POST" action="j_security_check"> 
<table> 
<tr><td>ユーザー名</td><td><input type=text name="j_username"></tr> 
<tr><td>パスワード</td><td><input type=password name="j_password"></tr> 
</table> 
<br><br> 
<input type=submit> 
</form> 
</center></body></html> 

フォームには次の設定が含まれている必要があります。

ユーザー名とパスワードが有効な場合、JRun サーバは、ユーザーがそのアプリケーションへのアクセス権を持っていることを認証し、リクエストされたページを返します。無効な場合、JRun は 403 (禁止) ステータスコードをユーザーに返します。ユーザー名やパスワードが無効な場合は、ユーザーは form-error-page 要素で指定されているページに転送されます。