2 Webアプリケーションの保護
ノート:
Webアプリケーションの保護には、デプロイメント記述子ファイルとWebLogic Server管理コンソールを使用できます。このドキュメントでは、デプロイメント記述子ファイルを使用する方法について説明します。WebLogic Server管理コンソールを使用したWebアプリケーションの保護の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
プログラムによる認可をWebアプリケーションに実装するために、WebLogic Serverでは次のものの使用がサポートされています:
-
サーブレットの
HttpServletRequest.isUserInRoleメソッドおよびHttpServletRequest.getUserPrincipalメソッド -
デプロイメント記述子の
security-role-ref要素 -
Java EE Security APIの
SecurityContext.getCallerPrincipal、SecurityContext.getPrincipalsByType、SecurityContext.isCallerInRoleおよびSecurityContext.hasAccessToWebResourceメソッド
Webブラウザでの認証
Webブラウザは、HyperText Transfer Protocol (HTTP)ポートまたはHTTP with SSL (HTTPS)ポートを介してWebLogic Serverに接続できます。WebLogic Serverは、WebブラウザがHTTPSポートを使用してサーバーに接続する場合に暗号化とデジタル証明書の認証を使用します。
HTTPポートではなくHTTPSポートを利用するメリットは2つあります。HTTPS接続を利用するメリットは以下のとおりです。
-
Webブラウザとサーバーの間で行われるすべての通信が暗号化されます。ユーザー名とパスワードを含め、通信がクリア・テキストで行われることはありません。
-
最低限の認証要件として、サーバーは身元を証明するためにWebブラウザ・クライアントに対してデジタル証明書を提示する必要があります。
双方向SSL認証を行うようにサーバーが構成された場合は、サーバーとクライアントの両方が互いにデジタル証明書を提示して、身元を証明する必要があります。
ユーザー名およびパスワードの認証
WebLogic Serverでは、ユーザーがWebブラウザを使用してHTTPポート経由でサーバーに接続するときにユーザー名とパスワードの認証が行われます。その場合、ブラウザとWebLogic Serverのインスタンスは次のように対話してユーザーを認証します(図2-1を参照):
デジタル証明書の認証
WebLogic Serverは、WebブラウザのユーザーがHTTPSポート経由でサーバーに接続する場合に暗号化とデジタル証明書の認証を使用します。その場合、ブラウザとサーバーは次のように対話してユーザーを認証および認可します(図2-1を参照):
次のトピックを参照してください。
複数のWebアプリケーション、Cookie、および認証
デフォルトでは、WebLogic ServerはすべてのWebアプリケーションに同じCookie名(JSESSIONID)を割り当てます。同じCookie名を使用するWebアプリケーションでは、どの種類の認証を使用する場合でも、認証用に1つのサインオンを使用します。ユーザーが認証されると、その認証は、同じCookie名を使用するすべてのWebアプリケーションへのリクエストに対して有効になります。ユーザーは再び認証を要求されることはありません。
Webアプリケーションごとに個別の認証が必要な場合は、Webアプリケーションに一意のCookie名またはCookieパスを指定できます。CookieNameパラメータでクッキー名を指定し、CookiePathパラメータでクッキー・パスを指定します。これらのパラメータは、weblogic.xmlの<session-descriptor>要素で定義されます。『Oracle WebLogic Serverサーバーの起動と停止の管理』のsession-descriptorに関する項を参照してください。
Cookie名を保持しつつWebアプリケーションごとに別々の認証が必要な場合は、WebアプリケーションごとにCookieパス・パラメータ(CookiePath)を変えることができます。
ただし、Webセキュリティの一般的な問題は、セッションの盗難です。「セキュアなCookieを使用したセッション盗難の防止」で説明しているように、Webサイトの設計者がセッション盗難の防止で使用できる機能や方法が2つ、WebLogic Serverに用意されています。
セキュアなCookieを使用したセッション盗難の防止
一般的に、Cookieがネットワーク経由で転送されている間に、攻撃者がセッションCookieのコピーを取得しようとしたとき、セッション盗難が発生します。この問題は、データがクリア・テキストで(つまり、Cookieが暗号化されずに)送信されている場合にのみ発生します。WebLogic Serverでは、セッションCookieの保護に2つの機能が用意されています。
ノート:
SSLリクエストがWebLogic Serverで終了する場合のみ、これらの2つの機能は適切に動作します。SSL接続がWebサーバー・プラグインやハードウェア型ロード・バランサで終了するプロキシ・アーキテクチャでは、これらの機能が動作するようにWeblogicPluginEnabled属性を有効にできますが、これを行うとセッションCookieがプロキシの背後で公開されます。
セキュアなCookieとしてのセッションCookieの構成
HTTPSを使用するようにアプリケーションを構成することで、セッション盗難を防止できます。WebLogic Serverとの通信がSSLで保護されていると、<cookie-secure>要素をweblogic.xmlデプロイメント記述子で指定してこの値をtrueに設定することで、WebLogic ServerでセッションCookieをセキュアにできます。SSLなどのセキュアなプロトコルのみ使用してCookieを送信する必要があることをセキュアなCookieはWebブラウザに指示します。
ブラウザで実行しているコード付きアプリケーション(たとえば、アプレット)では非HTTPアウトバウンド接続ができます。そのような接続では、ブラウザでセッションCookieを送信します。ただし、<cookie-http-only>要素をweblogic.xmlで指定すると、CookieをHTTP接続上でのみ送信するようにブラウザが制限され、ブラウザで実行しているアプリケーションや他のプロトコルではCookieをアクセスできません。そのため、<cookie-secure>と関連付けて<cookie-http-only>を指定する場合、セッションCookieがHTTPS上でのみ送信されることを確認します。
<cookie-secure>と<cookie-http-only>の要素の詳細は、Oracle WebLogic ServerのWebアプリケーション、サーブレット、JSPの開発でweblogic.xmlデプロイメント記述子の要素を参照してください。
AuthCookie _WL_AUTHCOOKIE_JSESSIONIDの使用
WebLogic Serverでは、セッション・データを失うことなく、HTTPを使用して開始されたセッションでHTTPSリソースにユーザーが安全にアクセスできます。この機能を有効にするには、config.xmlのWebServer要素にAuthCookieEnabled="true"を追加します。
<WebServer Name="myserver" AuthCookieEnabled="true"/>
AuthCookieEnabledをtrue(デフォルト設定)に設定すると、新しいセキュアなCookie(_WL_AUTHCOOKIE_JSESSIONID)が、HTTPS接続を介した認証時にブラウザに送信されるようになります。一度セキュアなCookieが設定されると、セッションはそのCookieがブラウザから送信された場合しかセキュリティ制約のある他のHTTPSリソースにアクセスできません。
このように、WebLogic Serverでは2つのCookie (JSESSIONIDCookieと_WL_AUTHCOOKIE_JSESSIONIDCookie)が使用されています。デフォルトでは、JSESSIONIDCookieはセキュアではありませんが、_WL_AUTHCOOKIE_JSESSIONIDCookieは常にセキュアです。セキュアなCookieは、暗号化された通信チャネルが使用されている場合のみ送信されます。標準のHTTPSログインを想定した場合(HTTPSは暗号化されたHTTP接続)、ブラウザは両方のCookieを取得します。
それ以降のHTTPアクセスでは、有効なJSESSIONIDCookieがあれば認証済みと判断されますが、HTTPSアクセスの場合は、両方のCookieがないと認証済みとは見なされません。JSESSIONIDCookieしかない場合は、再び認証する必要があります。
この機能が有効な場合は、HTTPS経由で一度ログインすると、セキュアなCookieはネットワーク上を暗号化された状態でしか送信されません。したがって途中で盗まれることはありません。ただしJSESSIONIDクッキーは、それでも途中で盗まれる恐れがあります。したがって、Webサイトの設計者はすべての機密データでHTTPSが必須となるようにすることでセッションの盗難が起こらないようにできます。HTTPセッションCookieはまだ盗用に対して脆弱ですが、すべての機密を扱う処理で_WL_AUTHCOOKIE_JSESSIONID (盗まれない)が必須となっているので、それらの処理は保護されます。
weblogic.xmlデプロイメント記述子の<session-descriptor>要素で定義するCookieNameパラメータを使用して、JSESSIONIDまたは_WL_AUTHCOOKIE_JSESSIONIDのCookie名を指定することもできます。次に例を示します。
<session-descriptor>
<cookie-name>FOOAPPID</cookie-name>
</session-descriptor>
この場合、Weblogic ServerではJSESSIONIDと_WL_AUTHCOOKIE_JSESSIONIDは使用されず、かわりにFOOAPPIDと_WL_AUTHCOOKIE_FOOAPPIDが使用されます。以上を表2-1にまとめます。
表2-1 WebLogic ServerのCookie
| デプロイメント記述子でのユーザー指定 | HTTPセッション | HTTPSセッション |
|---|---|---|
|
いいえ - デフォルトの |
JSESSIONID |
_WL_AUTHCOOKIE_JSESSIONID |
|
はい - |
FOOAPPID |
_WL_AUTHCOOKIE_FOOAPPID |
セキュアなWebアプリケーションの開発
WebLogic Serverは、Webブラウザに関してBASIC、FORMおよびCLIENT-CERTの3タイプの認証をサポートしています。
以下の節では、これらのタイプの認証を使用する様々な方法を紹介します。
BASIC、FORMおよびカスタムFORM認証を含むユーザー認証の実行方法としては他に、「Java EE Security APIの使用」で説明されているようにHttpAuthenticationMechanismを使用する方法があります。
ノート:
Java EE Security APIでは、グループ・プリンシパル名がデフォルトで同じ名前のロールにマップされている必要があります。WebLogic Serverでは、weblogic.xmlデプロイメント記述子のsecurity-role-assignment要素が、WebLogic Serverセキュリティ・レルムでセキュリティ・ロールと1つ以上のプリンシパルとの間のマッピングを宣言していない場合、ロール名がデフォルトのプリンシパルとして使用されます。
BASIC認証Webアプリケーションの開発
BASIC認証の場合、WebブラウザはWebLogicリソースのリクエストに応じてログイン画面を表示します。そのログイン画面は、ユーザー名とパスワードの入力をユーザーに要求します。図2-2は典型的なログイン画面を示します。
ノート:
非セキュアなリソースの処理に関する重要な情報については、「リソースが非セキュアな場合のBASIC認証の理解」を参照してください。
BASIC認証を提供するWebアプリケーションを開発するには、次のステップを実行します。
-
web.xmlデプロイメント記述子を作成します。このファイルには、次の情報を含めます(例2-1を参照):-
ウェルカム・ファイルを定義します。ウェルカム・ファイルの名前は
welcome.jspです。 -
保護する予定のWebアプリケーション・リソース、つまりURLリソースの各セットについてセキュリティ制約を定義します。リソースの各セットは共通のURLを共有します。HTMLページ、JSP、サーブレットなどは最も一般的に保護されるURLリソースですが、他のタイプのURLリソースもサポートされています。例2-1では、URLパターンはWebアプリケーションの最上位ディレクトリに位置する
welcome.jspファイルを指しており、URLリソースへのアクセスが許可されるHTTPメソッドはPOSTとGET、セキュリティ・ロール名はwebuserとなっています。ノート:
セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。
-
セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(
http://www.w3.org/TR/REC-xml#NT-Nmtoken)。 -
スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。
-
セキュリティ・ロール名では大文字と小文字が区別されます。
-
推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。
-
-
<login-config>タグを使用して、使用する認証のタイプとセキュリティ制約が適用されるセキュリティ・レルムを定義します。例2-1では、BASICタイプが指定されており、レルムはデフォルトのレルムとなっています。つまり、セキュリティ制約はWebLogic Serverインスタンスの起動時にアクティブなセキュリティ・レルムに適用されます。 -
1つまたは複数のセキュリティ・ロールを定義し、それらをセキュリティ制約にマップします。サンプルでは、1つのセキュリティ・ロール
webuserのみがセキュリティ制約で定義されているので、ここでは1つのセキュリティ・ロール名のみ定義されています(例2-1の<security-role>を参照)。ただし、セキュリティ・ロールは必要なだけ定義できます。
-
-
weblogic.xmlデプロイメント記述子を作成します。このファイルでは、セキュリティ・ロール名をユーザーおよびグループにマップします。例2-2は、weblogic.xmlファイルの<security-role>タグで定義されているwebuserセキュリティ・ロールをmyGroupというグループにマップするサンプルweblogic.xmlファイルです。プリンシパルは、ユーザーにもグループにもできるため、<principal-tag>はどちらにも使用できます。この構成の場合、WebLogic ServerはmyGroupユーザーのみに、保護されたURLリソースwelcome.jspへのアクセスを許可します。ノート:
バージョン9.0からは、ロール・マッピングのデフォルト動作によって、weblogic.xmlに何も指定されていないと空のロール・マッピングが作成されるようになりました。バージョン8.xではweblogic.xmlファイルを含めなかった場合や、ファイルを含めたがすべてのセキュリティ・ロールのマッピングは含めなかった場合、マップされていないセキュリティ・ロールはすべて、デフォルトで、ロール名に一致する名前を持つユーザーまたはグループに設定されていました。ロール・マッピングの動作および後方互換性の設定の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護の「ロール・マッピングの組合せを有効化」設定の理解を参照してください。
-
ユーザーがユーザー名とパスワードを入力してアクセスが許可されたときに表示される「ようこそ」画面を生成するファイルを作成します。例2-3は、サンプルの
welcome.jspファイルです。図2-3は、「ようこそ」画面を示しています。ノート:
例2-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ファイル(例2-2を参照)では、<principal-name>タグで、welcome.jspにアクセス可能なグループとしてmyGroupが定義されています。したがって、WebLogic Server管理コンソールを使用してmyGroupグループを定義し、ユーザーを定義して、そのユーザーをmyGroupグループに追加します。ユーザーとグループの追加の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のユーザー、グループおよびセキュリティ・ロールを参照してください。 -
Webアプリケーションをデプロイし、前のステップで定義したユーザーを使用して保護されたURLリソースにアクセスします。
-
デプロイメントの手順については、「Webアプリケーションのデプロイメント」を参照してください。
-
Webブラウザを開き、次のURLを入力します。
http://localhost:7001/basicauth/welcome.jsp
-
ユーザー名とパスワードを入力します。「ようこそ」画面が表示されます。
-
例2-1 BASIC認証のweb.xmlファイル
<?xml version='1.0' encoding='UTF-8'?>
<web-app version="4.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd">
<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>例2-2 BASIC認証のweblogic.xmlファイル
<?xml version='1.0' encoding='UTF-8'?>
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.4/weblogic-web-app.xsd">
<security-role-assignment>
<role-name>webuser</role-name>
<principal-name>myGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>例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>HttpSessionListenerを使用したブラウザによる資格証明のキャッシングの報告
ブラウザはユーザーの資格証明をキャッシュし、それらをサーバーに対して高い頻度で自動的に再送信します。これによって、ログアウトまたはタイムアウト後もWebLogic Serverセッションが破棄されていないように見えます。資格証明は、ブラウザに応じて、現在のブラウザ・セッションでのみキャッシュしたり、複数のセッションにまたがってキャッシュすることができます。
WebLogic Serverのセッションが破棄されたことを確認するには、javax.servlet.http.HttpSessionListenerインタフェースを実装するクラスを作成します。このインタフェースを実装すると、Webアプリケーションにおけるアクティブ・セッションのリストへの変更が通知されます。通知イベントを取得するには、対象Webアプリケーションについて、web.xmlのデプロイメント記述子で実装クラスを構成する必要があります。
セッション・リスナー・クラスを構成するには:
例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++;
// 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.
}
}
リソースが非セキュアな場合のBASIC認証の理解
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フラグを設定するには、次のステップに従います。
WLSTを使用してenforce-valid-basic-auth-credentialsの値を確認する
enforce-valid-basic-auth-credentialsフラグの設定は、WebLogic Server管理コンソールには表示されません。しかし、WLSTを使用すると、実行中のサーバーでの値を確認できます。enforce-valid-basic-auth-credentialsがドメイン全体の設定である点には注意してください。
例2-5に実行中のサンプル・サーバーでenforce-valid-basic-auth-credentialsの値を確認するためのWLSTセッションを示します。
例2-5 enforce-valid-basic-auth-credentialsの値の確認
wls:/offline> connect('','','t3://host:port')
Please enter your username :adminuser
Please enter your password :
Connecting to t3://host:port with userid adminuser ...
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
:
:FORM認証Webアプリケーションの開発
WebアプリケーションでFORM認証を使用する場合は、Webアプリケーション・リソースのリクエストに応じてWebブラウザが表示するカスタム・ログイン画面とログインが失敗した場合に表示されるエラー画面を用意します。ログイン画面はHTMLページ、JSP、またはサーブレットを使用して生成できます。フォームベースのログインのメリットは、これらの画面を完全に管理できるので、アプリケーションやエンタープライズ・ポリシー/ガイドラインの要件にあわせてそれらを設計できることです。
そのログイン画面は、ユーザー名とパスワードの入力をユーザーに要求します。図2-4は、JSPを使用して生成される典型的なログイン画面を、例2-6はソース・コードを示しています。
図2-5は、HTMLを使用して生成される典型的なログイン・エラー画面を、例2-7はソース・コードを示しています。
FORM認証を提供するWebアプリケーションを開発するには、次のステップを実行します。
-
web.xmlデプロイメント記述子を作成し、次の情報を追加します。-
ウェルカム・ファイルを定義します。ウェルカム・ファイルの名前は
welcome.jspです。 -
保護する予定のURLリソースの各セットについてセキュリティ制約を定義します。URLリソースの各セットは共通のURLを共有します。HTMLページ、JSP、サーブレットなどは最も一般的に保護されるURLリソースですが、他のタイプのURLリソースもサポートされています。次のステップで示されているサンプルの
web.xmlファイルでは、URLパターンは/admin/edit.jspを指しており(したがって、Webアプリケーションのadminサブディレクトリに配置されたedit.jspファイルが保護されます)、URLリソースへのアクセスが許可されるHTTPメソッド(GET)が定義され、セキュリティ・ロール名adminが定義されています。ノート:
セキュリティ・ロール名でハイフンは使用しないでください。ハイフンのあるセキュリティ・ロール名はWebLogic Server管理コンソールで修正できません。また、推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。
-
使用する認証のタイプとセキュリティ制約が適用されるセキュリティ・レルムを定義します。この場合は、
FORMタイプが指定されており、レルムは指定されていないのでデフォルトのレルムになります。つまり、セキュリティ制約はWebLogic Serverインスタンスの起動時にアクティブなセキュリティ・レルムに適用されます。 -
1つまたは複数のセキュリティ・ロールを定義し、それらをセキュリティ制約にマップします。サンプルでは、1つのセキュリティ・ロール
adminのみがセキュリティ制約で定義されているので、ここでは1つのセキュリティ・ロール名のみ定義されています。ただし、セキュリティ・ロールは必要なだけ定義できます。次にweb.xmlサンプル・ファイルを示します。<?xml version='1.0' encoding='UTF-8'?> <web-app xmlns="http://xmlns.jcp.org/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デプロイメント記述子を作成します。このファイルでは、セキュリティ・ロール名をユーザーおよびグループにマップします。次の例は、web.xmlファイルの<security-role>タグで定義されているadminセキュリティ・ロールをsupportGroupというグループにマップするサンプルweblogic.xmlファイルです。この構成の場合、WebLogic ServerはsupportGroupグループのユーザーのみに、保護された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>admin</role-name> <principal-name>supportGroup</principal-name> </security-role-assignment> </weblogic-web-app>ただし、WebLogic Server管理コンソールを使用すると、他のグループも保護されたWebLogicリソースへのアクセスが許可されるようにWebアプリケーションのセキュリティ・ロールを修正できます。
-
ユーザーがURLを入力して保護されたWebアプリケーション・リソースをリクエストしたときに「ようこそ」画面を生成するWebアプリケーション・ファイルを作成します。次の例は、
welcome.jspファイルのサンプルを示しています。図2-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=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())を呼び出していることに留意してください。かわりに、別のAPI (weblogic.security.Security.getCurrentSubject())を使用することもできます。このAPIを使用してユーザーの名前を取得するには、次のようにSubjectUtils APIと共に使用します。
String username = weblogic.security.SubjectUtils.getUsername weblogic.security.Security.getCurrentSubject()); -
WebLogic Serverを起動し、URLリソースにアクセス可能なユーザーおよびグループを定義します。サンプル
weblogic.xmlファイルでは、<role-name>タグでadminがedit.jspファイルにアクセス可能なグループとして定義され、ユーザーjoeがそのグループのメンバーとして定義されています。したがって、WebLogic Server管理コンソールを使用してadminグループを定義し、ユーザー「joe」を定義して、「joe」をadminグループに追加します。他のユーザーを定義してグループに追加し、その追加ユーザーに、保護されたWebLogicリソースへのアクセス権を付与することもできます。ユーザーとグループの追加の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のユーザー、グループおよびセキュリティ・ロールを参照してください。 -
Webアプリケーションをデプロイし、前のステップで定義したユーザーを使用して保護されたWebアプリケーション・リソースにアクセスします。
-
デプロイメントの手順については、「Webアプリケーションのデプロイメント」を参照してください。
-
Webブラウザを開き、次のURLを入力します。
http://hostname:7001/security/welcome.jsp
-
ユーザー名とパスワードを入力します。「ようこそ」画面が表示されます。
-
例2-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>
例2-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>
Webアプリケーションの認証にIDアサーションの使用
WebアプリケーションでIDアサーションを使用すると、認証を目的としてクライアントのIDを検証できます。IDアサーションを使用するときには、以下の要件を満たす必要があります。
- 認証のタイプはCLIENT-CERTに設定する必要があります。
- サーバーにIDアサーション・プロバイダが構成されている必要があります。WebブラウザまたはJavaクライアントがセキュリティ・ポリシーで保護されたWebLogic Serverリソースをリクエストする場合、WebLogic ServerはWebブラウザまたはJavaクライアントがIDを持つことを要求します。WebLogic IDアサーション・プロバイダは、WebブラウザまたはJavaクライアントからのトークンをWebLogic Serverセキュリティ・レルムのユーザーにマップします。IDアサーション・プロバイダの構成方法の詳細は、Oracle WebLogic Serverセキュリティの管理のIDアサーション・プロバイダの構成に関する項を参照してください。
- トークンの値に対応するユーザーは、サーバーのセキュリティ・レルムで定義されていなければなりません。定義されていない場合、クライアントは保護されているWebLogicリソースにアクセスできません。サーバーにおけるユーザーの構成の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のユーザー、グループおよびセキュリティ・ロールを参照してください。
Webアプリケーションの認証に双方向SSLの使用
Webアプリケーションで双方向SSLを使用すると、クライアントが、それがそうであると主張するクライアントであることを検証できます。双方向SSLを使用するときには、以下の要件を満たす必要があります。
認証方式に対するフォールバック・メカニズムの提供
Servlet 4.0仕様(https://jcp.org/en/jsr/detail?id=369)では、Webアプリケーションで使用する認証方法(BASIC、FORM、その他)を定義できます。WebLogic Serverはauth-methodセキュリティ・モジュールを提供しています。このモジュールを使用すると、複数の認証方式を(カンマ区切りのリストとして)定義できるため、コンテナはフォールバック・メカニズムを提供できます。認証は、auth-methodリストで値が定義されている順序で試行されます。
たとえば、web.xmlファイルのlogin-config要素に次のauth-methodリストを定義できます。
<login-config> <auth-method>CLIENT-CERT,BASIC</auth-method> </login-config>
コンテナは最初に、CLIENT-CERT値を確認して認証を試みます。これに失敗すると、コンテナはBASIC認証のユーザー・エージェントを再試行します。
FORMまたはBASICのいずれかが構成される場合、これらはユーザーとの往復の対話が必要なため、リストの最後に指定する必要があります。ただし、FORMとBASICの両方をauth-method値のリスト内に一緒に指定することはできません。
構成
auth-method認証のセキュリティは、以下の2つの方法で構成できます。
-
web.xmlファイルのlogin-config要素にauth-method値をカンマ区切りのリストとして定義します。 -
auth-method値をRealmMBean上でカンマ区切りのリストとして定義し、web.xmlのlogin-config要素でREALM値を使用します(このようにすると、Webアプリケーションはセキュリティ・レルムから認証方式を取得します)。
WebLogic Java Management Extensions (JMX)を使用すると、RealmMBeanにアクセスしてセキュリティ・リソースを作成および管理できます。詳細は、Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発のWebLogic ServerサブシステムMBeanの概要を参照してください。
Swingベース認証Webアプリケーションの開発
Webブラウザでは、JFC (Java Foundation Classes)のSwingコンポーネントを使用して開発されたグラフィカル・ユーザー・インタフェース(GUI)を操作することもできます。
Swingコンポーネントを使用してアプリケーションおよびアプレットのGUI (グラフィカル・ユーザー・インタフェース)を作成する方法については、JFC/SwingによるGUIの作成のチュートリアル(Swingチュートリアルともいいます)を参照してください。このチュートリアルは、Web(http://docs.oracle.com/javase/tutorial/uiswing/)で入手できます。
SwingベースのGUIを開発したら、「FORM認証Webアプリケーションの開発」を参照し、Swingベースの画面を使用して、FORM認証を提供するWebアプリケーションの開発に必要なステップを実行します。
ノート:
SwingベースのGUIを開発する場合、swingイベント・スレッドの子スレッドにJava仮想マシン全体のユーザーを使用しないでください。これはJava EEに準拠していないので、通常はシン・クライアントやIIOPでは動作しません。かわりに、以下のいずれかの方法を用います。
-
Swingアーティファクトの前にInitialContextを作成します。
-
または、Java Authentication and Authorization Service (JAAS)を使用してログインしてから、Swingイベント・スレッドとその子でSecurity.runAs()メソッドを使用します。
Webアプリケーションのデプロイメント
開発モードで動作しているサーバーにWebアプリケーションをデプロイするには、次のステップを実行します。
ノート:
開発モードまたは本番モードでのWebアプリケーションのデプロイの詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイのweblogic.deployerによるアプリケーションおよびモジュールのデプロイを参照してください。
- Webアプリケーションのファイルのディレクトリ構造を構築します。図2-6は、
basicauthというWebアプリケーションのディレクトリ構造を示しています。最上位ディレクトリにはWebアプリケーションの名前を割り当て、サブディレクトリはWEB-INFという名前にする必要があります。
セキュアなWebアプリケーションのデプロイの詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイのweblogic.deployerによるアプリケーションおよびモジュールのデプロイを参照してください。
Webアプリケーションでの宣言によるセキュリティの使用
WebLogic Serverでは、宣言によるセキュリティWebアプリケーションを実装する3つの異なる方法をサポートしています。WebLogic Server管理コンソールを使用してポリシーおよびロールを定義できます。Java Authorization Contract for Containers (JACC)を使用してJavaパーミッション・ベースのセキュリティ・モデルを使用できます。または、Webアプリケーションのデプロイメント記述子ファイル内でセキュリティを完全に構成できます。
コンソールを使用した宣言によるセキュリティの構成の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのWebアプリケーションおよびEJBのセキュリティの管理に関する項を参照してください。JACCの使用の詳細は、「Java Authorization Contract for Containersの使用」を参照してください。続く項で、Webアプリケーションのデプロイメント記述子でセキュリティを構成する方法を説明します。
これら3つのうちどの方法を使用するかは、JACCフラグとセキュリティ・モデルによって定義されます。(セキュリティ・モデルについては、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のEJBおよびWebアプリケーション・リソースの保護のオプションを参照してください。)
Webアプリケーションに宣言によってセキュリティを実装するには、デプロイメント記述子(web.xmlおよびweblogic.xml)を使用してセキュリティ要件を定義します。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、サーブレット・コンテナがセキュリティ定義を使って、要件を実施します。デプロイメント記述子の使い方については、「セキュアなWebアプリケーションの開発」を参照してください。
デプロイメント記述子およびexternally-defined要素を使用してWebアプリケーションのセキュリティを宣言によって構成する方法については、「externally-defined」を参照してください。
WebLogic Serverでは、Webアプリケーションのセキュリティ要件を定義するためにweb.xmlおよびweblogic.xmlファイルで使用されるいくつかのデプロイメント記述子の要素をサポートします。
Webアプリケーションのセキュリティ関連のデプロイメント記述子
WebLogic Serverでは、Webアプリケーションのセキュリティ要件を定義するためにweb.xmlおよびweblogic.xmファイルで使用されるいくつかのデプロイメント記述子の要素をサポートします。
web.xmlデプロイメント記述子
以下のweb.xmlのセキュリティ関連のデプロイメント記述子の要素が、WebLogic Serverでサポートされています。
auth-constraint
省略可能なauth-constraint要素では、このセキュリティ制約で定義されたWebリソースの集合にアクセスするグループまたはプリンシパルを定義します。
ノート:
auth-constraint要素で保護されるリソースは、INTEGRALまたはCONFIDENTIALの<transport-guarantee>を含む表2-6でも保護する必要があります。
INTEGRALまたはCONFIDENTIALのトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSSL (Secure Sockets Layer)接続を確立します。これにより、Webブラウザとサーバーの間で行われるネットワーク上のすべての通信が暗号化され、通信(ユーザー名とパスワードを含む)がクリア・テキストで行われることはありません。
「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic ServerではJSESSIONID Cookieと暗号化された_WL_AUTHCOOKIE_JSESSIONID Cookieの2つが使用されます。
次の表では、auth-constraint要素内で定義できる要素について説明します。
表2-2 auth-constraint要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
このセキュリティ制約の説明文。 |
<role-name> |
省略可能 |
この |
security-constraint
security-constraint要素は、web-resource-collection要素で定義されたリソースの集合へのアクセス権限を定義するためにweb.xmlファイルで使用されます。
ノート:
auth-constraint要素で保護されるリソースは、INTEGRALまたはCONFIDENTIALの<transport-guarantee>を含む表2-6でも保護する必要があります。
INTEGRALまたはCONFIDENTIALのトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSSL (Secure Sockets Layer)接続を確立します。これにより、Webブラウザとサーバーの間で行われるネットワーク上のすべての通信が暗号化され、通信(ユーザー名とパスワードを含む)がクリア・テキストで行われることはありません。
「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic ServerではJSESSIONID Cookieと暗号化された_WL_AUTHCOOKIE_JSESSIONID Cookieの2つが使用されます。
次の表では、security-constraint要素内で定義できる要素について説明します。
表2-3 security-constraint要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<web-resource-collection> |
必須 |
このセキュリティ制約が適用されるWebアプリケーションのコンポーネントを定義します。「web-resource-collection」を参照してください。 |
<auth-constraint> |
省略可能 |
このセキュリティ制約で定義されるWebリソースの集合にアクセスするグループまたはプリンシパルを定義します。「auth-constraint」を参照してください。 |
<user-data-constraint> |
省略可能 |
クライアントとサーバー間でやり取りされるデータの保護方法を定義します。「user-data-constraint」を参照してください。 |
例
例2-8は、security-constraint要素を使用して、web.xmlでSecureOrdersEastリソースのセキュリティを定義する方法を示しています。
例2-8 セキュリティ制約の例
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要素には、セキュリティ・ロールの定義が指定されます。定義は、セキュリティ・ロールの説明(オプション)とセキュリティ・ロール名から成ります。
次の表では、security-role要素内で定義できる要素について説明します。
表2-4 security-role要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
セキュリティ・ロールの説明文。 |
<role-name> |
必須 |
ロール名。ここで使用する名前は、WebLogic固有のデプロイメント記述子 |
security-role-ref
security-role-ref要素は、<security-role>で定義されたセキュリティ・ロール名を、サーブレットのロジックでハード・コード化される代替ロール名にリンクします。この特別な抽象化レイヤーによって、サーブレット・コードを変更しなくてもデプロイメント時にサーブレットを構成できるようになります。
次の表では、security-role-ref要素内で定義できる要素について説明します。
表2-5 security-role-ref要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
ロールの説明文。 |
<role-name> |
必須 |
サーブレット・コード内で使用されるセキュリティ・ロールまたはプリンシパルの名前を定義します。 |
<role-link> |
必須 |
後にデプロイメント記述子内の |
user-data-constraint
user-data-constraint要素は、クライアントとサーバー間でやり取りされるデータの保護方法を定義します。
ノート:
auth-constraint要素で保護されるリソースは、INTEGRALまたはCONFIDENTIALの<transport-guarantee>を含む表2-6でも保護する必要があります。
INTEGRALまたはCONFIDENTIALのトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSSL (Secure Sockets Layer)接続を確立します。これにより、Webブラウザとサーバーの間で行われるネットワーク上のすべての通信が暗号化され、通信(ユーザー名とパスワードを含む)がクリア・テキストで行われることはありません。
「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic ServerではJSESSIONID Cookieと暗号化された_WL_AUTHCOOKIE_JSESSIONID Cookieの2つが使用されます。
次の表では、user-data-constraint要素内で定義できる要素について説明します。
表2-6 user-data-constraint要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
説明文。 |
<transport-guarantee> |
必須 |
クライアントとサーバー間でやり取りされるデータのセキュリティ要件を指定します。 指定できる値:
|
web-resource-collection
web-resource-collection要素は、セキュリティ制約を適用するWebアプリケーションのリソースおよびHTTPメソッドのサブセットを識別するために使用します。HTTPメソッドが指定されていない場合、セキュリティ制約はすべてのHTTPメソッドに適用されます。
次の表では、web-resource-collection要素内で定義できる要素について説明します。
表2-7 web-resource-collection要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
|
|
必須 |
Webリソースの集合の名前。 |
|
|
省略可能 |
Webリソースの説明文。 |
|
|
必須 |
Webリソースの集合のマッピング、つまり場所。 URLパターンには、Javaサーブレット仕様( パターン |
|
|
省略可能 |
クライアントがWebリソースの集合にアクセスしようとするときにセキュリティ制約を適用する ここで |
weblogic.xmlデプロイメント記述子
以下のweblogic.xmlのセキュリティ関連のデプロイメント記述子の要素が、WebLogic Serverでサポートされています。
weblogic.xmlデプロイメント記述子の詳細は、Oracle WebLogic Serverアプリケーションの開発のXMLデプロイメント記述子を参照してください。
weblogic.xml要素の詳細は、Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発のweblogic.xmlデプロイメント記述子の要素を参照してください。
externally-defined
externally-defined要素を使用すると、web.xmlデプロイメント記述子のrole-name要素によって定義されたセキュリティ・ロールがWebLogic Server管理コンソールで指定したマッピングを使用するよう指定できます。この要素を使用することで、特定のWebアプリケーションのデプロイメント記述子に定義されたセキュリティ・ロールごとに特定のセキュリティ・ロール・マッピングを指定する必要がなくなります。このため、同じセキュリティ・レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、WebLogic Server管理コンソールを使用して他のアプリケーションのセキュリティを指定および変更できます。
サーバーのロール・マッピングの動作は、WebLogic Server管理コンソールでどのセキュリティ・デプロイメント・モデルを選択したかによって異なります。セキュリティ・デプロイメント・モデルの詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のEJBおよびWebアプリケーション・リソースの保護のオプションを参照してください。
ノート:
セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。
-
セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(
http://www.w3.org/TR/REC-xml#NT-Nmtoken)。 -
スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。
-
セキュリティ・ロール名では大文字と小文字が区別されます。
-
推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。
例
例2-9と例2-10は、weblogic.xmlファイルでexternally-defined要素を使用する方法を比較して示しています。例2-10で、weblogic.xml内の「webuser」のexternally-defined要素は、セキュリティがgetReceiptsメソッドにおいて正しく構成されるにはWebLogic Server管理コンソールでwebuserに対応するプリンシパルが作成される必要がある、ということを意味します。
ノート:
大量のプリンシパルをリストする必要がある場合は、ユーザーのかわりにグループを指定することを検討してください。指定したユーザーが多すぎると、パフォーマンスが低下するおそれがあります。
例2-9 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>
例2-10 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>
WebLogic Server管理コンソールを使用してWebアプリケーションのセキュリティを構成する方法の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のWebアプリケーションおよびEJBの保護を参照してください。
run-as-principal-name
run-as-principal-name要素では、対応するweb.xmlファイルのrun-as要素で定義されるセキュリティ・ロールに使用するプリンシパル名を指定します。
run-as-role-assignment
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-8 run-as-role-assignment要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<role-name> |
必須 |
対応する |
<run-as-principal-name> |
必須 |
対応する |
例
例2-11は、run-as-role-assignment要素を使用して、SnoopServletを常にユーザーjoeとして実行させる方法を示しています。
例2-11 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
security-permission-spec要素は、セキュリティ・ポリシー・ファイル構文に基づいて単一のセキュリティ許可を指定します。セキュリティ許可仕様の実装については、次のURLを参照してください。
http://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html#FileSyntax
ノート:
オプションのcodebaseおよびsignedBy句は無視してください。
例
例2-12は、security-permission-spec要素を使用して、java.net.SocketPermissionクラスに許可を付与する方法を示しています。
例2-12 security-permission-spec要素の例
<weblogic-web-app>
<security-permission>
<description>Optional explanation goes here</description>
<security-permission-spec>
<!--
A single grant statement following the syntax of
http://xmlns.jcp.org/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax,
without the "codebase" and "signedBy" clauses, goes here. For example:
-->
grant {
permission java.net.SocketPermission "*", "resolve";
};
</security-permission-spec>
</security-permission>
</weblogic-web-app>
例2-12では、permission java.net.SocketPermissionは許可クラス名を、"*"はターゲット名を、resolveはアクション(host/IP名サービスのルックアップを解決する)を示します。
security-role-assignment
security-role-assignment要素は、セキュリティ・ロールとWebLogic Serverセキュリティ・レルムの1つまたは複数のプリンシパルとのマッピングを宣言します。
ノート:
エンタープライズ・アプリケーションのweblogic-application.xmlデプロイメント記述子でsecurity-role-assignment要素を使用する方法の詳細は、Oracle WebLogic Serverアプリケーションの開発のエンタープライズ・アプリケーションのデプロイメント記述子の要素を参照してください。
例
例2-13は、security-role-assignment要素を使用してプリンシパルをPayrollAdminロールに割り当てる方法を示しています。
ノート:
大量のプリンシパルをリストする必要がある場合は、ユーザーのかわりにグループを指定することを検討してください。指定したユーザーが多すぎると、パフォーマンスが低下するおそれがあります。
例2-13 security-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>
Webアプリケーションでのプログラムによるセキュリティの使用
Java EE Security APIのSecurityContextインタフェースおよびサーブレットのHttpServletRequestインタフェースで定義されたメソッドを使用して、プログラムによりユーザーおよびセキュリティ・ロールにアクセスするようにサーブレットを記述できます。
次の各項で、各メソッドについて詳しく説明します:
Java EE Security APIのSecurityContextメソッド
Java仕様で指定されているように、WebLogic Serverでは、サーブレット(Webサービスを含む)およびEJBコンテナ内で次のJava EE Security APIのSecurityContextメソッドがサポートされています:
-
getCallerPrincipal()- 呼出し側を表すプリンシパルを取得する場合は、このメソッドを使用します。これは、呼出し側プリンシパルのコンテナ固有の表現です。このタイプは、最初にHttpAuthenticationMechanismによって確立された呼出し側プリンシパルのタイプとは異なる場合があります。このメソッドは、サーブレット・コンテナまたはEJBコンテナで認証されていない呼出し側に対してnullを返します。 -
getPrincipalsByType()- 特定のタイプのすべてのプリンシパルを取得する場合は、このメソッドを使用します。これを使用すると、認証時に設定されたアプリケーション固有の呼出し側プリンシパルを取得できます。このメソッドが役立つのは主に、コンテナの呼出し側プリンシパルのタイプがアプリケーションの呼出し側プリンシパルのタイプと異なり、アプリケーションがアプリケーション・プリンシパルからのみ使用可能な特定の情報動作を必要とする場合です。呼出し側が認証されていない場合、またはリクエストされたタイプが見つからない場合、このメソッドは空のSetを返します。 -
isCallerInRole()- 認証された呼出し側が指定の論理アプリケーション・ロールに含まれているかどうかをチェックする場合は、このメソッドを使用します。このメソッドは、検証対象の特定のロールを表す文字列引数を取ります。 -
hasAccessToWebResource()- 呼出し側が指定のHTTPメソッドに指定されているWebリソースにアクセスできるかどうか(アプリケーションに構成されているセキュリティ制約により決定される)を判別する場合は、このメソッドを使用します。リソース・パラメータは、Java Authorization Contract for Containers 1.5仕様(http://jcp.org/en/jsr/detail?id=115)で定義されているように、アプリケーション固有のWebリソースを識別するURLPatternSpecです。このメソッドは、現在のアプリケーションのリソースへのアクセスのチェックのみに使用できます。複数のアプリケーションまたはコンテナをまたいで別のアプリケーションのリソースへのアクセスをチェックするために、これを呼び出すことはできません。 -
authenticate()- 呼出し側に関する認証プロセスを開始する必要があることをコンテナに通知する場合は、このメソッドを使用します。
サーブレットのHttpServletRequestメソッド
サーブレットのコードで、javax.servlet.http.HttpServletRequest.getUserPrincipalおよびjavax.servlet.http.HttpServletRequest.isUserInRole(String role)メソッドを使用して、プログラムによりユーザーおよびセキュリティ・ロールにアクセスするようにサーブレットを記述できます。
getUserPrincipal
getUserPrincipal()メソッドは、Webアプリケーションの現在のユーザーを特定するために使用します。このメソッドは、1ユーザーが存在する場合にWLSUser Principalを返します。WLSUser Principalが複数の場合、このメソッドは、Subject.getPrincipals().iterator()メソッドで指定された順序の1番目を返します。WLSUser Principalが存在しない場合、getUserPrincipal()メソッドはWLSGroup Principal以外の1番目を返します。Principalが存在しない場合、またはすべてのPrincipalがWLSGroup型の場合、このメソッドはnullを返します。この動作は、weblogic.security.SubjectUtils.getUserPrincipal()メソッドのセマンティクスと同じです。
getUserPrincipal()メソッドの使用方法の詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.htmlを参照してください。
isUserInRole
javax.servlet.http.HttpServletRequest.isUserInRole(String role)メソッドは、認証されたユーザーが、指定された論理セキュリティ「ロール」を付与されているかどうかを示すブール値を返します。ユーザーが認証されていない場合、このメソッドはfalseを返します。
isUserInRole()メソッドは、セキュリティ・ロールをセキュリティ・レルムのグループ名にマップします。次の例は、web.xmlファイルでセキュリティ・ロールを定義するために<servlet>要素と一緒に使用される要素を示しています。
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>に対応します。
ノート:
セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。
-
セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(
http://www.w3.org/TR/REC-xml#NT-Nmtoken)。 -
スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。
-
セキュリティ・ロール名では大文字と小文字が区別されます。
-
推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。
たとえば、クライアントがmanagerというセキュリティ・ロールのBillというユーザーでログインに成功している場合、次のメソッドはtrueを返します。
request.isUserInRole("manager")
例2-14は例を示しています。
例2-14 セキュリティ・ロール・マッピングの例
Servlet code:
out.println("Is the user a Manager? " +
request.isUserInRole("manager"));
web.xml entries:
<servlet>
. . .
<role-name>manager</role-name>
<role-link>mgr</role-link>
. . .
</servlet>
<security-role>
<role-name>mgr</role-name>
</security-role>
weblogic.xml entries:
<security-role-assignment>
<role-name>mgr</role-name>
<principal-name>bostonManagers</principal-name>
<principal-name>Bill</principal-name>
<principal-name>Ralph</principal-name>
</security-role-ref>
プログラムによるユーザーの認証
WebLogic Serverでは、Java EE Security APIのSecurityContextインタフェースまたはWebLogic ServerのServletAuthentication APIを使用した、サーブレット・アプリケーション内でのプログラムによる認証をサポートしています。
Java EE Security APIのSecurityContextインタフェースの使用
WebLogic Serverでは、ユーザーの認証用にJava EE Security APIのSecurityContextインタフェースのauthenticateメソッドをサポートしています。authenticateメソッドはデフォルトでサーブレット・コンテナ内で有効になっており、移植可能な認証ソリューションが必要な場合に便利です。
アプリケーションでauthenticate()メソッドを使用して、呼出し側に関する認証プロセスを開始する必要があることをコンテナに通知します。このメソッドは、HttpServletRequestパラメータとHttpServletResponseパラメータが渡されることを必要とするため、有効なServletContextでのみ使用できます。
プログラムによる認証APIの使用
WebLogic Serverは、サーバー側のAPIとしてweblogic.servlet.security.ServletAuthenticationを備えています。このAPIは、サーブレット・アプリケーション内からプログラムによる認証をサポートします。
weblogic.servlet.security.ServletAuthentication APIを使用すると、ユーザーを認証してログインできます。いったんログインが完了すると、標準のメカニズムを使用してログインしたかのように感じられます。
ServletAuthentication APIと一緒にWebLogicが提供するweblogic.security.SimpleCallbackHandlerクラスまたはweblogic.security.URLCallbackHandlerクラスのうちいずれかを使用できます。これらのクラスの詳細は、Oracle WebLogic Server用Java APIリファレンスを参照してください。
例2-15は、SimpleCallbackHandlerを使用する例を示しています。例2-16は、URLCallbackHandlerを使用する例を示しています。
例2-15 SimpleCallbackHandlerクラスを使用したプログラムによる認証コードの一部
CallbackHandler handler = new SimpleCallbackHandler(username,
password);
Subject mySubject =
weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
// Where request is the httpservletrequest object.
例2-16 URLCallbackHandlerクラスを使用したプログラムによる認証コードの一部
CallbackHandler handler = new URLCallbackHandler(username,
password);
Subject mySubject =
weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
// Where request is the httpservletrequest object.
ログイン時のユーザー・セッションの変更
HttpSessionがサーブレットで生成されると、一意のIDと関連付けられます。ブラウザは、このセッションIDをそのリクエストに付与し、サーバーが再びセッション・データを見つけられるようにする必要があります。
「セッション固定化」と呼ばれる種類の攻撃を回避するには、ログイン時にユーザーのセッションを変更する必要があります。これを実行するには、loginメソッドを呼び出した後、weblogic.servlet.security.ServletAuthenticationのgenerateNewSessionIDメソッドを呼び出します。
generateNewSessionIDメソッドは、現在のすべてのセッション情報IDを完全に別のセッションIDに移動し、当該セッションを新しいIDに関連付けます。
ノート:
セッション自体に変更はなく、その識別子のみが変更されます。
レガシー・アプリケーションは、ログイン前後に残っているIDと同一のセッションIDに依存できます。generateNewSessionIDを呼び出すと、このようなアプリケーションが壊れてしまいます。このような依存関係はアプリケーションに構築しないことをお薦めします。ただし、構築する場合またはこの種類のレガシー・アプリケーションを処理する場合は、SSLを使用してアプリケーションに対するすべてのアクセスを保護することをお薦めします。
デフォルトでは、WebLogicコンテナはプログラム以外によるログインのIDを自動的に再生成します。
generateNewSessionID()メソッドに関する追加情報は、ServletAuthenticationを参照してください。