| Oracle® Fusion Middleware Oracle WebLogic Server Security プログラマーズ ガイド 11g リリース 1 (10.3.1) B55520-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server Security プログラマーズ ガイド 11g リリース 1 (10.3.1) B55520-01 |
|
戻る |
次へ |
WebLogic Server は、Web アプリケーションを保護する Java EE アーキテクチャ セキュリティ モデルをサポートしています。これには、宣言による認可 (このマニュアルでは宣言によるセキュリティとも呼ぶ) とプログラムによる認可 (このマニュアルではプログラムによるセキュリティとも呼ぶ) のサポートが含まれます。
この節では、以下のトピックを取り上げます。
|
注意 : Web アプリケーションの保護には、デプロイメント記述子ファイルと Administration Console を使用できます。このマニュアルでは、デプロイメント記述子ファイルを使用する方法について説明します。Administration Console を使用しての Web アプリケーションの保護については、『Oracle Fusion Middleware 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 アプリケーション プログラミング インタフェース (ISAPI)
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、および Netscape Enterprise Server も Web サーバとして使用できます。 |
Web サーバは、要求された WebLogic リソースがセキュリティ ポリシーによって保護されているかどうかチェックします。WebLogic リソースが保護されている場合、Web サーバは確立されている HTTPS 接続を使用して、ユーザのユーザ名とパスワードを要求します。
ユーザの Web ブラウザが WebLogic Server からのリクエストを受け取ると、ユーザに対してユーザ名とパスワードを要求します。この手順は省略可能です。
Web ブラウザは、ユーザ名とパスワードと一緒にリクエストを再送信します (サーバから要求された場合のみ)。
WebLogic Server は、Web ブラウザにデジタル証明書を提示します。
Web ブラウザは、URL で使用されているサーバの名前 (たとえば myserver) がデジタル証明書の名前と一致すること、そしてデジタル証明書が信頼できる第三者 (信頼性のある CA) によって発行されたものであることをチェックします。
双方向 SSL 認証を使用するよう設定されている場合、サーバはクライアントのデジタル証明書を要求します。
|
注意 : Web サーバ プロキシ プラグインを使用して完全な双方向 SSL ハンドシェークを強制するように WebLogic Server をコンフィグレーションできなくても、必要に応じてクライアント証明書をサーバに提供するようにプロキシ プラグインをコンフィグレーションできます。そのためには、HTTP ヘッダのクライアント証明書を WebLogic Server に対してエクスポートするように、プロキシ プラグインをコンフィグレーションします。クライアント証明書を WebLogic Server にエクスポートするようにプロキシ プラグインをコンフィグレーションする手順については、「Web サーバ プラグインの使用」でご使用のプラグインに関するコンフィグレーション情報を参照してください。 |
Web サーバはリクエストを Web サーバ プラグインに転送します。セキュアなプロキシが設定されていれば (HTTPS プロトコルが使用されている場合には設定されている)、Web サーバ プラグインはまた、HTTPS プロトコルを介して、ユーザから受け取った認証データ (ユーザ名とパスワード) と一緒にリクエストを WebLogic Server の WebLogic リソースに送信することによって認証を実行します。
|
注意 : 双方向 SSL 認証を使用していれば、クライアントの証明書に基づいて ID アサーションを行うようにサーバをコンフィグレーションすることもできます。この場合、ユーザがユーザ名とパスワードを提供するのではなく、サーバはクライアントの証明書からユーザ名とパスワードを取り出します。 |
認証に成功すると、WebLogic Server は、ユーザがその WebLogic リソースへのアクセスに必要なパーミッションを持っているかどうかを調べます。
WebLogic リソースに対してメソッドを呼び出す前に、サーバはセキュリティ認可チェックを実行します。サーバは、このチェックで、ユーザの資格をセキュリティ コンテキストから取り出し、ユーザのセキュリティ ロールを特定して、そのユーザのセキュリティ ロールを、要求された WebLogic リソースのセキュリティ ポリシーと照らし合わせ、ユーザが WebLogic リソースに対してメソッドを呼び出す認可を持っていることを確認します。
認可が成功すると、サーバがリクエストを遂行します。
詳細については、以下のマニュアルを参照してください。
デフォルトでは、WebLogic Server はすべての Web アプリケーションに同じクッキー名 (JSESSIONID) を割り当てます。同じクッキー名を使用する Web アプリケーションでは、どの種類の認証を使用する場合でも、認証用に 1 つのサインオンを使用します。ユーザが認証されると、その認証は、同じクッキー名を使用するすべての Web アプリケーションへのリクエストに対して有効になります。ユーザは再び認証を要求されることはありません。
Web アプリケーションごとに個別の認証が必要な場合は、Web アプリケーションにユニークなクッキー名またはクッキー パスを指定できます。CookieName パラメータでクッキー名を指定し、CookiePath パラメータでクッキー パスを指定します。これらのパラメータは、WebLogic 固有のデプロイメント記述子の weblogic.xml の <session-descriptor> 要素で定義されます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバの起動と停止』の「session-descriptor」を参照してください。
クッキー名を保持しつつ Web アプリケーションごとに別々の認証が必要な場合は、Web アプリケーションごとにクッキー パス パラメータ (CookiePath) を変えることができます。
WebLogic Server では、セッション データを失うことなく、HTTP を使用して開始されたセッションで HTTPS リソースにユーザが安全にアクセスできます。この機能を利用すると、Web サイトの設計者はセッションの盗難を防止できます。この機能の詳細については、「セキュアなクッキーを使用したセッション盗難の防止」を参照してください。
Web セキュリティの一般的な問題は、セッションの盗難です。この問題は、通常はクッキーがネットワーク経由で転送されている間に、攻撃者がセッション クッキーのコピーを取得しようとしたときに発生します。この問題は、データがクリアテキストで (つまり、クッキーが暗号化されずに) 送信されている場合にのみ発生します。
WebLogic Server では、セッション データを失うことなく、HTTP を使用して開始されたセッションで HTTPS リソースにユーザが安全にアクセスできます。この機能を有効にするには、config.xml の WebServer 要素に AuthCookieEnabled="true" を追加します。
<WebServer Name="myserver" AuthCookieEnabled="true"/>
AuthCookieEnabled を true (デフォルト設定) に設定すると、新しいセキュアなクッキー (_WL_AUTHCOOKIE_JSESSIONID) が、HTTPS 接続を介した認証時にブラウザに送信されるようになります。一度セキュアなクッキーが設定されると、セッションはそのクッキーがブラウザから送信された場合しかセキュリティ制約のある他の HTTPS リソースにアクセスできません。
このように、WebLogic Server では 2 つのクッキー (JSESSIONID クッキーと _WL_AUTHCOOKIE_JSESSIONID クッキー) が使用されています。デフォルトでは、JSESSIONID クッキーはセキュアではありませんが、_WL_AUTHCOOKIE_JSESSIONID クッキーは常にセキュアです。セキュアなクッキーは、暗号化された通信チャネルが使用されている場合のみ送信されます。標準の HTTPS ログインを想定した場合 (HTTPS は暗号化された HTTP 接続)、ブラウザは両方のクッキーを取得します。
それ以降の HTTP アクセスでは、有効な JSESSIONID クッキーがあれば認証済みと判断されますが、HTTPS アクセスの場合は、両方のクッキーがないと認証済みとは見なされません。JSESSIONID クッキーしかない場合は、再び認証する必要があります。
この機能が有効な場合は、HTTPS 経由で一度ログインすると、セキュアなクッキーはネットワーク上を暗号化された状態でしか送信されません。したがって途中で盗まれることはありません。ただし JSESSIONID クッキーは、それでも途中で盗まれる恐れがあります。したがって、Web サイトの設計者はすべての機密データで HTTPS が必須となるようにすることでセッションの盗難が起こらないようにできます。HTTP セッション クッキーはまだ盗用に対して脆弱ですが、すべての機密を扱う処理で _WL_AUTHCOOKIE_JSESSIONID (盗まれない) が必須となっているので、それらの処理は保護されます。
weblogic.xml デプロイメント記述子の <session-descriptor> 要素で定義する CookieName パラメータを使用して、JSESSIONID または _WL_AUTHCOOKIE_JSESSIONID のクッキー名を指定することもできます。次に例を示します。
<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 Fusion Middleware 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 が定義されています。したがって、Administration Console を使用して myGroup グループを定義し、ユーザを定義して、そのユーザを myGroup グループに追加します。ユーザとグループの追加については、『Oracle Fusion Middleware 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 Fusion Middleware 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 フラグの設定は、Administration Console には表示されません。また、Administration Console のログにも記録されません。しかし、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-5 は、HTML を使用して生成される典型的なログイン エラー画面を、コード リスト 3-7 はソース コードを示しています。
コード リスト 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 が定義されています。
|
注意 : セキュリティ ロール名でハイフンは使用しないでください。ハイフンのあるセキュリティ ロール名は Administration Console で修正できません。また、推奨される命名規約では、セキュリティ ロール名は単数形です。 |
使用する認証のタイプとセキュリティ制約が適用されるセキュリティ レルムを定義します。この場合は、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 リソースへのアクセスを許可します。ただし、Administration Console を使用すると、他のグループも保護された 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 がそのグループのメンバーとして定義されています。したがって、Administration Console を使用して admin グループを定義し、ユーザ joe を定義して、joe をadmin グループに追加します。他のユーザを定義してグループに追加することもでき、その追加ユーザも保護された WebLogic リソースにアクセスすることができます。ユーザとグループの追加については、『Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Server のセキュリティ』の「ID アサーション プロバイダのコンフィグレーション」を参照してください。
トークンの値に対応するユーザは、サーバのセキュリティ レルムで定義されていなければなりません。定義されていない場合、クライアントは保護されている WebLogic リソースにアクセスできません。サーバでのユーザのコンフィグレーションについては、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。
Web アプリケーションで双方向 SSL を使用すると、クライアントが、それがそうであると主張するクライアントであることを検証できます。双方向 SSL を使用するときには、以下の要件を満たす必要があります。
認証のタイプは CLIENT-CERT に設定する必要があります。
サーバは、双方向 SSL に合わせてコンフィグレーションする必要があります。SSL とデジタル証明書の使用については、「Java クライアントでの SSL 認証の使用」を参照してください。サーバでの SSL のコンフィグレーションについては、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「SSL のコンフィグレーション」を参照してください。
クライアントは、サーバの Web アプリケーションにアクセスするために HTTPS を使用する必要があります。
サーバに ID アサーション プロバイダがコンフィグレーションされている必要があります。Web ブラウザまたは Java クライアントがセキュリティ ポリシーで保護された WebLogic Server リソースを要求する場合、WebLogic Server は Web ブラウザまたは Java クライアントが ID を持つことを要求します。WebLogic ID アサーション プロバイダを使用すると、Web ブラウザまたは Java クライアントのデジタル証明書を WebLogic Server セキュリティ レルム内のユーザにマップするユーザ名マッパーをサーバで使用できます。セキュリティ プロバイダをコンフィグレーションする方法については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「WebLogic セキュリティ プロバイダのコンフィグレーション」を参照してください。
クライアントのデジタル証明書の Subject's Distinguished Name (SubjectDN) 属性に対応するユーザは、サーバのセキュリティ レルムで定義されている必要があります。定義されていないと、クライアントには保護された WebLogic リソースへのアクセスが許可されません。サーバでのユーザのコンフィグレーションについては、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。
|
注意 : SSL 認証を使用する場合、サーバの SSL コンフィグレーションを Administration Console で指定するので、web.xml および weblogic.xml ファイルを使用してサーバのコンフィグレーションを指定する必要はありません。 |
Servlet 2.4 仕様 (http://java.sun.com/products/servlet/download.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 Fusion Middleware Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』の「WebLogic Server サブシステム MBean の概要」を参照してください。
Web ブラウザでは、JFC (Java Foundation Classes) の Swing コンポーネントを使用して開発されたグラフィカル ユーザ インタフェース (GUI) を操作することもできます。
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 仮想マシン全体のユーザを使用しないでください。これは Java EE に準拠していないので、通常はシン クライアントや IIOP では動作しません。代わりに、以下のいずれかの方法を用います。
|
開発モードで動作しているサーバに Web アプリケーションをデプロイするには、次の手順を実行します。
|
注意 : 開発モードまたはプロダクション モードでの Web アプリケーションのデプロイについては、『Oracle Fusion Middleware 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 インスタンスが動作している場合、アプリケーションは自動デプロイされるはずです。Administration Console を使用すると、アプリケーションがデプロイされたことを確認できます。
WebLogic Server インスタンスが動作していない場合は、サーバを起動するとアプリケーションは自動デプロイされます。
まだしていない場合は、Administration Console を使用して、Web アプリケーションにアクセスできるユーザおよびグループをコンフィグレーションします。保護された WebLogic リソースへのアクセスを許可されるユーザおよびグループを判別するには、weblogic.xml ファイルを調べます。たとえば、basicauth サンプルの weblogic.xml ファイル (コード リスト 3-2) では、myGroup が welcome.jsp ファイルにアクセスできる唯一のグループとして定義されています。
セキュアな Web アプリケーションのデプロイについては、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント』の「weblogic.deployer によるアプリケーションおよびモジュールのデプロイ」を参照してください。
宣言によるセキュリティは、以下の 3 つの方法で実装できます。
Administration Console でセキュリティ プロバイダを使用する。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照してください。
JACC (Java Authorization Contract for Containers) を使用する。詳細については、「Java Authorization Contract for Containers の使用」を参照してください。
デプロイメント記述子を使用する。この節では、この方法について説明します。
これら 3 つのうちどの方法を使用するかは、JACC フラグとセキュリティ モデルによって定義されます （セキュリティ モデルについては、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「Web アプリケーションおよび EJB リソースの保護のオプション」を参照）。
Web アプリケーションに宣言によってセキュリティを実装するには、デプロイメント記述子 (web.xml および weblogic.xml) を使用してセキュリティ要件を定義します。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、サーブレット コンテナがセキュリティ定義を使って、要件を実施します。デプロイメント記述子の使い方については、「セキュアな Web アプリケーションの開発」を参照してください。
デプロイメント記述子および externally-defined 要素を使用して Web アプリケーションのセキュリティを宣言によってコンフィグレーションする方法については、「externally-defined」を参照してください。
Administration Console を使用して Web アプリケーションのセキュリティをコンフィグレーションする方法については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照してください。
以下のトピックでは、Web アプリケーションのセキュリティ要件を定義するために web.xml および weblogic.xml ファイルで使用されるデプロイメント記述子の要素について説明します。
以下の web.xml のセキュリティ関連のデプロイメント記述子の要素が、WebLogic Server でサポートされています。
省略可能な auth-constraint 要素では、このセキュリティ制約で定義された Web リソースの集合にアクセスするグループまたはプリンシパルを定義します。
次の表では、auth-constraint 要素内で定義できる要素について説明します。
表 3-2 auth-constraint 要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
このセキュリティ制約の説明文。 |
<role-name> |
省略可能 |
この |
security-constraint 要素は、web-resource-collection 要素で定義されたリソースの集合へのアクセス特権を定義するために web.xml ファイルで使用されます。
次の表では、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-ref 要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<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 要素は、クライアントとサーバ間でやり取りされるデータの保護方法を定義します。
次の表では、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 Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「XML デプロイメント記述子」を参照してください。
weblogic.xml 要素の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server の Web アプリケーション、サーブレット、JSP のデプロイ』の「weblogic.xml デプロイメント記述子の要素」を参照してください。
externally-defined 要素を使用すると、web.xml デプロイメント記述子の role-name 要素によって定義されたセキュリティ ロールが Administration Console で指定したマッピングを使用するよう指定できます。この要素を使用することで、特定の Web アプリケーションのデプロイメント記述子に定義されたセキュリティ ロールごとに特定のセキュリティ ロール マッピングを指定する必要がなくなります。このため、同じセキュリティ レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、Administration Console を使用して他のアプリケーションのセキュリティを指定および変更できます。
サーバのロール マッピングの動作は、Administration Console でどのセキュリティ デプロイメント モデルを選択したかによって異なります。セキュリティ デプロイメント モデルの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「Web アプリケーションおよび EJB リソースの保護のオプション」を参照してください。
|
注意 : セキュリティ ロール名を指定する場合には、以下の規約と制限に従ってください。
|
コード リスト 3-12 とコード リスト 3-13 は、weblogic.xml ファイルで externally-defined 要素を使用する方法を比較して示しています。コード リスト 3-13 で、weblogic.xml 内の「webuser」の externally-defined 要素は、セキュリティが getReceipts メソッドにおいて正しくコンフィグレーションされるには Administration Console で 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>
Administration Console を使用して Web アプリケーションのセキュリティをコンフィグレーションする方法については、『Oracle Fusion Middleware 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://java.sun.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>
<!--
http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax の構文にしたがって、単一の grant 文をここに記述する。
このとき、「codebase」および「signedBy」句は使用しない。次に例を示す
-->
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 Fusion Middleware 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://java.sun.com/javaee/technologies/javaee5.jsp を参照してください。
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 セキュリティ ロール マッピングの例
サーブレット コード :
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 を使用すると、ユーザを認証し、そのユーザをログインさせ、デフォルトのセキュリティ レルム (アクティブなセキュリティ レルム) で登録されるように現行セッションと関連付けるサーブレット コードを記述できます。いったんログインが完了すると、標準のメカニズムを使用してログインしたかのように感じられます。
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); // request は httpservletrequest オブジェクト
コード リスト 3-20 URLCallbackHandler クラスを使用したプログラムによる認証コードの一部
CallbackHandler handler = new URLCallbackHandler(username, password); Subject mySubject = weblogic.security.services.Authentication.login(handler); weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request); // request は httpservletrequest オブジェクト
