WebLogic Security プログラマーズ ガイド
![]() |
![]() |
![]() |
![]() |
WebLogic Server は、Web アプリケーションを保護する J2EE アーキテクチャ セキュリティ モデルをサポートしています。これには、宣言による認可 (このマニュアルでは宣言によるセキュリティとも呼ぶ) とプログラムによる認可 (このマニュアルではプログラムによるセキュリティとも呼ぶ) のサポートが含まれます。
注意 : Web アプリケーションの保護には、デプロイメント記述子ファイルと Administration Console を使用できます。このマニュアルでは、デプロイメント記述子ファイルを使用する方法について説明します。Administration Console を使用しての Web アプリケーションの保護については、『WebLogic リソースのセキュリティ』を参照してください。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3 Authorization」に以下のような記述があります。
「J2EE アーキテクチャにおいて、コンテナはホストするコンポーネントとその呼び出し側との間の認可境界として機能します。認可境界はコンテナの認証境界内に存在するので、正常に認証が実行される中で認可が考慮されます。着信呼び出しの場合、コンテナは呼び出し側の資格のセキュリティ属性と、対象コンポーネントのアクセス制御ルールを比較します。ルール要件が満たされていれば、呼び出しは許可されます。 それ以外の場合、この呼び出しは拒否されます。」
「アクセス制御ルールの定義には、能力とパーミッションという 2 つの基本的アプローチが存在します。能力は呼び出し側が実行できる操作、パーミッションは操作を実行できるユーザを焦点とします。J2EE アプリケーション プログラミング モデルは、パーミッションを焦点とします。J2EE アーキテクチャにおいて、デプロイヤの役割はアプリケーションのパーミッション モデルをその操作環境におけるユーザの能力にマップすることです。」
上記のマニュアルでは、J2EE アーキテクチャを使用してアプリケーション リソースへのアクセスを制御する 2 つの方法、宣言による認可とプログラムによる認可について説明しています。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html からオンラインで入手できます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.1 Authorization」に以下のような記述があります。
WebLogic Server は Web アプリケーションにおいて宣言による認可を実装するためのデプロイメント記述子の使用をサポートしています。
注意 : 宣言による認可は、このマニュアルでは宣言によるセキュリティとも呼ばれます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html からオンラインで入手できます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.2 Programmatic Authorization」に以下のような記述があります。
「J2EE コンテナは、コンポーネントにメソッド呼び出しをディスパッチする前に、アクセス制御の決定を行います。コンポーネントの論理または状態は、これらのアクセス決定を考慮に入れません。しかし、コンポーネントは EJBContext.isCallerInRole (エンタープライズ Bean コード用) および HttpServletRequest.isUserInRole (Web コンポーネント用) の 2 つのメソッドを使用して、きめ細かいアクセス制御を行うことが可能です。コンポーネントはこれらのメソッドを使用して、呼び出しのパラメータ、コンポーネントの初期状態、または呼び出しの時間などその他の要因に基づき、コンポーネントによって選択された特権が呼び出し側に付与されているかどうかを判断します。」
「これらの機能の 1 つを呼び出すコンポーネントのアプリケーション コンポーネント プロバイダは、すべての呼び出しで使用されるあらゆる個別の roleName 値を宣言する必要があります。これらの宣言は、デプロイメント記述子では security-role-ref
要素として登場します。各 security-role-ref
要素は、アプリケーションに roleName として組み込まれた特権名をセキュリティ ロールにリンクします。最終的には、デプロイヤはアプリケーションに組み込まれた特権名と、デプロイメント記述子で定義されたセキュリティ ロールとの間のリンクを確立します。特権名とセキュリティ ロールの間のリンクは、同じアプリケーション内でもコンポーネントごとに異なる場合があります。」
「特定の特権をテストするだけでなく、アプリケーション コンポーネントでは EJBContext.getCallerPrincipal
または HttpServletRequest.getUserPrincipal
を使用して取得した呼び出し側 ID と、作成時の状態のコンポーネントに組み込まれている識別された呼び出し側 ID を比較できます。呼び出し側 ID が、識別された呼び出し側 ID に等しければ、コンポーネントは呼び出し側に処理の続行を許可できます。等しくなければ、コンポーネントは呼び出し側がそれ以上の対話を行わないようにできます。コンテナによって返される呼び出し側のプリンシパルは、呼び出し側が使用した認証メカニズムによって決まります。また、同じメカニズムによる同じユーザ認証に対してでも、異なったベンダからのコンテナは異なったプリンシパルを返す場合があります。プリンシパルの形式の変動性を考慮に入れるため、コンポーネントのアクセス決定に識別された呼び出し側の状態を適用することを選択した開発者は、同一ユーザを表す複数の識別された呼び出し側 ID がコンポーネントと関連付けられることを許容する必要があります。これは特に、アプリケーションの柔軟性や移植性が優先される場合に、推奨されます。」
WebLogic Server は、Web アプリケーションにおけるプログラムによる認可を実装するために、HttpServletRequest.isUserInRole メソッドと HttpServletRequest.getUserPrincipal
メソッドの使用、およびデプロイメント記述子での security-role-ref
要素の使用をサポートしています。
注意 : プログラムによる認可は、このマニュアルではプログラムによるセキュリティとも呼ばれます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html からオンラインで入手できます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.3 Declarative Versus Programmatic Authorization」に以下のような記述があります。
「デプロイヤによってコンフィグレーションされる外部アクセス制御ポリシーと、コンポーネント プロバイダによってアプリケーションに組み込まれた内部ポリシーとの間にはトレードオフが存在します。アプリケーションが作成された後では、外部ポリシーのほうが高い融通性を持ちます。アプリケーションが記述されている過程では、内部ポリシーのほうが融通性の高い機能を提供します。また、外部ポリシーはデプロイヤにとって透過的で完全に理解可能であるのに対し、内部ポリシーはアプリケーションに埋め込まれており、これを完全に理解できるのはアプリケーション開発者のみである可能性があります。ある特定のコンポーネントとメソッドについて認可モデルを選択する際には、これらのトレードオフを検討する必要があります。」
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html からオンラインで入手できます。
Web ブラウザは、HyperText Transfer Protocol (HTTP) ポートまたは HTTP with SSL (HTTPS) ポートを介して WebLogic Server に接続できます。HTTP ポートではなく HTTPS ポートを利用するメリットは 2 つあります。HTTPS 接続を利用するメリットは以下のとおりです。
双方向 SSL 認証を行うようにサーバがコンフィグレーションされた場合は、サーバとクライアントの両方が互いにデジタル証明書を提示して、身元を証明する必要があります。
WebLogic Server では、ユーザが Web ブラウザを使用して HTTP ポート経由でサーバに接続するときにユーザ名とパスワードの認証が行われます。その場合、ブラウザと WebLogic Server のインスタンスは次のように対話してユーザを認証します (図 2-1を参照)。
http://myserver:7001
のように HTTP と HTTP リスン ポートを指定します。注意 : WebLogic Server では独自の Web サーバを用意していますが、Apache Server、Microsoft Internet Information Server、および Netscape Enterprise Server も Web サーバとして使用できます。
Web サーバ プラグインは、HTTP プロトコルを使用して、ユーザから受け取った認証データ (ユーザ名とパスワード) と一緒に認証リクエストを WebLogic Server に送信することで認証を行います。
WebLogic Server は、Web ブラウザのユーザが HTTPS ポート経由でサーバに接続する場合に暗号化とデジタル証明書の認証を使用します。その場合、ブラウザとサーバは次のように対話してユーザを認証および認可します (図 2-1を参照)。
https://myserver:7002
のように SSL リスン ポートと HTTPS スキーマを指定します。注意 : WebLogic Server では独自の Web サーバを用意していますが、Apache Server、Microsoft Internet Information Server、および Netscape Enterprise Server も Web サーバとして使用できます。
myserver
) がデジタル証明書の名前と一致すること、そしてデジタル証明書が信頼できる第三者 (信頼性のある CA) によって発行されたものであることをチェックします。 注意 : Web サーバ プロキシ プラグインを使用して完全な双方向 SSL ハンドシェークを強制するように WebLogic Server をコンフィグレーションできなくても、必要に応じてクライアント証明書をサーバに提供するようにプロキシ プラグインをコンフィグレーションできます。そのためには、HTTP ヘッダのクライアント証明書を WebLogic Server に対してエクスポートするように、プロキシ プラグインをコンフィグレーションします。クライアント証明書を WebLogic Server にエクスポートするようにプロキシ プラグインをコンフィグレーションする手順については、『WebLogic Server における Web サーバ プラグインの使い方』でご使用のプラグインに関するコンフィグレーション情報を参照してください。
注意 : 双方向 SSL 認証を使用していれば、クライアントの証明書に基づいて ID アサーションを行うようにサーバをコンフィグレーションすることもできます。この場合、ユーザがユーザ名とパスワードを提供するのではなく、サーバはクライアントの証明書からユーザ名とパスワードを取り出します。
デフォルトでは、WebLogic Server はすべての Web アプリケーションに同じクッキー名 (JSESSIONID
) を割り当てます。同じクッキー名を使用する Web アプリケーションでは、どの種類の認証を使用する場合でも、認証用に 1 つのサインオンを使用します。ユーザが認証されると、その認証は、同じクッキー名を使用するすべての Web アプリケーションへのリクエストに対して有効になります。ユーザは再び認証を要求されることはありません。
Web アプリケーションごとに個別の認証が必要な場合は、Web アプリケーションにユニークなクッキー名またはクッキー パスを指定できます。CookieName
パラメータでクッキー名を指定し、CookiePath
パラメータでクッキー パスを指定します。これらのパラメータは、WebLogic 固有のデプロイメント記述子の weblogic.xml
の <session-descriptor>
要素で定義されます。詳細については、「WebLogic Server Web アプリケーションの開発」の「session-descriptor」を参照してください。
クッキー名を保持しつつ Web アプリケーションごとに別々の認証が必要な場合は、Web アプリケーションごとにクッキー パス パラメータ (CookiePath
) を変えることができます。
サービス パック 1 からは、セッション データを失うことなく、HTTP を使用して開始されたセッションで HTTPS リソースにユーザが安全にアクセスできるようにする新機能が追加されました。この機能を利用すると、Web サイトの設計者はセッションの盗難を防止できます。この機能の詳細については、「セキュアなクッキーを使用したセッション盗難の防止」を参照してください。
Web セキュリティの一般的な問題は、セッションの盗難です。この問題は、通常はクッキーがネットワーク経由で転送されている間に、攻撃者がセッション クッキーのコピーを取得しようとしたときに発生します。この問題は、データがクリアテキストで、つまり暗号化されずに送信されている場合にのみ発生します。
サービス パック 1 からは、セッション データを失うことなく、HTTP を使用して開始されたセッションで HTTPS リソースにユーザが安全にアクセスできるようにする新機能が追加されました。この新機能を有効にするには、config.xml
の WebServer
要素に AuthCookieEnabled="true"
を追加します。
<WebServer Name="myserver" AuthCookieEnabled="true"/>
AuthCookieEnabled
を true
(デフォルト設定) に設定すると、新しいセキュアなクッキー (_wl_authcookie_
) が、HTTPS 接続を介した認証時にブラウザに送信されるようになります。一度セキュアなクッキーが設定されると、セッションはそのクッキーがブラウザから送信された場合しかセキュリティ制約のある他の HTTPS リソースにアクセスできません。
注意 : Service Pack 5 より前のバージョンでこの機能を使うには、ブラウザでクッキーが使用されている必要があります。ブラウザでクッキーがサポートされていない場合、この機能を有効にしてもユーザが HTTPS でログインすることはできません。一方、Service Pack 5 がインストールされている場合、この機能はクッキーが無効になっていても動作します。URL 中の authCookieID を JSESSIONID と共にエンコードするために、セキュアな接続に対して URL 書き換えが行われ、セキュアな URL が書き換えられます。
このように、WebLogic Server では 2 つのクッキー (JSESSIONID
クッキーと _wl_authcookie_
クッキー) が使用されています。デフォルトでは、JSESSIONID
クッキーはセキュアではありませんが、_wl_authcookie_
クッキーは常にセキュアです。セキュアなクッキーは、暗号化された通信チャネルが使用されている場合のみ送信されます。標準の HTTPS ログインを想定した場合 (HTTPS は暗号化された HTTP 接続)、ブラウザは両方のクッキーを取得します。それ以降の HTTP アクセスでは、有効な JSESSIONID
クッキーがあれば認証済みと判断されますが、HTTPS アクセスの場合は、両方のクッキーがないと認証済みとは見なされません。JSESSIONID
クッキーしかない場合は、再び認証する必要があります。
この機能が有効な場合は、HTTPS 経由で一度ログインすると、セキュアなクッキーはネットワーク上を暗号化された状態でしか送信されません。したがって途中で盗まれることはありません。ただし JSESSIONID
クッキーは、それでも途中で盗まれる恐れがあります。したがって、Web サイトの設計者はすべての機密データで HTTPS が必須となるようにすることでセッションの盗難が起こらないようにできます。 HTTP セッション クッキーはまだ盗用に対して脆弱ですが、すべての機密を扱う処理で _wl_authcookie_
クッキー (盗まれない) が必須となっているので、それらの処理は保護されます。
WebLogic Server は、Web ブラウザに関して以下の 3 タイプの認証をサポートしています。
以下の節では、これらのタイプの認証を使用するさまざまな方法を紹介します。
BASIC 認証の場合、Web ブラウザは WebLogic リソースのリクエストに応じてログイン画面を表示します。そのログイン画面は、ユーザ名とパスワードの入力をユーザに要求します。 図 2-2 は典型的なログイン画面です。
BASIC 認証を提供する Web アプリケーションを開発するには、次の手順を実行します。
web.xml
デプロイメント記述子を作成します。このファイルには、以下の情報を含めます (コード リスト 2-1を参照)。welcome.jsp
フ ァイルを指しており、URL リソースへのアクセスが許可される HTTP メソッドは POST と GET、セキュリティ ロール名は webuser
となっています。Nmtoken
に関して定義されているとおりです (http://www.w3.org/TR/REC-xml#NT-Nmtoken)。注意 : このリリースの WebLogic Server では、<login-config> タグおよび <realm-name>
サブタグで定義されたレルム名は無視されます。
webuser
のみがセキュリティ制約で定義されているので、ここでは 1 つのセキュリティ ロール名のみ定義されています (コード リスト 2-1 の <security-role> タグを参照)。ただし、セキュリティ ロールは必要なだけ定義できます。コード リスト 2-1BASIC 認証の web.xml ファイル
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<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
デプロイメント記述子を作成します。このファイルでは、セキュリティ ロール名をユーザおよびグループにマップします。コード リスト 2-2 は、web.xml
ファイルの <security-role> タグで定義されている webuser
セキュリティ ロールを myGroup
というグループにマップするサンプル weblogic.xml
ファイルです。プリンシパルは、ユーザにもグループにもできるため、<principal-tag>
はどちらにも使用できます。このコンフィグレーションでは、WebLogic Server は myGroup のユーザだけに保護された WebLogic リソース
welcome.jsp
へアクセスすることを許可します。ただし、Administration Console を使用すると、他のグループも保護リソースへのアクセスが許可されるように Web アプリケーションのセキュリティ ロールを修正できます。注意 : weblogic.xml
デプロイメント記述子の作成は省略可能です。 このファイルを含めなかった場合、またはファイルを含めたがすべてのセキュリティ ロールのマッピングは含めなかった場合、マップされていないセキュリティ ロールはすべて、デフォルトで、ロール名に一致する名前を持つユーザまたはグループに設定されます。たとえば、セキュリティ ロールに「SampleTester」という名前を付けると、「SampleTester」という名前を持つユーザまたはグループがそのセキュリティ ロールに含まれます。
コード リスト 2-2BASIC 認証の weblogic.xml ファイル
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic 810-web-jar.dtd">
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<principal-name>myGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>
welcome.jsp
ファイルです。図 2-3 は、ウェルカム画面です。コード リスト 2-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>
注意 : コード リスト 2-3 において、JSP がログインしたユーザの名前を取得するために API (request.getRemoteUser()
) を呼び出していることに留意してください。代わりに、別の APIweblogic.security.Security.getCurrentSubject()
を使用することもできます。この API を使用してユーザの名前を取得するには、次のように SubjectUtils
API と共に使用します。
String username = weblogic.security.SubjectUtils.getUsername(
weblogic.security.Security.getCurrentSubject());
weblogic.xml
ファイル (コード リスト 2-2 ) では、<principal-name> タグで、welcome.jsp
にアクセス可能なグループとして myGroup
が定義されています。したがって、Administration Console を使用して myGroup
グループを定義し、ユーザを定義して、そのユーザを myGroup
グループに追加します。ユーザとグループの追加については、『WebLogic リソースのセキュリティ』の「ユーザとグループ」を参照してください。
http://localhost:7001/basicauth/welcome.jsp
ブラウザがユーザの資格をキャッシュし、それらをサーバに自動で再送信することはよくあります。これでは、ログアウトやタイムアウト後も WebLogic Server セッションが破棄されていないように見えます。資格が現在のブラウザ セッションに対してのみキャッシュされるか、または複数のブラウザ セッションにわたってキャッシュされるかは、ブラウザによって異なります。
javax.servlet.http.HttpSessionListener
インタフェースを実装するクラスを作成することで、WebLogic Server のセッションが破棄されたかどうかを検証できます。このインタフェースを実装することにより、Web アプリケーションのアクティブなセッションのリストに対する変更が通知されます。通知イベントを受信するには、実装クラスを web.xml
の Web アプリケーション デプロイメント記述子でコンフィグレーションする必要があります。
セッション リスナ クラスをコンフィグレーションするには、次の手順に従います。
web.xml
デプロイメント記述子をテキスト エディタで開きます。web.xml
ファイルは、Web アプリケーションの WEB-INF ディレクトリにあります。
<listener>
<listener-class>myApp.MySessionListener</listener-class>
</listener>
詳細とガイドラインについては、「イベント リスナ クラスのコンフィグレーション」を参照してください。セッション リスナ クラスを作成し、デプロイします。 コード リスト 2-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++;
// ログに書き込むなどの何らかの処理を実行する
}
public void sessionDestroyed(HttpSessionEvent se) {
if(sessionCount > 0)
sessionCount--;
// ログに書き込むなどの何らかの処理を実行する
}
}
Web アプリケーションで FORM 認証を使用する場合は、Web アプリケーション リソースのリクエストに応じて Web ブラウザが表示するカスタム ログイン画面とログインが失敗した場合に表示されるエラー画面を用意します。ログイン画面は HTML ページ、JSP、またはサーブレットを使用して生成できます。フォームベースのログインのメリットは、これらの画面を完全に管理できるので、アプリケーションやエンタープライズ ポリシー/ガイドラインの要件にあわせてそれらを設計できることです。
そのログイン画面は、ユーザ名とパスワードの入力をユーザに要求します。図 2-4 は、JSP を使用して生成される典型的なログイン画面を、コード リスト 2-5 はソース コードを示しています。
図 2-4 フォームベースのログイン画面 (login.jsp)
コード リスト 2-5フォームベースのログイン画面 (login.jsp) のソース コード
<html>
<head>)
<title>Security WebApp login page</title>
</head>
<body bgcolor="#cccccc">
<blockquote>
<img src=BEA_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>
図 2-5 は HTML を使用して生成される典型的なログイン エラー画面を、コード リスト 2-6 はソース コードを示しています。
<html>
<head>
<title>Login failed</title>
</head>
<body bgcolor=#ffffff>
<blockquote>
<img src=/security/BEA_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
デプロイメント記述子を作成します。このファイルには、以下の情報を含めます (コード リスト 2-7 を参照)。admin
サブディレクトリに配置された edit.jsp
ファイルが保護される)、URL リソースへのアクセスが許可される HTTP メソッド (GET
) が定義され、セキュリティ ロール名 admin
が定義されています。注意 : セキュリティ ロール名でハイフンは使用しないでください。ハイフンのあるセキュリティ ロール名は Administration Console で修正できません。また、BEA が推奨する命名規約では、セキュリティ ロール名は単数形です。
コード リスト 2-7FORM 認証の web.xml ファイル
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<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
デプロイメント記述子を作成します。このファイルでは、セキュリティ ロール名をユーザおよびグループにマップします。コード リスト 2-8 は、web.xm
ファイルの <security-role> タグで定義されている admin
セキュリティ ロールを supportGroup
というグループにマップするサンプル weblogic.xml
ファイルです。このコンフィグレーションの場合、WebLogic Server は supportGroup
グループのユーザのみに、保護された WebLogic リソースへのアクセスを許可します。ただし、Administration Console を使用すると、他のグループも保護された WebLogic リソースへのアクセスが許可されるように Web アプリケーションのセキュリティ ロールを修正できます。コード リスト 2-8FORM 認証の weblogic.xml ファイル
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 7.0//EN"
"http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
<weblogic-web-app>
<security-role-assignment>
<role-name>admin</role-name>
<principal-name>supportGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>
welcome.jsp
ファイルです。ウェルカム画面は、図 2-3 に示されています。コード リスト 2-9FORM 認証の 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=BEA_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>
注意 : コード リスト 2-3 において、JSP がログインしたユーザの名前を取得するために API (request.getRemoteUser()
) を呼び出していることに留意してください。代わりに、別の APIweblogic.security.Security.getCurrentSubject()
を使用することもできます。この API を使用してユーザの名前を取得するには、次のように SubjectUtils
API と共に使用します。
String username = weblogic.security.SubjectUtils.getUsername(
weblogic.security.Security.getCurrentSubject());
weblogic.xml
ファイル (コード リスト 2-8) では、<role-name> タグで admin
が edit.jsp
ファイルにアクセス可能なグループとして定義され、ユーザ joe
がそのグループのメンバーとして定義されています。 したがって、Administration Console を使用して admin
グループを定義し、ユーザ joe
を定義して、joe
を admin
グループに追加します。他のユーザを定義してグループに追加することもでき、その追加ユーザも保護された WebLogic リソースにアクセスすることができます。ユーザとグループの追加については、『WebLogic リソースのセキュリティ』の「ユーザとグループ」を参照してください。Web アプリケーションで ID アサーションを使用すると、認証を目的としてクライアントの ID を検証できます。 ID アサーションを使用するときには、以下の要件を満たす必要があります。
Web アプリケーションで双方向 SSL を使用すると、クライアントが、それがそうであると主張するクライアントであることを検証できます。双方向 SSL を使用するときには、以下の要件を満たす必要があります。
注意 : SSL 認証を使用する場合、サーバの SSL コンフィグレーションを Administration Console で指定するので、web.xml
および weblogic.xml
ファイルを使用してサーバのコンフィグレーションを指定する必要はありません。サーバでの SSL のコンフィグレーションについては、『WebLogic Security の管理』の「SSL のコンフィグレーション」を参照してください。
Web ブラウザでは、Swing コンポーネントを使用して開発されたグラフィカル ユーザ インタフェース (GUI) を操作することもできます。Java Foundation Classes (JFC) の一部である Swing コンポーネントは、JDK 1.1 または Java 2 プラットフォームで使用できます。
Swing コンポーネントを使用してアプリケーションおよびアプレットのグラフィカル ユーザ インタフェース (GUI) を作成する方法については、Sun Microsystems, Inc. 作成の「Creating a GUI with JFC/Swing」チュートリアル (Swing チュートリアルとも呼ばれる) を参照してください。このチュートリアルには、http://java.sun.com/docs/books/tutorial/uiswing/ でアクセスできます。
Swing ベースの GUI を開発したら、「FORM 認証 Web アプリケーションの開発」を参照し、Swing ベースの画面を使用して、FORM 認証を提供する Web アプリケーションの開発に必要な手順を実行します。
注意 : Swing ベースの GUI を開発する場合、swing イベント スレッドの子スレッドに Java 仮想マシン全体のユーザを使用しないでください。これは J2EE に準拠していないので、通常はシン クライアントや IIOP では動作しません。代わりに、以下のいずれかの方法を用います。
開発モードで動作しているサーバに Web アプリケーションをデプロイするには、次の手順を実行します。
注意 : 開発モードまたはプロダクション モードでの Web アプリケーションのデプロイについては、『WebLogic Server Web アプリケーションの開発』の「Web アプリケーションのデプロイメント」を参照してください。
basicauth
という Web アプリケーションのディレクトリ構造を示しています。 最上位ディレクトリには Web アプリケーションの名前を割り当て、サブディレクトリは WEB-INF
という名前にする必要があります。図 2-6 Basicauth Web アプリケーションのディレクトリ構造
applications
ディレクトリに移動します。たとえば、basicauth
Web アプリケーションは次の位置にデプロイします。WL_HOME
\user_projects\domains\mydomain\applications\basicauth
WebLogic Server インスタンスが動作している場合、アプリケーションは自動デプロイされるはずです。Administration Console を使用すると、アプリケーションがデプロイされたことを確認できます。
WebLogic Server インスタンスが動作していない場合は、サーバを起動するとアプリケーションは自動デプロイされます。
weblogic.xml
ファイルを調べます。たとえば、basicauth
サンプルの weblogic.xml
ファイル (コード リスト 2-2) では、myGroup
が welcome.jsp
ファイルにアクセスできる唯一のグループとして定義されています。開発モードまたはプロダクション モードでのセキュアな Web アプリケーションのデプロイについては、『WebLogic Server Web アプリケーションの開発』の「Web アプリケーションのデプロイメント」を参照してください。
Web アプリケーションに宣言によってセキュリティを実装するには、デプロイメント記述子 (web.xml
および weblogic.xml
) を使用してセキュリティ要件を定義します。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、サーブレット コンテナがセキュリティ定義を使って、要件を実施します。デプロイメント記述子の使い方については、「セキュアな Web アプリケーションの開発」を参照してください。
デプロイメント記述子および externally-defined
要素を使用して Web アプリケーションのセキュリティを宣言によってコンフィグレーションする方法については、「externally-defined」を参照してください。
Administration Console を使用して Web アプリケーションのセキュリティをコンフィグレーションする方法については、『WebLogic リソースのセキュリティ』を参照してください。
以下のトピックでは、Web アプリケーションのセキュリティ要件を定義するために web.xml
および weblogic.xml
ファイルで使用されるデプロイメント記述子の要素について説明します。
以下の web.xml
のセキュリティ関連のデプロイメント記述子の要素が、WebLogic Server でサポートされています。
この節の情報は、Sun Microsystems, Inc. 提供の web.xml
の文書型記述子 (DTD) に基づいています。web.xml
の DTD は、http://java.sun.com/dtd/web-app_2_3.dtd にあります。
省略可能な auth-constraint
要素では、このセキュリティ制約で定義された Web リソースの集合にアクセスするグループまたはプリンシパルを定義します。
次の表では、auth-constraint
要素内で定義できる要素について説明します。
|
auth-constraint
要素は、security-constraint
要素内で使用されます。
web.xml
ファイルで、auth-constraint
要素を使用する例については、コード リスト 2-10 を参照してください。
security-constraint
要素は、web-resource-collection
要素で定義されたリソースの集合へのアクセス特権を定義するために web.xml ファイルで使用されます。
次の表では、security-constraint 要素内で定義できる要素について説明します。
|
||
|
||
|
コード リスト 2-10 は、security-constraint
要素を使用して、web.xml
で SecureOrdersEast のセキュリティを定義する方法を示しています。
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
要素内で定義できる要素について説明します。
|
web.xml
ファイルで、security-role
要素を使用する例については、コード リスト 2-13 を参照してください。
security-role-ref
要素は、<security-role>
で定義されたセキュリティ ロール名を、サーブレットのロジックでハード コード化される代替ロール名にリンクします。この特別な抽象化レイヤによって、サーブレット コードを変更しなくてもデプロイメント時にサーブレットをコンフィグレーションできるようになります。
次の表では、security-role-ref
要素内で定義できる要素について説明します。
web.xml
ファイルで、security-role-ref
要素を使用する例については、コード リスト 2-16 を参照してください。
user-data-constraint
要素は、クライアントとサーバ間でやり取りされるデータの保護方法を定義します。
次の表では、user-data-constraint
要素内で定義できる要素について説明します。
user-data-constraint
要素は、security-constraint
要素内で使用されます。
web.xml
ファイルで、user-data-constraint
要素を使用する例については、コード リスト 2-10 を参照してください。
web-resource-collection
要素は、セキュリティ制約を適用する Web アプリケーションのリソースおよび HTTP
メソッドのサブセットを識別するために使用されます。HTTP
メソッドが指定されていない場合、セキュリティ制約はすべての HTTP
メソッドに適用される。
次の表では、web-resource-collection
要素内で定義できる要素について説明します。
|
web-resource-collection
要素は、security-constraint
要素内で使用されます。
web.xml
ファイルで、web-resource-collection
要素を使用する例については、コード リスト 2-10 を参照してください。
以下の weblogic.xml
のセキュリティ関連のデプロイメント記述子の要素が、WebLogic Server でサポートされています。
weblogic.xml
デプロイメント記述子の詳細については、http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd にある weblogic.xml
の文書型記述子 (DTD) を参照してください。
WebLogic Server 8.1 以降では、externally-defined
要素の weblogic.xml
デプロイメント記述子での使用がサポートされています。 <principal-name>
タグの代わりにこの要素を使用すると、web.xml
デプロイメント記述子の role-name
要素によって定義されたセキュリティ ロールが Administration Console で指定したマッピングを使用するよう指定できます。
注意 : externally-defined
要素は、WebLogic Server 7.0 SP1 で使用されていた global-role
要素に代わるものです。externally-defined
要素の機能は、global-role
要素と同じです。global-role
要素は WebLogic Server 8.1 では非推奨となりました。
externally-defined
要素を使用すると、特定の Web アプリケーションのデプロイメント記述子に定義されたセキュリティ ロールごとに特定のセキュリティ ロール マッピングを指定する必要がなくなります。代わりに、Administration Console を使用して定義済みの各ロールに対する特定のロール マッピングをいつでも指定および変更できます。さらに、この要素は一部のアプリケーションのみに対して使用できるので、セキュリティ レルムの [デプロイメント記述子のロールとポリシーを無視] オプションを選択する必要がありません。このオプションは、Administration Console の [セキュリティ|レルム|myrealm] コントロール パネルの [全般] タブにある [今後の再デプロイの設定] フィールドで選択します。 このため、同じセキュリティ レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、Administration Console を使用して他のアプリケーションのセキュリティを指定および変更できます。
注意 : セキュリティ ロール名を指定する場合には、以下の規約と制限に従ってください。
Nmtoken
に関して定義されているとおりです (http://www.w3.org/TR/REC-xml#NT-Nmtoken)。externally-defined
要素は、security-role-assignment
要素内で使用されます。
コード リスト 2-11 とコード リスト 2-12 は、weblogic.xml
で externally-defined
要素を使用する方法を比較して示しています。コード リスト 2-12 で、weblogic.xml
内の「webuser」の externally-defined
要素は、セキュリティが getReceipts
メソッドにおいて正しくコンフィグレーションされるには Administration Console で webuser
に対応するプリンシパルが作成される必要がある、ということを意味します。
コード リスト 2-11web.xml ファイルと weblogic.xml ファイルを使用したセキュリティ ロールとプリンシパルのセキュリティ レルムへのマッピング
web.xml のエントリ :
<web-app>
...
<security-role>
<role-name>webuser</role-name>
</security-role>
...
</web-app>
weblogic.xml のエントリ :
<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>
コード リスト 2-12 Web アプリケーションのデプロイメント記述子での externally-defined タグの使用
web.xml のエントリ :
<web-app>
...
<security-role>
<role-name>webuser</role-name>
</security-role>
...
</web-app>
weblogic.xml のエントリ :
<weblogic-web-app>
<security-role-assignment>
<role-name>webuser</role-name>
<externally-defined/>
</security-role-assignment>
Administration Console を使用して Web アプリケーションのセキュリティをコンフィグレーションする方法については、『WebLogic リソースのセキュリティ』を参照してください。
run-as-principal-name
要素では、対応する web.xml
ファイルの run-as
要素で定義されるセキュリティ ロールに使用するプリンシパル名を指定します。
run-as-principal-name
要素は、run-as-role-assignment
要素内で使用されます。
run-as-principal-name
要素を使用する例については、 コード リスト 2-13 を参照してください。
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
要素内で定義できる要素について説明します。
コード リスト 2-13 は、run-as-role-assignment
要素を使用して、SnoopServlet
を常にユーザ joe
として実行させる方法を示しています。
コード リスト 2-13run-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
要素は、J2EE Sandbox と関連するセキュリティ パーミッションを指定します。
security-permission
要素を使用する例については、 コード リスト 2-14 を参照してください。
security-permission-spec 要素は、セキュリティ ポリシー ファイル構文に基づいて単一のセキュリティ パーミッションを指定します。Sun のセキュリティ パーミッション仕様の実装については、次の URL を参照してください。
http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax
注意 : オプションの codebase および signedBy 句は無視してください。
security-permission-spec
要素は、security-permission
要素内で使用されます。
コード リスト 2-14 は、security-permission-spec 要素を使用して、java.net.SocketPermission
クラスにパーミッションを付与する方法を示しています。
コード リスト 2-14security-permission-spec 要素の例
<weblogic-web-app>
<security-permission>
<description>Optional explanation goes here</description>
<security-permission-spec>
<!--http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax
の構文にしたがって、単一の grant 文をここに記述する。このとき、「codebase」および「signedBy」句は使用しない。次に例を示す-->
grant {
permission java.net.SocketPermission "*", "resolve";
};
</security-permission-spec>
</security-permission>
</weblogic-web-app>
コード リスト 2-14 では、permission java.net.SocketPermission はパーミッション クラス名を、"*" は対象名を、resolve (host/IP 名サービスのルックアップを解決する) はアクションを示します。
security-role-assignment
要素は、セキュリティ ロールと WebLogic Server セキュリティ レルムの 1 つまたは複数のプリンシパルとのマッピングを宣言します。
コード リスト 2-15は、security-role-assignment
要素を使用してプリンシパルを PayrollAdmin
ロールに割り当てる方法を示しています。
コード リスト 2-15security-role-assignment 要素の例
<weblogic-web-app>
<security-role-assignment><role-name>
PayrollAdmin</role-name>
<principal-name>
Tanya</principal-name>
<principal-name>
Fred</principal-name>
<principal-name>
system</principal-name>
</security-role-assignment>
</weblogic-web-app>
サーブレットを記述して、そのサーブレット コードでプログラム的にユーザとセキュリティ ロールにアクセスできます。そのためには、サーブレットのコードで 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://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security5.html#80556 を参照してください。
javax.servlet.http.HttpServletRequest.isUserInRole(String role)
メソッドは、認証されたユーザが指定された論理セキュリティ「ロール」を付与されているかどうかを示すブール値を返します。 ユーザが認証されていない場合、このメソッドは false を返します。
isUserInRole()
メソッドは、セキュリティ ロールをセキュリティ レルムのグループ名にマップします。コード リスト 2-16 は、web.xml
でセキュリティ ロールを定義するために<servlet>
要素と一緒に使用される要素を示しています。
コード リスト 2-16isUserInRole の web.xml および weblogic.xml の要素
web.xml のエントリ :
...
<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>
...
weblogic.xml のエントリ :
...
<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>
に対応します。
注意 : セキュリティ ロール名を指定する場合には、以下の規約と制限に従ってください。
Nmtoken
に関して定義されているとおりです (http://www.w3.org/TR/REC-xml#NT-Nmtoken)。たとえば、クライアントが manager
というセキュリティ ロールの Bill
というユーザでログインに成功している場合、次のメソッドは true を返します。
request.isUserInRole("manager
")
コード リスト 2-17 は例を示しています。
コード リスト 2-17セキュリティ ロール マッピングの例
サーブレット コード :
out.println("Is the user a Manager? " +
request.isUserInRole("manager"));
web.xml
のエントリ
:
<servlet>
. . .
<role-name>manager
</role-name>
<role-link>mgr
</role-link>
. . .
</servlet>
<security-role>
<role-name>mgr
</role-name>
</security-role>
weblogic.xml
のエントリ
:
<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 を使用すると、ユーザを認証し、そのユーザをログインさせ、デフォルトのレルム (アクティブなレルム) で登録されるように現行セッションと関連付けるサーブレット コードを記述できます。いったんログインが完了すると、標準のメカニズムを使用してログインしたかのように感じられます。
ServletAuthentication
API と一緒に WebLogic が提供する weblogic.security.SimpleCallbackHandler
クラスまたは weblogic.security.URLCallbackHandler
クラスのうちいずれかを使用できます。これらのクラスの詳細については、WebLogic クラスの Javadoc を参照してください。
コード リスト 2-18 は、SimpleCallbackHandler
を使用する例を示します。コード リスト 2-19 は、URLCallbackHandler
を使用する例を示しています。
コード リスト 2-18SimpleCallbackHandler クラスを使用したプログラムによる認証コードの一部
CallbackHandler handler = new SimpleCallbackHandler(username, password);
Subject mySubject = weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
request
は、httpservletrequest
オブジェクトです。
コード リスト 2-19URLCallbackHandler クラスを使用したプログラムによる認証コードの一部
CallbackHandler handler = new URLCallbackHandler(username, password);
Subject mySubject = weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
![]() ![]() |
![]() |
![]() |