| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング 11g リリース1(10.3.6) B61619-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング 11g リリース1(10.3.6) B61619-04 |
|
前 |
次 |
WebLogic Serverは、Webアプリケーションを保護するJava EEアーキテクチャ・セキュリティ・モデルをサポートしています。これには、宣言による認可(このドキュメントでは宣言によるセキュリティとも呼びます)とプログラムによる認可(このドキュメントではプログラムによるセキュリティとも呼びます)のサポートが含まれます。
この節では、以下のトピックを取り上げます。
|
注意: Webアプリケーションの保護には、デプロイメント記述子ファイルと管理コンソールを使用できます。このドキュメントでは、デプロイメント記述子ファイルを使用する方法について説明します。管理コンソールを使用したWebアプリケーションの保護の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。 |
WebLogic Serverは、Webアプリケーションにおけるプログラムによる認可を実装するために、HttpServletRequest.isUserInRoleメソッドとHttpServletRequest.getUserPrincipalメソッドの使用、およびデプロイメント記述子でのsecurity-role-ref要素の使用をサポートしています。
Webブラウザは、HyperText Transfer Protocol (HTTP)ポートまたはHTTP with SSL (HTTPS)ポートを介してWebLogic Serverに接続できます。HTTPポートではなくHTTPSポートを利用するメリットは2つあります。HTTPS接続を利用するメリットは以下のとおりです。
Webブラウザとサーバーの間で行われるすべての通信が暗号化されます。ユーザー名とパスワードを含め、通信がクリア・テキストで行われることはありません。
最低限の認証要件として、サーバーは身元を証明するためにWebブラウザ・クライアントに対してデジタル証明書を提示する必要があります。
双方向SSL認証を行うようにサーバーが構成された場合は、サーバーとクライアントの両方が互いにデジタル証明書を提示して、身元を証明する必要があります。
WebLogic Serverでは、ユーザーがWebブラウザを使用してHTTPポート経由でサーバーに接続するときにユーザー名とパスワードの認証が行われます。その場合、ブラウザとWebLogic Serverのインスタンスは次のように対話してユーザーを認証します(図3-1を参照)。
ユーザーは、WebブラウザでWebLogicリソースのURLを入力して、WebLogic ServerのWebLogicリソースを呼び出します。そのHTTP URLでは、たとえばhttp://myserver:7001のようにHTTPリスニング・ポートを指定します。
WebLogic ServerのWebサーバーはリクエストを受け取ります。
|
注意: WebLogic Serverでは独自のWebサーバーを用意していますが、Apache Server、Microsoft Internet Information Server、およびSun Java System Web ServerもWebサーバーとして使用できます。 |
Webサーバーは、リクエストされたWebLogicリソースがセキュリティ・ポリシーによって保護されているかどうか判別します。WebLogicリソースが保護されている場合、Webサーバーは確立されているHTTP接続を使用して、ユーザーのユーザー名とパスワードをリクエストします。
ユーザーのWebブラウザがWebサーバーからのリクエストを受け取ると、ユーザーに対してユーザー名とパスワードを要求します。
Webブラウザは、Webサーバーに対してユーザー名とパスワードと一緒にリクエストを再送信します。
WebサーバーはリクエストをWebサーバー・プラグインに転送します。WebLogic Serverでは、Webサーバー用に以下のプラグインを提供します。
Apache-WebLogic Serverプラグイン
Sun Java System Web Serverプラグイン
Internet Information Server (IIS)プラグイン
Webサーバー・プラグインは、HTTPプロトコルを使用して、ユーザーから受け取った認証データ(ユーザー名とパスワード)と一緒に認証リクエストをWebLogic Serverに送信することで認証を行います。
認証に成功すると、WebLogic Serverは、ユーザーがそのWebLogicリソースへのアクセスに必要な権限を持っているかどうかを調べます。
WebLogicリソースに対してメソッドを呼び出す前に、WebLogic Serverインスタンスはセキュリティ認可チェックを実行します。サーバーは、このチェックで、ユーザーの資格証明をセキュリティ・コンテキストから取り出し、ユーザーのセキュリティ・ロールを特定して、そのユーザーのセキュリティ・ロールを、リクエストされたWebLogicリソースのセキュリティ・ポリシーと照らし合わせ、ユーザーがWebLogicリソースに対してメソッドを呼び出す認可を持っていることを確認します。
認可が成功すると、サーバーがリクエストを遂行します。
WebLogic Serverは、WebブラウザのユーザーがHTTPSポート経由でサーバーに接続する場合に暗号化とデジタル証明書の認証を使用します。その場合、ブラウザとサーバーは次のように対話してユーザーを認証および認可します(図3-1を参照)。
ユーザーは、WebブラウザでWebLogicリソースのURLを入力して、WebLogic ServerのWebLogicリソースを呼び出します。そのHTTPS URLでは、たとえばhttps://myserver:7002のようにSSLリスニング・ポートを指定します。
WebLogic ServerのWebサーバーはリクエストを受け取ります。
|
注意: WebLogic Serverでは独自のWebサーバーを用意していますが、Apache Server、Microsoft Internet Information Server、およびSun Java System Web ServerもWebサーバーとして使用できます。 |
Webサーバーは、WebLogicリソースがセキュリティ・ポリシーによって保護されているかどうかチェックします。WebLogicリソースが保護されている場合、Webサーバーは確立されているHTTPS接続を使用して、ユーザーのユーザー名とパスワードをリクエストします。
ユーザーのWebブラウザがWebLogic Serverからのリクエストを受け取ると、ユーザーに対してユーザー名とパスワードを要求します。この手順は省略可能です。
Webブラウザは、ユーザー名とパスワードと一緒にリクエストを再送信します(サーバーからリクエストされた場合のみ供給されます)。
WebLogic Serverは、Webブラウザにデジタル証明書を提示します。
Webブラウザは、URLで使用されているサーバーの名前(たとえばmyserver)がデジタル証明書の名前と一致すること、そしてデジタル証明書が信頼できる第三者(信頼性のあるCA)によって発行されたものであることをチェックします。
双方向SSL認証を使用するよう設定されている場合、サーバーはクライアントのデジタル証明書をリクエストします。
|
注意: 1.0 Webサーバー・プロキシ・プラグインを使用して完全な双方向SSLハンドシェークを強制するようにWebLogic Serverを構成できなくても、必要に応じてクライアント証明書をサーバーに提供するようにプロキシ・プラグインを構成できます。そのためには、HTTPヘッダーのクライアント証明書をWebLogic Serverに対してエクスポートするように、プロキシ・プラグインを構成します。クライアント証明書をWebLogic Serverにエクスポートするようにプロキシ・プラグインを構成する手順については、『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』でご使用のプラグインに関する構成情報を参照してください。バージョン1.1プラグインがクライアントIDを検証するため双方向SSLサポートを提供します。ハンドシェイク・プロセス中にWebLogic Serverがクライアント証明書をリクエストすると双方向SSLが自動的に強制されます。『Oracle WebLogic ServerにおけるWebサーバー・プラグインの使用』のプラグインとWebLogic Server間の双方向SSLの構成に関する項を参照してください。 |
WebサーバーはリクエストをWebサーバー・プラグインに転送します。セキュアなプロキシが設定されていれば(HTTPSプロトコルが使用されている場合には設定されています)、Webサーバー・プラグインはまた、HTTPSプロトコルを介して、ユーザーから受け取った認証データ(ユーザー名とパスワード)と一緒にリクエストをWebLogic ServerのWebLogicリソースに送信することによって認証を実行します。
|
注意: 双方向SSL認証を使用していれば、クライアントの証明書に基づいてIDアサーションを行うようにサーバーを構成することもできます。この場合、ユーザーがユーザー名とパスワードを提供するのではなく、サーバーはクライアントの証明書からユーザー名とパスワードを取り出します。 |
認証に成功すると、WebLogic Serverは、ユーザーがそのWebLogicリソースへのアクセスに必要な権限を持っているかどうかを調べます。
WebLogicリソースに対してメソッドを呼び出す前に、サーバーはセキュリティ認可チェックを実行します。サーバーは、このチェックで、ユーザーの資格証明をセキュリティ・コンテキストから取り出し、ユーザーのセキュリティ・ロールを特定して、そのユーザーのセキュリティ・ロールを、リクエストされたWebLogicリソースのセキュリティ・ポリシーと照らし合わせ、ユーザーがWebLogicリソースに対してメソッドを呼び出す認可を持っていることを確認します。
認可が成功すると、サーバーがリクエストを遂行します。
詳細については、以下のドキュメントを参照してください。
『Oracle WebLogic Serverの保護』
Apache HTTP Serverプラグインのインストールと構成
Microsoft IISプラグインのインストールと構成
デフォルトでは、WebLogic ServerはすべてのWebアプリケーションに同じCookie名(JSESSIONID)を割り当てます。同じCookie名を使用するWebアプリケーションでは、どの種類の認証を使用する場合でも、認証用に1つのサインオンを使用します。ユーザーが認証されると、その認証は、同じCookie名を使用するすべてのWebアプリケーションへのリクエストに対して有効になります。ユーザーは再び認証を要求されることはありません。
Webアプリケーションごとに個別の認証が必要な場合は、Webアプリケーションに一意のCookie名またはCookieパスを指定できます。CookieNameパラメータでCookie名を指定し、CookiePathパラメータでCookieパスを指定します。これらのパラメータは、WebLogic固有のデプロイメント記述子のweblogic.xmlの<session-descriptor要素で定義されます。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のsession-descriptorに関する項を参照してください。
Cookie名を保持しつつWebアプリケーションごとに別々の認証が必要な場合は、WebアプリケーションごとにCookieパス・パラメータ(CookiePath)を変えることができます。
WebLogic Serverでは、セッション・データを失うことなく、HTTPを使用して開始されたセッションでHTTPSリソースにユーザーが安全にアクセスできます。この機能を利用すると、Webサイトの設計者はセッションの盗難を防止できます。この機能の詳細は、「セキュアなCookieを使用したセッション盗難の防止」を参照してください。
Webセキュリティの一般的な問題は、セッションの盗難です。この問題は、通常はCookieがネットワーク経由で転送されている間に、攻撃者がセッションCookieのコピーを取得しようとしたときに発生します。この問題は、データがクリア・テキストで(つまり、Cookieが暗号化されずに)送信されている場合にのみ発生します。
WebLogic Serverでは、セッション・データを失うことなく、HTTPを使用して開始されたセッションでHTTPSリソースにユーザーが安全にアクセスできます。この機能を有効にするには、config.xmlのWebServer要素にAuthCookieEnabled="true"を追加します。
<WebServer Name="myserver" AuthCookieEnabled="true"/>
AuthCookieEnabledをtrue(デフォルト設定)に設定すると、新しいセキュアなCookie(_WL_AUTHCOOKIE_JSESSIONID)が、HTTPS接続を介した認証時にブラウザに送信されるようになります。一度セキュアなCookieが設定されると、セッションはそのCookieがブラウザから送信された場合しかセキュリティ制約のある他のHTTPSリソースにアクセスできません。
このように、WebLogic Serverでは2つのCookie(JSESSIONIDCookieと_WL_AUTHCOOKIE_JSESSIONIDCookie)が使用されています。デフォルトでは、JSESSIONIDCookieはセキュアではありませんが、_WL_AUTHCOOKIE_JSESSIONIDCookieは常にセキュアです。セキュアなCookieは、暗号化された通信チャネルが使用されている場合のみ送信されます。標準のHTTPSログインを想定した場合(HTTPSは暗号化されたHTTP接続)、ブラウザは両方のCookieを取得します。
それ以降のHTTPアクセスでは、有効なJSESSIONIDCookieがあれば認証済みと判断されますが、HTTPSアクセスの場合は、両方のCookieがないと認証済みとは見なされません。JSESSIONIDCookieしかない場合は、再び認証する必要があります。
この機能が有効な場合は、HTTPS経由で一度ログインすると、セキュアなCookieはネットワーク上を暗号化された状態でしか送信されません。したがって途中で盗まれることはありません。ただしJSESSIONID Cookieは、それでも途中で盗まれる恐れがあります。したがって、Webサイトの設計者はすべての機密データでHTTPSが必須となるようにすることでセッションの盗難が起こらないようにできます。HTTPセッションCookieはまだ盗用に対して脆弱ですが、すべての機密を扱う処理で_WL_AUTHCOOKIE_JSESSIONID (盗まれない)が必須となっているので、それらの処理は保護されます。
weblogic.xmlデプロイメント記述子の<session-descriptor>要素で定義するCookieNameパラメータを使用して、JSESSIONIDまたは_WL_AUTHCOOKIE_JSESSIONIDのCookie名を指定することもできます。次に例を示します。
<session-descriptor>
<cookie-name>FOOAPPID</cookie-name>
</session-descriptor>
この場合、Weblogic ServerではJSESSIONIDと_WL_AUTHCOOKIE_JSESSIONIDは使用されず、かわりにFOOAPPIDと_WL_AUTHCOOKIE_FOOAPPIDが使用されます。以上を表3-1にまとめます。
WebLogic Serverは、Webブラウザに関して以下の3タイプの認証をサポートしています。
BASIC
FORM
CLIENT-CERT
以下の節では、これらのタイプの認証を使用する様々な方法を紹介します。
BASIC認証の場合、WebブラウザはWebLogicリソースのリクエストに応じてログイン画面を表示します。そのログイン画面は、ユーザー名とパスワードの入力をユーザーに要求します。図3-2は典型的なログイン画面を示します。
BASIC認証を提供するWebアプリケーションを開発するには、次の手順を実行します。
web.xmlデプロイメント記述子を作成します。このファイルには、以下の情報を含めます(例3-1を参照)。
ウェルカム・ファイルを定義します。ウェルカム・ファイルの名前はwelcome.jspです。
保護する予定のWebアプリケーション・リソース、つまりURLリソースの各セットについてセキュリティ制約を定義します。リソースの各セットは共通のURLを共有します。HTMLページ、JSP、サーブレットなどは最も一般的に保護されるURLリソースですが、他のタイプのURLリソースもサポートされています。例3-1では、URLパターンはWebアプリケーションの最上位ディレクトリに位置するwelcome.jspファイルを指しており、URLリソースへのアクセスが許可されるHTTPメソッドはPOSTとGET、セキュリティ・ロール名はwebuserとなっています。
|
注意: セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。
|
<login-config>タグを使用して、使用する認証のタイプとセキュリティ制約が適用されるセキュリティ・レルムを定義します。例3-1では、BASICタイプが指定されており、レルムはデフォルトのレルムとなっています。つまり、セキュリティ制約はWebLogic Serverインスタンスの起動時にアクティブなセキュリティ・レルムに適用されます。
1つまたは複数のセキュリティ・ロールを定義し、それらをセキュリティ制約にマップします。サンプルでは、1つのセキュリティ・ロールwebuserのみがセキュリティ制約で定義されているので、ここでは1つのセキュリティ・ロール名のみ定義されています(例3-1の<security-role>を参照)。ただし、セキュリティ・ロールは必要なだけ定義できます。
例3-1 BASIC認証のweb.xmlファイル
<?xml version='1.0' encoding='UTF-8'?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/welcome.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>webuser</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>
<security-role>
<role-name>webuser</role-name>
</security-role>
</web-app>
weblogic.xmlデプロイメント記述子を作成します。このファイルでは、セキュリティ・ロール名をユーザーおよびグループにマップします。例3-2は、weblogic.xmlファイルの<security-role>タグで定義されているwebuserセキュリティ・ロールをmyGroupというグループにマップするサンプルweblogic.xmlファイルです。プリンシパルは、ユーザーにもグループにもできるため、<principal-tag>はどちらにも使用できます。この構成の場合、WebLogic ServerはmyGroupユーザーのみに、保護されたURLリソースwelcome.jspへのアクセスを許可します。
|
注意: バージョン9.0からは、ロール・マッピングのデフォルト動作によって、weblogic.xmlに何も指定されていないと空のロール・マッピングが作成されるようになりました。バージョン8.xではweblogic.xmlファイルを含めなかった場合や、ファイルを含めたがすべてのセキュリティ・ロールのマッピングは含めなかった場合、マップされていないセキュリティ・ロールはすべて、デフォルトで、ロール名に一致する名前を持つユーザーまたはグループに設定されていました。ロール・マッピングの動作および下位互換性の設定の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ロール・マッピングの組合せを有効化」設定の理解に関する項を参照してください。 |
例3-2 BASIC認証のweblogic.xmlファイル
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<principal-name>myGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>
ユーザーがユーザー名とパスワードを入力してアクセスが許可されたときに表示される「ようこそ」画面を生成するファイルを作成します。例3-3は、サンプルのwelcome.jspファイルです。図3-3は、「ようこそ」画面を示しています。
例3-3 BASIC認証のwelcome.jspファイル
<html>
<head>
<title>Browser Based Authentication Example Welcome Page</title>
</head>
<h1> Browser Based Authentication Example Welcome Page </h1>
<p> Welcome <%= request.getRemoteUser() %>!
</blockquote>
</body>
</html>
|
注意: 例3-3において、JSPがログインしたユーザーの名前を取得するためにAPI (request.getRemoteUser())を呼び出していることに留意してください。かわりに、別のAPI (weblogic.security.Security.getCurrentSubject())を使用することもできます。このAPIを使用してユーザーの名前を取得するには、次のようにSubjectUtils APIと共に使用します。String username = weblogic.security.SubjectUtils.getUsername weblogic.security.Security.getCurrentSubject()); |
WebLogic Serverを起動し、URLリソースにアクセス可能なユーザーおよびグループを定義します。weblogic.xmlファイル(例3-2を参照)では、<principal-nameタグで、welcome.jspにアクセス可能なグループとしてmyGroupが定義されています。したがって、管理コンソールを使用してmyGroupグループを定義し、ユーザーを定義して、そのユーザーをmyGroupグループに追加します。ユーザーとグループの追加の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。
Webアプリケーションをデプロイし、前の手順で定義したユーザーを使用して保護されたURLリソースにアクセスします。
デプロイメントの手順については、「Webアプリケーションのデプロイメント」を参照してください。
Webブラウザを開き、次のURLを入力します。
http://localhost:7001/basicauth/welcome.jsp
ユーザー名とパスワードを入力します。「ようこそ」画面が表示されます。
ブラウザはユーザーの資格証明をキャッシュし、それらをサーバーに対して高い頻度で自動的に再送信します。これによって、ログアウトまたはタイムアウト後もWebLogic Serverセッションが破棄されていないように見えます。資格証明は、ブラウザに応じて、現在のブラウザ・セッションでのみキャッシュしたり、複数のセッションにまたがってキャッシュすることができます。
WebLogic Serverのセッションが破棄されたことを確認するには、javax.servlet.http.HttpSessionListenerインタフェースを実装するクラスを作成します。このインタフェースを実装すると、Webアプリケーションにおけるアクティブ・セッションのリストへの変更が通知されます。通知イベントを取得するには、対象Webアプリケーションについて、web.xmlのデプロイメント記述子で実装クラスを構成する必要があります。
セッション・リスナー・クラスを構成するには:
セッション・リスナー・クラスを作成するWebアプリケーションのweb.xmlデプロイメント記述子をテキスト・エディタで開きます。web.xmlファイルは、WebアプリケーションのWEB-INFディレクトリにあります。
web.xmlデプロイメント記述子のlistener要素を使用してイベント宣言を追加します。イベント宣言は、イベントが発生するときに起動されるイベント・リスナー・クラスを定義します。例:
<listener> <listener-class>myApp.MySessionListener</listener-class> </listener>
詳細およびガイドラインは、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のイベント・リスナー・クラスの構成に関する項を参照してください。
セッション・リスナー・クラスを作成し、デプロイします。例3-4のサンプルでは、単純なカウンタを使用してセッション数をトラッキングしています。
例3-4 セッション数のトラッキング
package myApp;
import javax.servlet.http.HttpSessionListener;
import javax.servlet.http.HttpSessionEvent;
public class MySessionListener implements HttpSessionListener {
private static int sessionCount = 0;
public void sessionCreated(HttpSessionEvent se) {
sessionCount++;
// Write to a log or do some other processing.
}
public void sessionDestroyed(HttpSessionEvent se) {
if(sessionCount > 0)
sessionCount--;
//Write to a log or do some other processing.
}
}
WebLogic Serverバージョン9.2以降では、ターゲット・リソースにおいてアクセス制御が有効になっていない場合でも、HTTP BASIC認証を使用するクライアント・リクエストはWebLogic Server認証を通過しなければなりません。
この動作は、セキュリティ構成MBeanフラグenforce-valid-basic-auth-credentialsで指定します。(DomainMBeanを使用すると、そのドメインの新しいセキュリティ構成MBeanを取得できます)。このフラグは、非セキュアなリソースへのアクセスにおいて、無効なHTTP BASIC認証資格証明によるリクエストを許可するかどうかを指定します。
|
注意: セキュリティ構成MBeanは、ドメイン全体のセキュリティ構成情報を提供します。enforce-valid-basic-auth-credentialsフラグは、ドメイン全体に影響します。 |
デフォルトでは、enforce-valid-basic-auth-credentialsフラグはtrueに設定されており、WebLogic Server認証が実行されます。認証に失敗すると、リクエストは拒否されます。したがって、ユーザーおよびパスワードの情報がWebLogic Serverに保持されている必要があります。
別の認証メカニズムを使用する場合のように、このデフォルトの動作を変更したい場合もあります。たとえば、バックエンドのWebサービスを使用してクライアントを認証する場合は、ユーザー情報をWebLogic Serverに保持する必要はありません。ただし、デフォルトの認証実施が有効になっている場合は、先にWebLogic Server認証に成功していないと、Webサービス独自の認証を実行することできません。
enforce-valid-basic-auth-credentialsフラグを明示的にfalseに設定すると、ターゲット・リソースでのアクセス制御が有効になっていないHTTP BASIC認証クライアント・リクエストのWebLogic Server認証は実行されません。
先に挙げたバックエンドWebサービスでクライアントを認証する例であれば、WebLogic Serverにユーザーに関する情報が保持されていなくても、Webサービス独自の認証を実行できます。
enforce-valid-basic-auth-credentialsフラグを設定するには、次の手順に従います。
config.xmlの<security-configuration>要素内に<enforce-valid-basic-auth-credentials>要素を追加します。
: <enforce-valid-basic-auth-credentials>false</enforce-valid-basic-auth-credentials> </security-configuration>
ドメイン内のすべてのサーバーを起動または再起動します。
enforce-valid-basic-auth-credentialsフラグの設定は、管理コンソールには表示されません。しかし、WLSTを使用すると、実行中のサーバーでの値を確認できます。enforce-valid-basic-auth-credentialsがドメイン全体の設定である点には注意してください。
例3-5に実行中のサンプル・サーバーでenforce-valid-basic-auth-credentialsの値を確認するためのWLSTセッションを示します。
例3-5 enforce-valid-basic-auth-credentialsの値の確認
wls:/offline> connect('weblogic','weblogic','t3://localhost:7001')
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'examplesServer' that belongs to domain '
wl_server'.
wls:/wl_server/serverConfig> cd('SecurityConfiguration')
wls:/wl_server/serverConfig/SecurityConfiguration> ls()
dr-- wl_server
wls:/wl_server/serverConfig/SecurityConfiguration> cd('wl_server')
wls:/wl_server/serverConfig/SecurityConfiguration/wl_server> ls()
dr-- DefaultRealm
dr-- Realms
-r-- AnonymousAdminLookupEnabled false
-r-- CompatibilityConnectionFiltersEnabled false
-r-- ConnectionFilter null
-r-- ConnectionFilterRules null
-r-- ConnectionLoggerEnabled false
-r-- ConsoleFullDelegationEnabled false
-r-- Credential ******
-r-- CredentialEncrypted ******
-r-- CrossDomainSecurityEnabled false
-r-- DowngradeUntrustedPrincipals false
-r-- EnforceStrictURLPattern true
-r-- EnforceValidBasicAuthCredentials false
:
:
WebアプリケーションでFORM認証を使用する場合は、Webアプリケーション・リソースのリクエストに応じてWebブラウザが表示するカスタム・ログイン画面とログインが失敗した場合に表示されるエラー画面を用意します。ログイン画面はHTMLページ、JSP、またはサーブレットを使用して生成できます。フォームベースのログインのメリットは、これらの画面を完全に管理できるので、アプリケーションやエンタープライズ・ポリシー/ガイドラインの要件にあわせてそれらを設計できることです。
そのログイン画面は、ユーザー名とパスワードの入力をユーザーに要求します。図3-4は、JSPを使用して生成される典型的なログイン画面を、例3-6はソース・コードを示しています。
例3-6 フォーム-ベースのログイン画面(login.jsp)のソース・コード
<html>
<head>)
<title>Security WebApp login page</title>
</head>
<body bgcolor="#cccccc">
<blockquote>
<img src=Button_Final_web.gif align=right>
<h2>Please enter your user name and password:</h2>
<p>
<form method="POST" action="j_security_check">
<table border=1>
<tr>
<td>Username:</td>
<td><input type="text" name="j_username"></td>
</tr>
<tr>
<td>Password:</td>
<td><input type="password" name="j_password"></td>
</tr>
<tr>
<td colspan=2 align=right><input type=submit
value="Submit"></td>
</tr>
</table>
</form>
</blockquote>
</body>
</html>
例3-7 ログイン・エラー画面のソース・コード
<html>
<head>
<title>Login failed</title>
</head>
<body bgcolor=#ffffff>
<blockquote>
<img src=/security/Button_Final_web.gif align=right>
<h2>Sorry, your user name and password were not recognized.</h2>
<p><b>
<a href="/security/welcome.jsp">Return to welcome page</a> or
<a href="/security/logout.jsp">logout</a>
</b>
</blockquote>
</body>
</html>
FORM認証を提供するWebアプリケーションを開発するには、次の手順を実行します。
web.xmlデプロイメント記述子を作成します。このファイルには、以下の情報を含めます(例3-8を参照)。
ウェルカム・ファイルを定義します。ウェルカム・ファイルの名前はwelcome.jspです。
保護する予定のURLリソースの各セットについてセキュリティ制約を定義します。URLリソースの各セットは共通のURLを共有します。HTMLページ、JSP、サーブレットなどは最も一般的に保護されるURLリソースですが、他のタイプのURLリソースもサポートされています。例3-8では、URLパターンは/admin/edit.jspを指しており(したがって、Webアプリケーションのadminサブディレクトリに配置されたedit.jspファイルが保護されます)、URLリソースへのアクセスが許可されるHTTPメソッド(GET)が定義され、セキュリティ・ロール名adminが定義されています。
|
注意: セキュリティ・ロール名でハイフンは使用しないでください。ハイフンのあるセキュリティ・ロール名は管理コンソールで修正できません。また、推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。 |
使用する認証のタイプとセキュリティ制約が適用されるセキュリティ・レルムを定義します。この場合は、FORMタイプが指定されており、レルムは指定されていないのでデフォルトのレルムになります。つまり、セキュリティ制約はWebLogic Serverインスタンスの起動時にアクティブなセキュリティ・レルムに適用されます。
1つまたは複数のセキュリティ・ロールを定義し、それらをセキュリティ制約にマップします。サンプルでは、1つのセキュリティ・ロールadminのみがセキュリティ制約で定義されているので、ここでは1つのセキュリティ・ロール名のみ定義されています。ただし、セキュリティ・ロールは必要なだけ定義できます。
例3-8 FORM認証のweb.xmlファイル
<?xml version='1.0' encoding='UTF-8'?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>AdminPages</web-resource-name>
<description>
These pages are only accessible by authorized
administrators.
</description>
<url-pattern>/admin/edit.jsp</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>
These are the roles who have access.
</description>
<role-name>
admin
</role-name>
</auth-constraint>
<user-data-constraint>
<description>
This is how the user data must be transmitted.
</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/fail_login.html</form-error-page>
</form-login-config>
</login-config>
<security-role>
<description>
An administrator
</description>
<role-name>
admin
</role-name>
</security-role>
</web-app>
weblogic.xmlデプロイメント記述子を作成します。このファイルでは、セキュリティ・ロール名をユーザーおよびグループにマップします。例3-9は、web.xmlファイルの<security-role>タグで定義されているadminセキュリティ・ロールをsupportGroupというグループにマップするサンプルweblogic.xmlファイルです。この構成の場合、WebLogic ServerはsupportGroupグループのユーザーのみに、保護されたWebLogicリソースへのアクセスを許可します。ただし、管理コンソールを使用すると、他のグループも保護されたWebLogicリソースへのアクセスが許可されるようにWebアプリケーションのセキュリティ・ロールを修正できます。
例3-9 FORM認証のweblogic.xmlファイル
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<weblogic-web-app>
<security-role-assignment>
<role-name>admin</role-name>
<principal-name>supportGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>
ユーザーがURLを入力して保護されたWebアプリケーション・リソースをリクエストしたときに「ようこそ」画面を生成するWebアプリケーション・ファイルを作成します。例3-10は、サンプルのwelcome.jspファイルです。図3-3は、「ようこそ」画面を示しています。
例3-10 FORM認証のwelcome.jspファイル
<html>
<head>
<title>Security login example</title>
</head>
<%
String bgcolor;
if ((bgcolor=(String)application.getAttribute("Background")) ==
null)
{
bgcolor="#cccccc";
}
%>
<body bgcolor=<%="\""+bgcolor+"\""%>>
<blockquote>
<img src=Button_Final_web.gif align=right>
<h1> Security Login Example </h1>
<p> Welcome <%= request.getRemoteUser() %>!
<p> If you are an administrator, you can configure the background
color of the Web Application.
<br> <b><a href="admin/edit.jsp">Configure background</a></b>.
<% if (request.getRemoteUser() != null) { %>
<p> Click here to <a href="logout.jsp">logout</a>.
<% } %>
</blockquote>
</body>
</html>
|
注意: 例3-3において、JSPがログインしたユーザーの名前を取得するためにAPI (request.getRemoteUser())を呼び出していることに留意してください。かわりに、別のAPI (weblogic.security.Security.getCurrentSubject())を使用することもできます。このAPIを使用してユーザーの名前を取得するには、次のようにSubjectUtils APIと共に使用します。String username = weblogic.security.SubjectUtils.getUsername weblogic.security.Security.getCurrentSubject()); |
WebLogic Serverを起動し、URLリソースにアクセス可能なユーザーおよびグループを定義します。weblogic.xmlファイル(例3-9を参照)では、<role-nameタグでadminがedit.jspファイルにアクセス可能なグループとして定義され、ユーザーjoeがそのグループのメンバーとして定義されています。したがって、管理コンソールを使用してadminグループを定義し、ユーザーjoeを定義して、joeをadminグループに追加します。他のユーザーを定義してグループに追加することもでき、その追加ユーザーも保護されたWebLogicリソースにアクセスすることができます。ユーザーとグループの追加の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。
Webアプリケーションをデプロイし、前の手順で定義したユーザーを使用して保護されたWebアプリケーション・リソースにアクセスします。
デプロイメントの手順については、「Webアプリケーションのデプロイメント」を参照してください。
Webブラウザを開き、次のURLを入力します。
http://hostname:7001/security/welcome.jsp
ユーザー名とパスワードを入力します。「ようこそ」画面が表示されます。
WebアプリケーションでIDアサーションを使用すると、認証を目的としてクライアントのIDを検証できます。IDアサーションを使用するときには、以下の要件を満たす必要があります。
認証のタイプはCLIENT-CERTに設定する必要があります。
サーバーにIDアサーション・プロバイダが構成されている必要があります。WebブラウザまたはJavaクライアントがセキュリティ・ポリシーで保護されたWebLogic Serverリソースをリクエストする場合、WebLogic ServerはWebブラウザまたはJavaクライアントがIDを持つことを要求します。WebLogic IDアサーション・プロバイダは、WebブラウザまたはJavaクライアントからのトークンをWebLogic Serverセキュリティ・レルムのユーザーにマップします。IDアサーション・プロバイダの構成方法の詳細は、『Oracle WebLogic Serverの保護』のIDアサーション・プロバイダの構成に関する項を参照してください。
トークンの値に対応するユーザーは、サーバーのセキュリティ・レルムで定義されていなければなりません。定義されていない場合、クライアントは保護されているWebLogicリソースにアクセスできません。サーバーにおけるユーザーの構成の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。
Webアプリケーションで双方向SSLを使用すると、クライアントが、それがそうであると主張するクライアントであることを検証できます。双方向SSLを使用するときには、以下の要件を満たす必要があります。
認証のタイプはCLIENT-CERTに設定する必要があります。
サーバーは、双方向SSLに合せて構成する必要があります。SSLとデジタル証明書の使用の詳細は、第5章「JavaクライアントでのSSL認証の使用」を参照してください。サーバーにおけるSSLの構成の詳細は、『Oracle WebLogic Serverの保護』のSSLの構成に関する項を参照してください。
クライアントは、サーバーのWebアプリケーションにアクセスするためにHTTPSを使用する必要があります。
サーバーにIDアサーション・プロバイダが構成されている必要があります。WebブラウザまたはJavaクライアントがセキュリティ・ポリシーで保護されたWebLogic Serverリソースをリクエストする場合、WebLogic ServerはWebブラウザまたはJavaクライアントがIDを持つことを要求します。WebLogic IDアサーション・プロバイダを使用すると、WebブラウザまたはJavaクライアントのデジタル証明書をWebLogic Serverセキュリティ・レルム内のユーザーにマップするユーザー名マッパーをサーバーで使用できます。セキュリティ・プロバイダの構成方法の詳細は、『Oracle WebLogic Serverの保護』のWebLogicセキュリティ・プロバイダの構成に関する項を参照してください。
クライアントのデジタル証明書のSubject's Distinguished Name (SubjectDN)属性に対応するユーザーは、サーバーのセキュリティ・レルムで定義されている必要があります。定義されていないと、クライアントには保護されたWebLogicリソースへのアクセスが許可されません。サーバーにおけるユーザーの構成の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のユーザー、グループおよびセキュリティ・ロールに関する項を参照してください。
|
注意: SSL認証を使用する場合、サーバーのSSL構成を管理コンソールで指定するので、web.xmlおよびweblogic.xmlファイルを使用してサーバーの構成を指定する必要はありません。 |
Servlet 2.4仕様(http://www.oracle.com/technetwork/java/javaee/servlet/index.html#specs)では、Webアプリケーションで使用する認証方法(BASIC、FORM、その他)を定義できます。WebLogic Serverはauth-methodセキュリティ・モジュールを提供しています。このモジュールを使用すると、複数の認証方式を(カンマ区切りのリストとして)定義できるため、コンテナはフォールバック・メカニズムを提供できます。認証は、auth-methodリストで値が定義されている順序で試行されます。
たとえば、web.xmlファイルのlogin-config要素に次のauth-methodリストを定義できます。
<login-config> <auth-method>CLIENT-CERT,BASIC</auth-method> </login-config>
コンテナは最初に、CLIENT-CERT値を確認して認証を試みます。これに失敗すると、コンテナはBASIC認証のユーザー・エージェントを再試行します。
FORMまたはBASICのいずれかが構成される場合、これらはユーザーとの往復の対話が必要なため、リストの最後に指定する必要があります。ただし、FORMとBASICの両方をauth-method値のリスト内に一緒に指定することはできません。
auth-method認証のセキュリティは、以下の2つの方法で構成できます。
web.xmlファイルのlogin-config要素にauth-method値をカンマ区切りのリストとして定義します。
auth-method値をRealmMBean上でカンマ区切りのリストとして定義し、web.xmlのlogin-config要素でREALM値を使用します(このようにすると、Webアプリケーションはセキュリティ・レルムから認証方式を取得します)。
WebLogic Java Management Extensions (JMX)を使用すると、RealmMBeanにアクセスしてセキュリティ・リソースを作成および管理できます。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic ServerサブシステムMBeanの概要に関する項を参照してください。
Webブラウザでは、JFC (Java Foundation Classes)のSwingコンポーネントを使用して開発されたグラフィカル・ユーザー・インタフェース(GUI)を操作することもできます。
Swingコンポーネントを使用してアプリケーションおよびアプレットのGUI (グラフィカル・ユーザー・インタフェース)を作成する方法については、JFC/Swingを使用したGUIの作成チュートリアル(Swingチュートリアル)を参照してください。このチュートリアルは、Web(http://download.oracle.com/javase/tutorial/uiswing/)で入手できます。
SwingベースのGUIを開発したら、「FORM認証Webアプリケーションの開発」を参照し、Swingベースの画面を使用して、FORM認証を提供するWebアプリケーションの開発に必要な手順を実行します。
|
注意: SwingベースのGUIを開発する場合、swingイベント・スレッドの子スレッドにJava仮想マシン全体のユーザーを使用しないでください。これはJava EEに準拠していないので、通常はシン・クライアントやIIOPでは動作しません。かわりに、以下のいずれかの方法を用います。
|
開発モードで動作しているサーバーにWebアプリケーションをデプロイするには、次の手順を実行します。
|
注意: 開発モードまたは本番モードでのWebアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.deployerによるアプリケーションおよびモジュールのデプロイに関する項を参照してください。 |
Webアプリケーションのファイルのディレクトリ構造を構築します。図3-6は、basicauthというWebアプリケーションのディレクトリ構造を示しています。最上位ディレクトリにはWebアプリケーションの名前を割り当て、サブディレクトリはWEB-INFという名前にする必要があります。
展開ディレクトリ形式、つまりJavaアーカイブ(jar)ではない形式のアプリケーションをデプロイするには、ただ単純にディレクトリをサーバー上のapplicationsディレクトリに移動します。たとえば、basicauth Webアプリケーションは次の位置にデプロイします。
WL_HOME\user_projects\domains\mydomain\applications\basicauth
WebLogic Serverインスタンスが動作している場合、アプリケーションは自動デプロイされるはずです。管理コンソールを使用すると、アプリケーションがデプロイされたことを確認できます。
WebLogic Serverインスタンスが動作していない場合は、サーバーを起動するとアプリケーションは自動デプロイされます。
まだしていない場合は、管理コンソールを使用して、Webアプリケーションにアクセスできるユーザーおよびグループを構成します。保護されたWebLogicリソースへのアクセスを許可されるユーザーおよびグループを判別するには、weblogic.xmlファイルを調べます。たとえば、basicauthサンプルのweblogic.xmlファイル(例3-2)では、myGroupがwelcome.jspファイルにアクセスできる唯一のグループとして定義されています。
セキュアなWebアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.deployerによるアプリケーションおよびモジュールのデプロイに関する項を参照してください。
宣言によるセキュリティは、以下の3つの方法で実装できます。
管理コンソールを介したセキュリティ・プロバイダ: 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』で説明されています。
JACC (Java Authorization Contract for Containers): 「Java Authorization Contract for Containersの使用」で説明されています。
デプロイメント記述子 - この項で説明します。
これら3つのうちどの方法を使用するかは、JACCフラグとセキュリティ・モデルによって定義されます。(セキュリティ・モデルについては、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のEJBおよびWebアプリケーション・リソースの保護のオプションに関する項を参照してください。)
Webアプリケーションに宣言によってセキュリティを実装するには、デプロイメント記述子(web.xmlおよびweblogic.xml)を使用してセキュリティ要件を定義します。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、サーブレット・コンテナがセキュリティ定義を使って、要件を実施します。デプロイメント記述子の使い方については、「セキュアなWebアプリケーションの開発」を参照してください。
デプロイメント記述子およびexternally-defined要素を使用してWebアプリケーションのセキュリティを宣言によって構成する方法については、「externally-defined」を参照してください。
管理コンソールを使用してWebアプリケーションのセキュリティを構成する方法の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
以下のトピックでは、Webアプリケーションのセキュリティ要件を定義するためにweb.xmlおよびweblogic.xmlファイルで使用されるデプロイメント記述子の要素について説明します。
以下のweb.xmlのセキュリティ関連のデプロイメント記述子の要素が、WebLogic Serverでサポートされています。
省略可能なauth-constraint要素では、このセキュリティ制約で定義されたWebリソースの集合にアクセスするグループまたはプリンシパルを定義します。
|
注意: auth-constraint要素で保護されるリソースは、INTEGRALまたはCONFIDENTIALの<transport-guarantee>を含むuser-data-constraint要素でも保護する必要があります。
「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic Serverでは |
次の表では、auth-constraint要素内で定義できる要素について説明します。
表3-2 auth-constraint要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
このセキュリティ制約の説明文。 |
<role-name> |
省略可能 |
この |
security-constraint要素は、web-resource-collection要素で定義されたリソースの集合へのアクセス権限を定義するためにweb.xmlファイルで使用されます。
|
注意: auth-constraint要素で保護されるリソースは、INTEGRALまたはCONFIDENTIALの<transport-guarantee>を含むuser-data-constraint要素でも保護する必要があります。
「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic Serverでは |
次の表では、security-constraint要素内で定義できる要素について説明します。
表3-3 security-constraint要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<web-resource-collection> |
必須 |
このセキュリティ制約が適用されるWebアプリケーションのコンポーネントを定義します。詳細については、以下を参照。web-resource-collection |
<auth-constraint> |
省略可能 |
このセキュリティ制約で定義されるWebリソースの集合にアクセスするグループまたはプリンシパルを定義します。詳細については、「auth-constraint」を参照してください。 |
<user-data-constraint> |
省略可能 |
クライアントとサーバー間でやり取りされるデータの保護方法を定義します。詳細については、user-data-constraintを参照してください。 |
例3-11は、security-constraint要素を使用して、web.xmlでSecureOrdersEastリソースのセキュリティを定義する方法を示しています。
例3-11 セキュリティ制約の例
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>
...
security-role要素には、セキュリティ・ロールの定義が指定されます。定義は、セキュリティ・ロールの説明(オプション)とセキュリティ・ロール名から成ります。
次の表では、security-role要素内で定義できる要素について説明します。
表3-4 security-role要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
セキュリティ・ロールの説明文。 |
<role-name> |
必須 |
ロール名。ここで使用する名前は、WebLogic固有のデプロイメント記述子 |
security-role-ref要素は<security-role>で定義されたセキュリティ・ロール名を、サーブレットのロジックでハード・コード化される代替ロール名にリンクします。この特別な抽象化レイヤーによって、サーブレット・コードを変更しなくてもデプロイメント時にサーブレットを構成できるようになります。
次の表では、security-role-ref要素内で定義できる要素について説明します。
表3-5 security-role-ref要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
ロールの説明文。 |
<role-name> |
必須 |
サーブレット・コード内で使用されるセキュリティ・ロールまたはプリンシパルの名前を定義します。 |
<role-link> |
必須 |
後にデプロイメント記述子内の |
user-data-constraint要素は、クライアントとサーバー間でやり取りされるデータの保護方法を定義します。
|
注意: auth-constraint要素で保護されるリソースは、INTEGRALまたはCONFIDENTIALの<transport-guarantee>を含むuser-data-constraint要素でも保護する必要があります。
「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic Serverでは |
次の表では、user-data-constraint要素内で定義できる要素について説明します。
表3-6 user-data-constraint要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
説明文。 |
<transport-guarantee> |
必須 |
クライアントとサーバー間でやり取りされるデータのセキュリティ要件を指定します。 指定できる値:
|
web-resource-collection要素は、セキュリティ制約を適用するWebアプリケーションのリソースおよびHTTPメソッドのサブセットを識別するために使用します。HTTPメソッドが指定されていない場合、セキュリティ制約はすべてのHTTPメソッドに適用されます。
次の表では、web-resource-collection要素内で定義できる要素について説明します。
表3-7 web-resource-collection要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<web-resource-name> |
必須 |
Webリソースの集合の名前。 |
<description> |
省略可能 |
Webリソースの説明文。 |
<url-pattern> |
必須 |
Webリソースの集合のマッピング、つまり場所。 URLパターンには、Javaサーブレット仕様バージョン2.4(JSR-000154)のセクション11.2( パターン |
<http-method> |
省略可能 |
クライアントがWebリソースの集合にアクセスしようとするときにセキュリティ制約を適用する ここで |
以下のweblogic.xmlのセキュリティ関連のデプロイメント記述子の要素が、WebLogic Serverでサポートされています。
weblogic.xmlデプロイメント記述子の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のXMLデプロイメント記述子に関する項を参照してください。
weblogic.xml要素の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント記述子の要素に関する項を参照してください。
externally-defined要素を使用すると、web.xmlデプロイメント記述子のrole-name要素によって定義されたセキュリティ・ロールが管理コンソールで指定したマッピングを使用するよう指定できます。この要素を使用することで、特定のWebアプリケーションのデプロイメント記述子に定義されたセキュリティ・ロールごとに特定のセキュリティ・ロール・マッピングを指定する必要がなくなります。このため、同じセキュリティ・レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、管理コンソールを使用して他のアプリケーションのセキュリティを指定および変更できます。
サーバーのロール・マッピングの動作は、管理コンソールでどのセキュリティ・デプロイメント・モデルを選択したかによって異なります。セキュリティ・デプロイメント・モデルの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のEJBおよびWebアプリケーション・リソースの保護のオプションに関する項を参照してください。
|
注意: セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。
|
例3-12と例3-13は、weblogic.xmlファイルでexternally-defined要素を使用する方法を比較して示しています。例3-13で、weblogic.xml内の「webuser」のexternally-defined要素は、セキュリティがgetReceiptsメソッドにおいて正しく構成されるには管理コンソールでwebuserに対応するプリンシパルが作成される必要がある、ということを意味します。
|
注意: 大量のプリンシパルをリストする必要がある場合は、ユーザーのかわりにグループを指定することを検討してください。指定したユーザーが多すぎると、パフォーマンスが低下するおそれがあります。 |
例3-12 web.xmlファイルとweblogic.xmlファイルを使用したセキュリティ・ロールとプリンシパルのセキュリティ・レルムへのマッピング
web.xml entries:
<web-app>
...
<security-role>
<role-name>webuser</role-name>
</security-role>
...
</web-app>
<weblogic.xml entries:
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<principal-name>myGroup</principal-name>
<principal-name>Bill</principal-name>
<principal-name>Mary</principal-name>
</security-role-assignment>
</weblogic-web-app>
例3-13 Webアプリケーションのデプロイメント記述子でのexternally-definedタグの使用
web.xml entries:
<web-app>
...
<security-role>
<role-name>webuser</role-name>
</security-role>
...
</web-app>
<weblogic.xml entries:
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<externally-defined/>
</security-role-assignment>
管理コンソールを使用してWebアプリケーションのセキュリティを構成する方法の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
run-as-principal-name要素では、対応するweb.xmlファイルのrun-as要素で定義されるセキュリティ・ロールに使用するプリンシパル名を指定します。
run-as-role-assignment要素は、対応するweb.xmlファイルのrole-name要素で定義されるロール名をシステム内の有効なユーザー名にマップします。この値は、servlet-descriptorのrun-as-principal-name要素によって任意のサーブレットについてオーバーライドできます。ロール名のrun-as-role-assignment要素がない場合は、security-role-assignment要素に定義されている最初のprincipal-nameをWebアプリケーション・コンテナが選択します。
次の表では、run-as-role-assignment要素内で定義できる要素について説明します。
表3-8 run-as-role-assignment要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<role-name> |
必須 |
対応する |
<run-as-principal-name> |
必須 |
対応する |
例3-14は、run-as-role-assignment要素を使用して、SnoopServletを常にユーザーjoeとして実行させる方法を示しています。
例3-14 run-as-role-assignment要素の例
web.xml:
<servlet>
<servlet-name>SnoopServlet</servlet-name>
<servlet-class>extra.SnoopServlet</servlet-class>
<run-as>
<role-name>runasrole</role-name>
</run-as>
</servlet>
<security-role>
<role-name>runasrole</role-name>
</security-role>
weblogic.xml:
<weblogic-web-app>
<run-as-role-assignment>
<role-name>runasrole</role-name>
<run-as-principal-name>joe</run-as-principal-name>
</run-as-role-assignment>
</weblogic-web-app>
security-permission-spec要素は、セキュリティ・ポリシー・ファイル構文に基づいて単一のセキュリティ許可を指定します。Sunのセキュリティ許可仕様の実装については、次のURLを参照してください。
http://download.oracle.com/javase/6/docs/technotes/guides/security/PolicyFiles.html#FileSyntax
|
注意: オプションのcodebaseおよびsignedBy句は無視してください。 |
例3-15は、security-permission-spec要素を使用して、java.net.SocketPermissionクラスに許可を付与する方法を示しています。
例3-15 security-permission-spec要素の例
<weblogic-web-app>
<security-permission>
<description>Optional explanation goes here</description>
<security-permission-spec>
<!--
A single grant statement following the syntax of
http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax,
without the "codebase" and "signedBy" clauses, goes here. For example:
-->
grant {
permission java.net.SocketPermission "*", "resolve";
};
</security-permission-spec>
</security-permission>
</weblogic-web-app>
例3-15では、permission java.net.SocketPermissionは許可クラス名を、"*"はターゲット名を、resolveはアクション(host/IP名サービスのルックアップを解決する)を示します。
security-role-assignment要素は、セキュリティ・ロールとWebLogic Serverセキュリティ・レルムの1つまたは複数のプリンシパルとのマッピングを宣言します。
|
注意: エンタープライズ・アプリケーションのweblogic-application.xmlデプロイメント記述子でsecurity-role-assignment要素を使用する方法の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。 |
例3-16は、security-role-assignment要素を使用してプリンシパルをPayrollAdminロールに割り当てる方法を示しています。
|
注意: 大量のプリンシパルをリストする必要がある場合は、ユーザーのかわりにグループを指定することを検討してください。指定したユーザーが多すぎると、パフォーマンスが低下するおそれがあります。 |
サーブレットを記述して、そのサーブレット・コードでプログラム的にユーザーとセキュリティ・ロールにアクセスできます。そのためには、サーブレットのコードでjavax.servlet.http.HttpServletRequest.getUserPrincipalおよびjavax.servlet.http.HttpServletRequest.isUserInRole(String role)メソッドを使用します。
getUserPrincipal()メソッドは、Webアプリケーションの現在のユーザーを特定するために使用します。このメソッドは、1ユーザーが存在する場合にWLSUser Principalを返します。WLSUser Principalが複数の場合、このメソッドは、Subject.getPrincipals().iterator()メソッドで指定された順序の1番目を返します。WLSUser Principalが存在しない場合、getUserPrincipal()メソッドはWLSGroup Principal以外の1番目を返します。Principalが存在しない場合、またはすべてのPrincipalがWLSGroup型の場合、このメソッドはnullを返します。この動作は、weblogic.security.SubjectUtils.getUserPrincipal()メソッドのセマンティクスと同じです。
getUserPrincipal()メソッドの使用方法の詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.htmlを参照してください。
javax.servlet.http.HttpServletRequest.isUserInRole(String role)メソッドは、認証されたユーザーが、指定された論理セキュリティ「ロール」を付与されているかどうかを示すブール値を返します。ユーザーが認証されていない場合、このメソッドはfalseを返します。
isUserInRole()メソッドは、セキュリティ・ロールをセキュリティ・レルムのグループ名にマップします。例3-17は、web.xmlファイルでセキュリティ・ロールを定義するために<servlet>要素と一緒に使用される要素を示しています。
例3-17 isUserInRoleのweb.xmlおよびweblogic.xmlの要素
Begin web.xml entries:
...
<servlet>
<security-role-ref>
<role-name>user-rolename</role-name>
<role-link>rolename-link</role-link>
</security-role-ref>
</servlet>
<security-role>
<role-name>rolename-link</role-name>
</security-role>
...
Begin weblogic.xml entries:
...
<security-role-assignment>
<role-name>rolename-link</role-name>
<principal-name>groupname</principal>
<principal-name>username</principal>
</security-role-assignment>
...
文字列roleは、web.xmlデプロイメント記述子の<servlet>宣言の<security-role-ref>要素の中にネストされた<role-name>要素で提供される名前にマップされます。<role-name>要素は、サーブレット・コードで使用されるセキュリティ・ロールまたはprincipal(ユーザーまたはグループ)の名前を定義します。<role-link>要素は、weblogic.xmlデプロイメント記述子の<security-role-assignment>要素で定義された<role-name>に対応します。
|
注意: セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。
|
たとえば、クライアントがmanagerというセキュリティ・ロールのBillというユーザーでログインに成功している場合、次のメソッドはtrueを返します。
request.isUserInRole("manager")
例3-18は例を示しています。
例3-18 セキュリティ・ロール・マッピングの例
Servlet code:
out.println("Is the user a Manager? " +
request.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>bostonManagers</principal-name>
<principal-name>Bill</principal-name>
<principal-name>Ralph</principal-name>
</security-role-ref>
一部のアプリケーションでは、プログラムによる認証を使用するのが適切です。
WebLogic Serverは、サーバー側のAPIとしてweblogic.servlet.security.ServletAuthenticationを備えています。このAPIは、サーブレット・アプリケーション内からプログラムによる認証をサポートします。weblogic.servlet.security.ServletAuthentication APIを使用すると、ユーザーを認証してログインできます。
いったんログインが完了すると、標準のメカニズムを使用してログインしたかのように感じられます。
ServletAuthentication APIと一緒にWebLogicが提供するweblogic.security.SimpleCallbackHandlerクラスまたはweblogic.security.URLCallbackHandlerクラスのうちいずれかを使用できます。これらのクラスの詳細は、WebLogicクラスのJavadocを参照してください。
例3-19は、SimpleCallbackHandlerを使用する例を示しています。例3-20は、URLCallbackHandlerを使用する例を示しています。
例3-19 SimpleCallbackHandlerクラスを使用したプログラムによる認証コードの一部
CallbackHandler handler = new SimpleCallbackHandler(username,
password);
Subject mySubject =
weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
// Where request is the httpservletrequest object.
例3-20 URLCallbackHandlerクラスを使用したプログラムによる認証コードの一部
CallbackHandler handler = new URLCallbackHandler(username,
password);
Subject mySubject =
weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
// Where request is the httpservletrequest object.
HttpSessionがサーブレットで生成されると、一意のIDと関連付けられます。ブラウザは、このセッションIDをそのリクエストに付与し、サーバーが再びセッション・データを見つけられるようにする必要があります。
「セッション固定化」と呼ばれる種類の攻撃を回避するには、ログイン時にユーザーのセッションを変更する必要があります。これを実行するには、loginメソッドを呼び出した後、weblogic.servlet.security.ServletAuthenticationのgenerateNewSessionIDメソッドを呼び出します。
generateNewSessionIDメソッドは、現在のすべてのセッション情報IDを完全に別のセッションIDに移動し、当該セッションを新しいIDに関連付けます。
|
注意: セッション自体に変更はなく、その識別子のみが変更されます。 |
レガシー・アプリケーションは、ログイン前後に残っているIDと同一のセッションIDに依存できます。generateNewSessionIDを呼び出すと、このようなアプリケーションが壊れてしまいます。このような依存関係はアプリケーションに構築しないことをお薦めします。ただし、構築する場合またはこの種類のレガシー・アプリケーションを処理する場合は、SSLを使用してアプリケーションに対するすべてのアクセスを保護することをお薦めします。
デフォルトでは、WebLogicコンテナはプログラム以外によるログインのIDを自動的に再生成します。
generateNewSessionID()メソッドに関する追加情報は、ServletAuthenticationを参照してください。
