![]() ![]() ![]() ![]() |
WebLogic Server は、Web アプリケーションを保護する Java EE アーキテクチャ セキュリティ モデルをサポートしています。これには、宣言による認可 (このマニュアルでは宣言によるセキュリティとも呼ぶ) とプログラムによる認可 (このマニュアルではプログラムによるセキュリティとも呼ぶ) のサポートが含まれます。
注意 : | Web アプリケーションの保護には、デプロイメント記述子ファイルと Administration Console を使用できます。このマニュアルでは、デプロイメント記述子ファイルを使用する方法について説明します。Administration Console を使用しての Web アプリケーションの保護については、『ロールおよびポリシーによる WebLogic リソースの保護』を参照してください。 |
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 接続を利用するメリットは以下のとおりです。
双方向 SSL 認証を行うようにサーバがコンフィグレーションされた場合は、サーバとクライアントの両方が互いにデジタル証明書を提示して、身元を証明する必要があります。
WebLogic Server では、ユーザが Web ブラウザを使用して HTTP ポート経由でサーバに接続するときにユーザ名とパスワードの認証が行われます。その場合、ブラウザと WebLogic Server のインスタンスは次のように対話してユーザを認証します (図 3-1 を参照)。
http
URL では、たとえば http://myserver:7001
のように HTTP リスン ポートを指定します。注意 : | WebLogic Server では独自の Web サーバを用意していますが、Apache Server、Microsoft Internet Information Server、および Netscape Enterprise Server も Web サーバとして使用できます。 |
WebLogic Server は、Web ブラウザのユーザが HTTPS ポート経由でサーバに接続する場合に暗号化とデジタル証明書の認証を使用します。その場合、ブラウザとサーバは次のように対話してユーザを認証および認可します (図 3-1 を参照)。
https
URL では、たとえば https://myserver:7002
のように SSL リスン ポートを指定します。注意 : | WebLogic Server では独自の Web サーバを用意していますが、Apache Server、Microsoft Internet Information Server、および Netscape Enterprise Server も Web サーバとして使用できます。 |
myserver
) がデジタル証明書の名前と一致すること、そしてデジタル証明書が信頼できる第三者 (信頼性のある CA) によって発行されたものであることをチェックします。 注意 : | Web サーバ プロキシ プラグインを使用して完全な双方向 SSL ハンドシェークを強制するように WebLogic Server をコンフィグレーションできなくても、必要に応じてクライアント証明書をサーバに提供するようにプロキシ プラグインをコンフィグレーションできます。そのためには、HTTP ヘッダのクライアント証明書を 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 アプリケーション、サーブレット、JSP の開発』の「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 では、URL 中の authCookieID を JSESSIONID と共にエンコードするために、セキュアな接続での URL 書き換えを使用してセキュアな URL を書き換えるためです。 |
このように、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 認証の場合、Web ブラウザは WebLogic リソースのリクエストに応じてログイン画面を表示します。そのログイン画面は、ユーザ名とパスワードの入力をユーザに要求します。図 3-2 は典型的なログイン画面です。
注意 : | 非セキュアなリソースの処理に関する重要な情報については、「リソースが非セキュアな場合の BASIC 認証について」を参照してください。 |
BASIC 認証を提供する Web アプリケーションを開発するには、次の手順を実行します。
web.xml
デプロイメント記述子を作成します。このファイルには、以下の情報を含めます (コード リスト 3-1 を参照)。welcome.jsp
です。welcome.jsp
ファイルを指しており、URL リソースへのアクセスが許可される HTTP メソッドは POST と GET、セキュリティ ロール名は webuser
となっています。注意 : | セキュリティ ロール名を指定する場合には、以下の規約と制限に従ってください。 |
Nmtoken
に関して定義されているとおりです (http://www.w3.org/TR/REC-xml#NT-Nmtoken)。webuser
のみがセキュリティ制約で定義されているので、ここでは 1 つのセキュリティ ロール名のみ定義されています (コード リスト 3-1 の <security-role> タグを参照)。ただし、セキュリティ ロールは必要なだけ定義できます。<?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 は、web.xml
ファイルの <security-role> タグで定義されている webuser
セキュリティ ロールを myGroup
というグループにマップするサンプル weblogic.xml
ファイルです。プリンシパルは、ユーザにもグループにもできるため、<principal-tag>
はどちらにも使用できます。このコンフィグレーションの場合、WebLogic Server は myGroup
グループのユーザのみに、保護された URL リソース welcome.jsp
へのアクセスを許可します。注意 : | バージョン 9.0 からは、ロール マッピングのデフォルト動作によって、weblogic.xml に何も指定されていないと空のロール マッピングが作成されるようになりました。バージョン 8.x では、weblogic.xml ファイルを含めなかった場合や、ファイルを含めたがすべてのセキュリティ ロールのマッピングは含めなかった場合、マップされていないセキュリティ ロールはすべて、デフォルトで、ロール名に一致する名前を持つユーザまたはグループに設定されていました。ロール マッピングの動作および下位互換性の設定については、『ロールおよびポリシーによる WebLogic リソースの保護』の「[ロール マッピングの組み合わせを有効化] 設定について」を参照してください。 |
<?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>
welcome.jsp
ファイルです。図 3-3 は、ウェルカム画面です。<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.xml
ファイル (コード リスト 3-2) では、<principal-name> タグで、welcome.jsp
にアクセス可能なグループとして myGroup
が定義されています。したがって、Administration Console を使用して myGroup
グループを定義し、ユーザを定義して、そのユーザを myGroup
グループに追加します。ユーザとグループの追加については、『ロールおよびポリシーによる WebLogic リソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。
http://localhost:7001/basicauth/welcome.jsp
ブラウザはユーザの資格をキャッシュし、それらをサーバに対して高い頻度で自動的に再送信します。これによって、ログアウトまたはタイムアウト後も WebLogic Server セッションが破棄されていないように見えます。資格は、ブラウザに応じて、現在のブラウザ セッションでのみキャッシュしたり、複数のセッションにまたがってキャッシュすることができます。
WebLogic Server のセッションが破棄されたことを確認するには、javax.servlet.http.HttpSessionListener
インタフェースを実装するクラスを作成します。このインタフェースを実装すると、Web アプリケーションにおけるアクティブ セッションのリストへの変更が通知されます。通知イベントを取得するには、対象 Web アプリケーションについて、web.xml
のデプロイメント記述子で実装クラスをコンフィグレーションする必要があります。
セッション リスナ クラスをコンフィグレーションするには、次の手順に従います。
web.xml
デプロイメント記述子をテキスト エディタで開きます。web.xml
ファイルは、Web アプリケーションの WEB-INF ディレクトリにあります。
<listener>
<listener-class>myApp.MySessionListener</listener-class>
</listener>
詳細およびガイドラインについては、「イベント リスナ クラスのコンフィグレーション」を参照してください。
セッション リスナ クラスを作成し、デプロイします。コード リスト 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++;
// ログに記録する、またはその他の処理を行う
}
public void sessionDestroyed(HttpSessionEvent se) {
if(sessionCount > 0)
sessionCount--;
// ログに記録する、またはその他の処理を行う
}
}
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
フラグを設定するには、次の手順に従います。
enforce-valid-basic-auth-credentials
フラグの設定は、Administration Console には表示されません。また、Administration Console のログにも記録されません。しかし、WLST を使用すると、実行中のサーバでの値を確認できます。なお、enforce-valid-basic-auth-credentials
がドメイン全体の設定である点には注意してください。
コード リスト 3-5 に、実行中のサンプル サーバで enforce-valid-basic-auth-credentials
の値を確認するための WLST セッションを示します。
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 はソース コードを示しています。
<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>
図 3-5 は HTML を使用して生成される典型的なログイン エラー画面を、コード リスト 3-7 はソース コードを示しています。
<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
デプロイメント記述子を作成します。このファイルには、以下の情報を含めます (コード リスト 3-8 を参照)。welcome.jsp
です。admin
サブディレクトリに配置された edit.jsp
ファイルが保護される)、URL リソースへのアクセスが許可される HTTP メソッド (GET
) が定義され、セキュリティ ロール名 admin
が定義されています。注意 : | セキュリティ ロール名でハイフンは使用しないでください。ハイフンのあるセキュリティ ロール名は Administration Console で修正できません。また、BEA が推奨する命名規約では、セキュリティ ロール名は単数形です。 |
FORM
タイプが指定されており、レルムは指定されていないのでデフォルトのレルムになります。つまり、セキュリティ制約は WebLogic Server インスタンスの起動時にアクティブなセキュリティ レルムに適用されます。admin
のみがセキュリティ制約で定義されているので、ここでは 1 つのセキュリティ ロール名のみ定義されています。ただし、セキュリティ ロールは必要なだけ定義できます。<?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 アプリケーションのセキュリティ ロールを修正できます。<?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>
welcome.jsp
ファイルです。図 3-3 は、ウェルカム画面です。<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>
注意 : | コード リスト 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.xml
ファイル (コード リスト 3-9) では、<role-name> タグで admin
が edit.jsp
ファイルにアクセス可能なグループとして定義され、ユーザ joe
がそのグループのメンバーとして定義されています。したがって、Administration Console を使用して admin
グループを定義し、ユーザ joe
を定義して、joe
を admin
グループに追加します。他のユーザを定義してグループに追加することもでき、その追加ユーザも保護された WebLogic リソースにアクセスすることができます。ユーザとグループの追加については、『ロールおよびポリシーによる WebLogic リソースの保護』の「ユーザ、グループ、セキュリティ ロール」を参照してください。
http://
hostname
:7001/security/welcome.jsp
Web アプリケーションで ID アサーションを使用すると、認証を目的としてクライアントの ID を検証できます。ID アサーションを使用するときには、以下の要件を満たす必要があります。
Web アプリケーションで双方向 SSL を使用すると、クライアントが、それがそうであると主張するクライアントであることを検証できます。双方向 SSL を使用するときには、以下の要件を満たす必要があります。
注意 : | SSL 認証を使用する場合、サーバの SSL コンフィグレーションを Administration Console で指定するので、web.xml および weblogic.xml ファイルを使用してサーバのコンフィグレーションを指定する必要はありません。 |
Servlet 2.4 仕様では、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 つの方法でコンフィグレーションできます。
WebLogic Java Management Extensions (JMX) を使用すると、RealmMBean
にアクセスしてセキュリティ リソースを作成および管理できます。詳細については、『JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server サブシステム MBean の概要」を参照してください。
Web ブラウザでは、JFC (Java Foundation Classes) の Swing コンポーネントを使用して開発されたグラフィカル ユーザ インタフェース (GUI) を操作することもできます。Swing コンポーネント キットは、J2SE (Java 2 プラットフォーム Standard Edition) に統合されています。
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 アプリケーションのデプロイについては、『WebLogic Server アプリケーションのデプロイメント』の「weblogic.deployer によるアプリケーションおよびモジュールのデプロイ」を参照してください。 |
basicauth
という Web アプリケーションのディレクトリ構造を示しています。最上位ディレクトリには Web アプリケーションの名前を割り当て、サブディレクトリは WEB-INF
という名前にする必要があります。applications
ディレクトリに移動します。たとえば、basicauth
Web アプリケーションは次の位置にデプロイします。
WL_HOME
\user_projects\domains\mydomain\applications\basicauth
WebLogic Server インスタンスが動作している場合、アプリケーションは自動デプロイされるはずです。Administration Console を使用すると、アプリケーションがデプロイされたことを確認できます。
WebLogic Server インスタンスが動作していない場合は、サーバを起動するとアプリケーションは自動デプロイされます。
weblogic.xml
ファイルを調べます。たとえば、basicauth
サンプルの weblogic.xml
ファイル (コード リスト 3-2) では、myGroup
が welcome.jsp
ファイルにアクセスできる唯一のグループとして定義されています。
セキュアな Web アプリケーションのデプロイについては、『WebLogic Server アプリケーションのデプロイメント』の「weblogic.deployer によるアプリケーションおよびモジュールのデプロイ」を参照してください。
宣言によるセキュリティは、以下の 3 つの方法で実装できます。
これら 3 つのうちどの方法を使用するかは、JACC フラグとセキュリティ モデルによって定義されます (セキュリティ モデルについては、『ロールおよびポリシーによる WebLogic リソースの保護』の「Web アプリケーションおよび EJB リソースの保護のオプション」を参照)。
Web アプリケーションに宣言によってセキュリティを実装するには、デプロイメント記述子 (web.xml
および weblogic.xml
) を使用してセキュリティ要件を定義します。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、サーブレット コンテナがセキュリティ定義を使って、要件を実施します。デプロイメント記述子の使い方については、「セキュアな Web アプリケーションの開発」を参照してください。
デプロイメント記述子および externally-defined
要素を使用して Web アプリケーションのセキュリティを宣言によってコンフィグレーションする方法については、「externally-defined」を参照してください。
Administration Console を使用して Web アプリケーションのセキュリティをコンフィグレーションする方法については、『ロールおよびポリシーによる WebLogic リソースの保護』を参照してください。
以下のトピックでは、Web アプリケーションのセキュリティ要件を定義するために web.xml
および weblogic.xml
ファイルで使用されるデプロイメント記述子の要素について説明します。
以下の web.xml
のセキュリティ関連のデプロイメント記述子の要素が、WebLogic Server でサポートされています。
省略可能な auth-constraint
要素では、このセキュリティ制約で定義された Web リソースの集合にアクセスするグループまたはプリンシパルを定義します。
次の表では、auth-constraint
要素内で定義できる要素について説明します。
<security-constraint> で定義されたリソースにアクセスできるセキュリティ ロールを定義する。セキュリティ ロール名は、<security-role-ref> 要素を使用してプリンシパルにマップされる。 「security-role-ref」を参照。
|
auth-constraint
要素は、security-constraint
要素内で使用されます。
web.xml
ファイルで auth-constraint
要素を使用する例については、コード リスト 3-11 を参照してください。
security-constraint
要素は、web-resource-collection
要素で定義されたリソースの集合へのアクセス特権を定義するために web.xml
ファイルで使用されます。
次の表では、security-constraint 要素内で定義できる要素について説明します。
コード リスト 3-11 は、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
要素内で定義できる要素について説明します。
weblogic.xml で対応するエントリが必要になる。weblogic.xml によって、ロールはセキュリティ レルムにあるプリンシパルにマップされる。詳細については、「security-role-assignment」を参照。
|
web.xml
ファイルで security-role
要素を使用する例については、コード リスト 3-14 を参照してください。
security-role-ref
要素は、<security-role>
で定義されたセキュリティ ロール名を、サーブレットのロジックでハード コード化される代替ロール名にリンクします。この特別な抽象化レイヤによって、サーブレット コードを変更しなくてもデプロイメント時にサーブレットをコンフィグレーションできるようになります。
次の表では、security-role-ref
要素内で定義できる要素について説明します。
web.xml
で security-role-ref
要素を使用する例については、コード リスト 3-17 を参照してください。
user-data-constraint
要素は、クライアントとサーバ間でやり取りされるデータの保護方法を定義します。
次の表では、user-data-constraint
要素内で定義できる要素について説明します。
user-data-constraint
要素は、security-constraint
要素内で使用されます。
web.xml
ファイルで user-data-constraint
要素を使用する例については、コード リスト 3-11 を参照してください。
web-resource-collection
要素は、セキュリティ制約を適用する Web アプリケーションのリソースおよび HTTP
メソッドのサブセットを識別するために使用します。HTTP
メソッドが指定されていない場合、セキュリティ制約はすべての HTTP
メソッドに適用されます。
次の表では、web-resource-collection
要素内で定義できる要素について説明します。
|
||
web-resource-collection
要素は、security-constraint
要素内で使用されます。
web.xml
ファイルで web-resource-collection
要素を使用する例については、コード リスト 3-11 を参照してください。
以下の weblogic.xml
のセキュリティ関連のデプロイメント記述子の要素が、WebLogic Server でサポートされています。
weblogic.xml
デプロイメント記述子の詳細については、『WebLogic Server アプリケーションの開発』の「XML デプロイメント記述子」を参照してください。
weblogic.xml
要素の詳細については、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「weblogic.xml デプロイメント記述子の要素」を参照してください。
externally-defined
要素を使用すると、web.xml
デプロイメント記述子の role-name
要素によって定義されたセキュリティ ロールが Administration Console で指定したマッピングを使用するよう指定できます。この要素を使用することで、特定の Web アプリケーションのデプロイメント記述子に定義されたセキュリティ ロールごとに特定のセキュリティ ロール マッピングを指定する必要がなくなります。このため、同じセキュリティ レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、Administration Console を使用して他のアプリケーションのセキュリティを指定および変更できます。
サーバのロール マッピングの動作は、Administration Console でどのセキュリティ デプロイメント モデルを選択したかによって異なります。セキュリティ デプロイメント モデルの詳細については、『ロールおよびポリシーによる WebLogic リソースの保護』の「Web アプリケーションおよび EJB リソースの保護のオプション」を参照してください。
注意 : | セキュリティ ロール名を指定する場合には、以下の規約と制限に従ってください。 |
Nmtoken
に関して定義されているとおりです (http://www.w3.org/TR/REC-xml#NT-Nmtoken)。
externally-defined
要素は、security-role-assignment
要素内で使用されます。
コード リスト 3-12 とコード リスト 3-13 は、weblogic.xml
ファイルで externally-defined
要素を使用する方法を比較して示しています。コード リスト 3-13 で、weblogic.xml
内の「webuser」の externally-defined
要素は、セキュリティが getReceipts
メソッドにおいて正しくコンフィグレーションされるには Administration Console で webuser
に対応するプリンシパルが作成される必要がある、ということを意味します。
注意 : | 大量のプリンシパルをリストする必要がある場合は、ユーザの代わりにグループを指定することを検討してください。指定したユーザが多すぎると、パフォーマンスが低下するおそれがあります。 |
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>
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
要素を使用する例については、コード リスト 3-14 を参照してください。
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-14 は、run-as-role-assignment
要素を使用して、SnoopServlet
を常にユーザ joe
として実行させる方法を示しています。
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
要素は、Java EE Sandbox と関連するセキュリティ パーミッションを指定します。
security-permission
要素を使用する例については、コード リスト 3-15 を参照してください。
security-permission-spec 要素は、セキュリティ ポリシー ファイル構文に基づいて単一のセキュリティ パーミッションを指定します。Sun のセキュリティ パーミッション仕様の実装については、次の URL を参照してください。
http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax
注意 : | オプションの codebase および signedBy 句は無視してください。 |
security-permission-spec
要素は、security-permission
要素内で使用されます。
コード リスト 3-15 は、security-permission-spec 要素を使用して、java.net.SocketPermission
クラスにパーミッションを付与する方法を示しています。
<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 要素を使用する方法については、『WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。 |
コード リスト 3-16 は、security-role-assignment
要素を使用してプリンシパルを PayrollAdmin
ロールに割り当てる方法を示しています。
注意 : | 大量のプリンシパルをリストする必要がある場合は、ユーザの代わりにグループを指定することを検討してください。指定したユーザが多すぎると、パフォーマンスが低下するおそれがあります。 |
<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/javaee/5/docs/tutorial/doc/Security-WebTier4.html を参照してください。
javax.servlet.http.HttpServletRequest.isUserInRole(String role)
メソッドは、認証されたユーザが、指定された論理セキュリティ「ロール」を付与されているかどうかを示すブール値を返します。ユーザが認証されていない場合、このメソッドは false を返します。
isUserInRole()
メソッドは、セキュリティ ロールをセキュリティ レルムのグループ名にマップします。コード リスト 3-17 は、web.xml
ファイルでセキュリティ ロールを定義するために <servlet>
要素と一緒に使用される要素を示しています。
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
")
コード リスト 3-18 は例を示しています。
サーブレット コード :
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 を参照してください。
コード リスト 3-19 は、SimpleCallbackHandler
を使用する例を示しています。コード リスト 3-20 は、URLCallbackHandler
を使用する例を示しています。
CallbackHandler handler = new SimpleCallbackHandler(username,
password);
Subject mySubject =
weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
// request は httpservletrequest オブジェクト
CallbackHandler handler = new URLCallbackHandler(username,
password);
Subject mySubject =
weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
//request
はhttpservletrequest
オブジェクト
![]() ![]() ![]() |