BEA ホーム | 製品 | dev2dev | support | askBEA
 ドキュメントのダウンロード   サイト マップ   Glossary 
検索

Web アプリケーションのアセンブルとコンフィグレーション

 Previous Next Contents Index PDF で侮ヲ  

Web アプリケーションでのセキュリティのコンフィグレーション

この章では、Web アプリケーションでセキュリティをコンフィグレーションする方法について説明します。

WebLogic Server セキュリティの概要、アップグレード、および新情報については、『WebLogic Security プログラマーズ ガイド』を参照してください。

 


Web アプリケーションでのセキュリティのコンフィグレーションの概要

Web アプリケーションにセキュリティを設定するには、認証を使用するか、Web アプリケーション内の特定のリソースへのアクセスを制限するか、またはサーブレット コードでセキュリティの呼び出しを使用します。複数のタイプのセキュリティ レルムを使用できます。セキュリティ レルムの詳細については、「セキュリティの基礎概念」を参照してください。セキュリティ レルムは複数の仮想ホスト間で共有されることに注意してください。

 


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

Web アプリケーションの認証をコンフィグレーションするには、web.xml デプロイメント記述子の <login-config> 要素を使用します。この要素では、ユーザの資格が収められるセキュリティ レルム、認証方式、および認証用リソースの場所を定義します。セキュリティ レルムの詳細については、「セキュリティの基礎概念」を参照してください。

アプリケーションのデプロイメント時に、WebLogic Server は weblogic.xml ファイルからロール情報を読み込みます。この情報は、セキュリティ レルムでコンフィグレーションされた認証プロバイダに格納するために使用します。ロール情報が認証プロバイダに格納された後は、WebLogic Server Administration Console を通じて行われた変更は weblogic.xml ファイルに保持されません。アプリケーションを再デプロイする前に (コンソールを使用して再デプロイするか、ディスク上で変更を行うか、WebLogic Server を再起動するときに行われる)、[セキュリティ|レルム|一般] タブで [デプロイメント記述子内のセキュリティ データを無視] 属性を有効にする必要があります。そうしないと、WebLogic Server Administration Console を通じて行われた変更が weblogic.xml ファイルの古いデータで上書きされます。

Web アプリケーション用の認証を設定するには、次の手順を実行します。

  1. テキスト エディタで web.xml デプロイメント記述子を開くか、Administration Console を使用します。詳細については、Web アプリケーション開発者向けツールを参照してください。

  2. <auth-method> 要素を使用して認証メソッドを指定します。以下のオプションを設定できます。

    BASIC

    基本認証では、Web ブラウザを使用してユーザ名/パスワード ダイアログ ボックスを表示します。このユーザ名とパスワードは、セキュリティ レルムに対して認証されます。

    FORM

    フォーム ベースの認証では、ユーザ名とパスワードが指定された HTML フォームを返す必要があります。フォーム要素から返されるフィールドは j_usernamej_password で、アクション属性は j_security_check でなければなりません。次に、FORM 認証を使用するための HTML コードのサンプルを示します。

    <form method=”POST” action=”j_security_check”>

    <input type=”text” name=”j_username”>
    <input type=”password” name=”j_password”>

    </form>

    この HTML フォームの生成に使用するリソースは、HTML ページ、JSP、またはサーブレットです。このリソースは、<form-login-page> 要素で定義します。

    HTTP セッション オブジェクトはログイン ページが提供されるときに作成されます。したがって、session.isNew() メソッドは、認証の成功後に提供されるページから呼び出されると FALSE を返します。

    CLIENT-CERT

    クライアント証明書を使用してリクエストを認証します。詳細については、「SSL プロトコルのコンフィグレーション」を参照してください。

  3. FORM 認証を選択した場合、HTML ページの生成に使用するリソースの場所 (<form-login-page> 要素を使用)、および失敗した認証に応答するリソースの場所 (<form-error-page> 要素を使用) も定義します。FORM 認証をコンフィグレーションする手順については、form-login-configを参照してください。

  4. <realm-name> 要素を使用して認証のレルムを指定します。特定のレルムを指定しなかった場合は、Administration Console の [Web アプリケーション|コンフィグレーション|その他] タブにある [認証レルム名] フィールドで定義されたレルムが使用されます。詳細については、form-login-configを参照してください。

  5. Web アプリケーションごとに別々にログインを定義する場合は、複数の Web アプリケーション、クッキー、および認証を参照してください。定義しない場合は、同じクッキーを使用するすべての Web アプリケーションでの認証に 1 つのサインオンが使用されます。

 


複数の Web アプリケーション、クッキー、および認証

デフォルトでは、WebLogic Server はすべての Web アプリケーションに同じクッキー名 (JSESSIONID) を割り当てます。どの種類の認証を使用する場合でも、同じクッキー名を使用する Web アプリケーションでは、認証用に 1 つのサインオンを使用します。ユーザが認証されると、その認証は、同じクッキー名を使用するすべての Web アプリケーションへのリクエストに対して有効になります。ユーザは再び認証を要求されることはありません。

Web アプリケーションごとに個別の認証が必要な場合は、Web アプリケーションにユニークなクッキー名またはクッキー パスを指定できます。CookieName パラメータでクッキー名を指定し、CookiePath パラメータでクッキー パスを指定します。これらのパラメータは、<session-descriptor> 要素の WebLogic 固有のデプロイメント記述子 weblogic.xml で定義されています。詳細については、jsp-descriptorを参照してください。

クッキー名を保持しつつ Web アプリケーションごとに別々の認証が必要な場合は、Web アプリケーションごとにクッキー パラメータ (CookiePath) を変えることができます。

サービス パック 3 では、セッション データを失うことなく、HTTP を使用して開始されたセッションで HTTPS リソースにユーザが安全にアクセスできるようにする新機能が追加されました。 この新機能を有効にするには、config.xmlWebServer 要素に AuthCookieEnabled="true" を追加します。

<WebServer Name="myserver" AuthCookieEnabled="true"/> 

AuthCookieEnabledtrue に設定すると、HTTPS 接続を介して認証するときに、WebLogic Server インスタンスはブラウザに新しいセキュアなクッキーを送信します。 一度セキュアなクッキーを設定すると、セッションはクッキーがブラウザから送信された場合にしかセキュリティ制約のある他の HTTPS リソースにアクセスできません。

 


Web アプリケーション リソースへのアクセスの制限

Web アプリケーションの特定のリソース (サーブレット、JSP、または HTML ページ) へのアクセスを制限するには、それらのリソースにセキュリティ制約を適用します。

セキュリティ制約をコンフィグレーションするには、次の手順に従います。

  1. テキスト エディタで web.xml および weblogic.xml デプロイメント記述子を開くか、Administration Console を使用します。詳細については、Web アプリケーション開発者向けツールを参照してください。

  2. WebLogic 固有のデプロイメント記述子、weblogic.xml で、セキュリティ レルムの 1 つまたは複数のプリンシパルにマップされるロールを定義します。security-roleでロールを定義します。次に、security-role-assignmentでこれらのロールをレルム内のプリンシパルにマップします。

  3. web.xml で、<web-resource-collection> 要素にネストされる <url-pattern> 要素を使用して、セキュリティ制約を適用する Web アプリケーション リソースを定義します。<url-pattern> は、ディレクトリ、ファイル名、または <servlet-mapping> です。

    また、セキュリティ制約を Web アプリケーション全体に適用する場合は、次のエントリを使用します。

    <url-pattern>/*</url-pattern>

  4. web.xml で、<web-resource-collection> 要素にネストされる <http-method> 要素を定義することによって、セキュリティ制約を適用する HTTP メソッド (GET または POST) を定義します。HTTP メソッドごとに、別々の <http-method> 要素を使用します。

  5. web.xml で、<user-data-constraint> 要素にネストされる <transport-guarantee> 要素を使用して、クライアントとサーバ間の通信に SSL を使用するかどうかを定義します。

コード リスト 5-1 セキュリティ制約のサンプル

web.xml entries:
<security-constraint>
<web-resource-collection>
<web-resource-name>SecureOrdersEast</web-resource-name>
<description>
Security constraint for
resources in the orders/east directory
</description>
<url-pattern>/orders/east/*</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>
constraint for east coast sales
</description>
<role-name>east</role-name>
<role-name>manager</role-name>
</auth-constraint>
<user-data-constraint>
<description>SSL not required</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
...

 


サーブレットでのユーザとロールのプログラマティカルな使い方

javax.servlet.http.HttpServletRequest.isUserInRole(String role) メソッドを使用すると、サーブレット コード中のユーザとロールにプログラム的にアクセスできるようサーブレットを記述できます。文字列 role は、Web アプリケーション デプロイメント記述子の <servlet> 宣言の <security-role-ref> 要素の中にネストされた <role-name> 要素に指定された名前にマップされます。<role-link> 要素は、Web アプリケーション デプロイメント記述子の <security-role> 要素で定義された <role-name> に対応します。

次のリストで例を提供します。

コード リスト 5-2 セキュリティ ロール マッピングの例

Servlet code: 
isUserInRole("manager");
web.xml entries:
<servlet>
. . .
<role-name>manager</role-name>
<role-link>mgr</role-link>
. . .
</servlet>
<security-role>
<role-name>mgr</role-name>
</security-role>
weblogic.xml entries:
<security-role-assignment>
<role-name>mgr</role-name>
<principal-name>al</principal-name>
<principal-name>george</principal-name>
<principal-name>ralph</principal-name>
</security-role-ref>

 

Back to Top Previous Next