この章の内容は次のとおりです。
注意:
Webアプリケーションの保護には、デプロイメント記述子ファイルとWebLogic Server管理コンソールを使用できます。このドキュメントでは、デプロイメント記述子ファイルを使用する方法について説明します。WebLogic Server管理コンソールを使用したWebアプリケーションの保護の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
WebLogic Serverは、Webアプリケーションにおけるプログラムによる認可を実装するために、HttpServletRequest.isUserInRole
メソッドとHttpServletRequest.getUserPrincipal
メソッドの使用、およびデプロイメント記述子でのsecurity-role-ref要素の使用をサポートしています。
Webブラウザは、HyperText Transfer Protocol (HTTP)ポートまたはHTTP with SSL (HTTPS)ポートを介してWebLogic Serverに接続できます。HTTPポートではなくHTTPSポートを利用するメリットは2つあります。HTTPS接続を利用するメリットは以下のとおりです。
Webブラウザとサーバーの間で行われるすべての通信が暗号化されます。ユーザー名とパスワードを含め、通信がクリア・テキストで行われることはありません。
最低限の認証要件として、サーバーは身元を証明するためにWebブラウザ・クライアントに対してデジタル証明書を提示する必要があります。
双方向SSL認証を行うようにサーバーが構成された場合は、サーバーとクライアントの両方が互いにデジタル証明書を提示して、身元を証明する必要があります。
WebLogic Serverでは、ユーザーがWebブラウザを使用してHTTPポート経由でサーバーに接続するときにユーザー名とパスワードの認証が行われます。その場合、ブラウザとWebLogic Serverのインスタンスは次のように対話してユーザーを認証します(図3-1を参照)。
WebLogic Serverは、WebブラウザのユーザーがHTTPSポート経由でサーバーに接続する場合に暗号化とデジタル証明書の認証を使用します。その場合、ブラウザとサーバーは次のように対話してユーザーを認証および認可します(図3-1を参照)。
詳細については、以下のドキュメントを参照してください。
『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』
Apache HTTP Serverプラグインのインストールと構成
Microsoft IISプラグインのインストールと構成
デフォルトでは、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が暗号化されずに)送信されている場合にのみ発生します。
この後の項で説明するように、WebLogic ServerにはセッションCookieを保護する機能が2つ用意されています。
注意:
SSLリクエストがWebLogic Serverで終了する場合のみ、これらの2つの機能は適切に動作します。SSL接続がWebサーバー・プラグインやハードウェア型ロード・バランサで終了するプロキシ・アーキテクチャでは、これらの機能が動作するようにWeblogicPluginEnabled
属性を有効にできますが、これを行うとセッション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デプロイメント記述子の要素を参照してください。
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 (JSESSIONID
Cookieと_WL_AUTHCOOKIE_JSESSIONID
Cookie)が使用されています。デフォルトでは、JSESSIONID
Cookieはセキュアではありませんが、_WL_AUTHCOOKIE_JSESSIONID
Cookieは常にセキュアです。セキュアなCookieは、暗号化された通信チャネルが使用されている場合のみ送信されます。標準のHTTPSログインを想定した場合(HTTPSは暗号化されたHTTP接続)、ブラウザは両方のCookieを取得します。
それ以降のHTTPアクセスでは、有効なJSESSIONID
Cookieがあれば認証済みと判断されますが、HTTPSアクセスの場合は、両方のCookieがないと認証済みとは見なされません。JSESSIONID
Cookieしかない場合は、再び認証する必要があります。
この機能が有効な場合は、HTTPS経由で一度ログインすると、セキュアなCookieはネットワーク上を暗号化された状態でしか送信されません。したがって途中で盗まれることはありません。ただしJSESSIONID
Cookieは、それでも途中で盗まれる恐れがあります。したがって、Webサイトの設計者はすべての機密データでHTTPSが必須となるようにすることでセッションの盗難が起こらないようにできます。HTTPセッションCookieはまだ盗用に対して脆弱ですが、すべての機密を扱う処理で_WL_AUTHCOOKIE_JSESSIONID
(盗まれない)が必須となっているので、それらの処理は保護されます。
weblogic.xml
デプロイメント記述子の<session-descriptor>
要素で定義するCookieName
パラメータを使用して、JSESSIONID
または_WL_AUTHCOOKIE_JSESSIONID
のCookie名を指定することもできます。次に例を示します。
<session-descriptor> <cookie-name>FOOAPPID</cookie-name> </session-descriptor>
この場合、Weblogic ServerではJSESSIONID
と_WL_AUTHCOOKIE_JSESSIONID
は使用されず、かわりにFOOAPPID
と_WL_AUTHCOOKIE_FOOAPPID
が使用されます。以上を表3-1にまとめます。
表3-1 WebLogic ServerのCookie
デプロイメント記述子でのユーザー指定 | HTTPセッション | HTTPSセッション |
---|---|---|
いいえ - デフォルトの |
JSESSIONID |
_WL_AUTHCOOKIE_JSESSIONID |
はい - |
FOOAPPID |
_WL_AUTHCOOKIE_FOOAPPID |
WebLogic Serverは、Webブラウザに関して以下の3タイプの認証をサポートしています。
BASIC
FORM
CLIENT-CERT
以下の節では、これらのタイプの認証を使用する様々な方法を紹介します。
BASIC認証の場合、WebブラウザはWebLogicリソースのリクエストに応じてログイン画面を表示します。そのログイン画面は、ユーザー名とパスワードの入力をユーザーに要求します。図3-2は典型的なログイン画面を示します。
注意:
非セキュアなリソースの処理に関する重要な情報については、「リソースが非セキュアな場合のBASIC認証の理解」を参照してください。
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
となっています。
注意:
セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。
セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(http://www.w3.org/TR/REC-xml#NT-Nmtoken
)。
スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。
セキュリティ・ロール名では大文字と小文字が区別されます。
推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。
<login-config>
タグを使用して、使用する認証のタイプとセキュリティ制約が適用されるセキュリティ・レルムを定義します。例3-1では、BASICタイプが指定されており、レルムはデフォルトのレルムとなっています。つまり、セキュリティ制約はWebLogic Serverインスタンスの起動時にアクティブなセキュリティ・レルムに適用されます。
1つまたは複数のセキュリティ・ロールを定義し、それらをセキュリティ制約にマップします。サンプルでは、1つのセキュリティ・ロールwebuser
のみがセキュリティ制約で定義されているので、ここでは1つのセキュリティ・ロール名のみ定義されています(例3-1の<security-role>
を参照)。ただし、セキュリティ・ロールは必要なだけ定義できます。
weblogic.xml
デプロイメント記述子を作成します。このファイルでは、セキュリティ・ロール名をユーザーおよびグループにマップします。例3-2は、weblogic.xmlファイルの<security-role>
タグで定義されているwebuserセキュリティ・ロールをmyGroupというグループにマップするサンプルweblogic.xmlファイルです。プリンシパルは、ユーザーにもグループにもできるため、<principal-tag>
はどちらにも使用できます。この構成の場合、WebLogic ServerはmyGroupユーザーのみに、保護されたURLリソースwelcome.jspへのアクセスを許可します。
注意:
バージョン9.0からは、ロール・マッピングのデフォルト動作によって、weblogic.xmlに何も指定されていないと空のロール・マッピングが作成されるようになりました。バージョン8.xではweblogic.xmlファイルを含めなかった場合や、ファイルを含めたがすべてのセキュリティ・ロールのマッピングは含めなかった場合、マップされていないセキュリティ・ロールはすべて、デフォルトで、ロール名に一致する名前を持つユーザーまたはグループに設定されていました。ロール・マッピングの動作および後方互換性の設定の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護の「ロール・マッピングの組合せを有効化」設定の理解を参照してください。
ユーザーがユーザー名とパスワードを入力してアクセスが許可されたときに表示される「ようこそ」画面を生成するファイルを作成します。例3-3は、サンプルのwelcome.jsp
ファイルです。図3-3は、「ようこそ」画面を示しています。
注意:
例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が定義されています。したがって、WebLogic Server管理コンソールを使用してmyGroup
グループを定義し、ユーザーを定義して、そのユーザーをmyGroup
グループに追加します。ユーザーとグループの追加の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のユーザー、グループおよびセキュリティ・ロールを参照してください。
Webアプリケーションをデプロイし、前の手順で定義したユーザーを使用して保護されたURLリソースにアクセスします。
デプロイメントの手順については、「Webアプリケーションのデプロイメント」を参照してください。
Webブラウザを開き、次のURLを入力します。
http://localhost:7001/basicauth/welcome.jsp
ユーザー名とパスワードを入力します。「ようこそ」画面が表示されます。
例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>
例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 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>
ブラウザはユーザーの資格証明をキャッシュし、それらをサーバーに対して高い頻度で自動的に再送信します。これによって、ログアウトまたはタイムアウト後もWebLogic Serverセッションが破棄されていないように見えます。資格証明は、ブラウザに応じて、現在のブラウザ・セッションでのみキャッシュしたり、複数のセッションにまたがってキャッシュすることができます。
WebLogic Serverのセッションが破棄されたことを確認するには、javax.servlet.http.HttpSessionListener
インタフェースを実装するクラスを作成します。このインタフェースを実装すると、Webアプリケーションにおけるアクティブ・セッションのリストへの変更が通知されます。通知イベントを取得するには、対象Webアプリケーションについて、web.xml
のデプロイメント記述子で実装クラスを構成する必要があります。
セッション・リスナー・クラスを構成するには:
例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. } }
セッション・リスナー・クラスを作成し、デプロイします。例3-4のサンプルでは、単純なカウンタを使用してセッション数をトラッキングしています。
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フラグの設定は、WebLogic Server管理コンソールには表示されません。しかし、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はソース・コードを示しています。
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
が定義されています。
注意:
セキュリティ・ロール名でハイフンは使用しないでください。ハイフンのあるセキュリティ・ロール名はWebLogic Server管理コンソールで修正できません。また、推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。
使用する認証のタイプとセキュリティ制約が適用されるセキュリティ・レルムを定義します。この場合は、FORM
タイプが指定されており、レルムは指定されていないのでデフォルトのレルムになります。つまり、セキュリティ制約はWebLogic Serverインスタンスの起動時にアクティブなセキュリティ・レルムに適用されます。
1つまたは複数のセキュリティ・ロールを定義し、それらをセキュリティ制約にマップします。サンプルでは、1つのセキュリティ・ロールadmin
のみがセキュリティ制約で定義されているので、ここでは1つのセキュリティ・ロール名のみ定義されています。ただし、セキュリティ・ロールは必要なだけ定義できます。
weblogic.xml
デプロイメント記述子を作成します。このファイルでは、セキュリティ・ロール名をユーザーおよびグループにマップします。例3-9は、web.xmlファイルの<security-role>
タグで定義されているadmin
セキュリティ・ロールをsupportGroupというグループにマップするサンプルweblogic.xml
ファイルです。この構成の場合、WebLogic ServerはsupportGroupグループのユーザーのみに、保護されたWebLogicリソースへのアクセスを許可します。ただし、WebLogic Server管理コンソールを使用すると、他のグループも保護されたWebLogicリソースへのアクセスが許可されるようにWebアプリケーションのセキュリティ・ロールを修正できます。
ユーザーがURLを入力して保護されたWebアプリケーション・リソースをリクエストしたときに「ようこそ」画面を生成するWebアプリケーション・ファイルを作成します。例3-10は、サンプルのwelcome.jsp
ファイルです。図3-3は、「ようこそ」画面を示しています。
注意:
例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がそのグループのメンバーとして定義されています。したがって、WebLogic Server管理コンソールを使用してadminグループを定義し、ユーザーjoeを定義して、joeをadminグループに追加します。他のユーザーを定義してグループに追加することもでき、その追加ユーザーも保護されたWebLogicリソースにアクセスすることができます。ユーザーとグループの追加の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のユーザー、グループおよびセキュリティ・ロールを参照してください。
Webアプリケーションをデプロイし、前の手順で定義したユーザーを使用して保護されたWebアプリケーション・リソースにアクセスします。
デプロイメントの手順については、「Webアプリケーションのデプロイメント」を参照してください。
Webブラウザを開き、次のURLを入力します。
http://hostname:7001/security/welcome.jsp
ユーザー名とパスワードを入力します。「ようこそ」画面が表示されます。
例3-6 フォーム-ベースのログイン画面(login.jsp)のソース・コード
<html> <head>) <title>Security WebApp login page</title> </head> <body bgcolor="#cccccc"> <blockquote> <img src=Button_Final_web.gif align=right> <h2>Please enter your user name and password:</h2> <p> <form method="POST" action="j_security_check"> <table border=1> <tr> <td>Username:</td> <td><input type="text" name="j_username"></td> </tr> <tr> <td>Password:</td> <td><input type="password" name="j_password"></td> </tr> <tr> <td colspan=2 align=right><input type=submit value="Submit"></td> </tr> </table> </form> </blockquote> </body> </html>
例3-7 ログイン・エラー画面のソース・コード
<html> <head> <title>Login failed</title> </head> <body bgcolor=#ffffff> <blockquote> <img src=/security/Button_Final_web.gif align=right> <h2>Sorry, your user name and password were not recognized.</h2> <p><b> <a href="/security/welcome.jsp">Return to welcome page</a> or <a href="/security/logout.jsp">logout</a> </b> </blockquote> </body> </html>
FORM認証を提供するWebアプリケーションを開発するには、次の手順を実行します。
例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>
例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>
例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>
WebアプリケーションでIDアサーションを使用すると、認証を目的としてクライアントのIDを検証できます。IDアサーションを使用するときには、以下の要件を満たす必要があります。
Webアプリケーションで双方向SSLを使用すると、クライアントが、それがそうであると主張するクライアントであることを検証できます。双方向SSLを使用するときには、以下の要件を満たす必要があります。
Servlet 3.0仕様(http://jcp.org/en/jsr/detail?id=315
)では、Webアプリケーションで使用する認証方法(BASIC、FORM、その他)を定義できます。WebLogic Serverはauth-method
セキュリティ・モジュールを提供しています。このモジュールを使用すると、複数の認証方式を(カンマ区切りのリストとして)定義できるため、コンテナはフォールバック・メカニズムを提供できます。認証は、auth-method
リストで値が定義されている順序で試行されます。
たとえば、web.xml
ファイルのlogin-config
要素に次のauth-method
リストを定義できます。
<login-config> <auth-method>CLIENT-CERT,BASIC</auth-method> </login-config>
コンテナは最初に、CLIENT-CERT値を確認して認証を試みます。これに失敗すると、コンテナはBASIC認証のユーザー・エージェントを再試行します。
FORMまたはBASICのいずれかが構成される場合、これらはユーザーとの往復の対話が必要なため、リストの最後に指定する必要があります。ただし、FORMとBASICの両方をauth-method
値のリスト内に一緒に指定することはできません。
auth-method
認証のセキュリティは、以下の2つの方法で構成できます。
web.xml
ファイルのlogin-config
要素にauth-method
値をカンマ区切りのリストとして定義します。
auth-method
値をRealmMBean
上でカンマ区切りのリストとして定義し、web.xml
のlogin-config
要素でREALM値を使用します(このようにすると、Webアプリケーションはセキュリティ・レルムから認証方式を取得します)。
WebLogic Java Management Extensions (JMX)を使用すると、RealmMBeanにアクセスしてセキュリティ・リソースを作成および管理できます。詳細は、Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発のWebLogic ServerサブシステムMBeanの概要を参照してください。
Webブラウザでは、JFC (Java Foundation Classes)のSwingコンポーネントを使用して開発されたグラフィカル・ユーザー・インタフェース(GUI)を操作することもできます。
Swingコンポーネントを使用してアプリケーションおよびアプレットのGUI (グラフィカル・ユーザー・インタフェース)を作成する方法については、JFC/SwingによるGUIの作成のチュートリアル(Swingチュートリアルともいいます)を参照してください。このチュートリアルは、Web(http://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アプリケーションのデプロイの詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイのweblogic.deployerによるアプリケーションおよびモジュールのデプロイを参照してください。
セキュアなWebアプリケーションのデプロイの詳細は、Oracle WebLogic Serverへのアプリケーションのデプロイのweblogic.deployerによるアプリケーションおよびモジュールのデプロイを参照してください。
宣言によるセキュリティは、以下の3つの方法で実装できます。
これら3つのうちどの方法を使用するかは、JACCフラグとセキュリティ・モデルによって定義されます。(セキュリティ・モデルについては、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のEJBおよびWebアプリケーション・リソースの保護のオプションを参照してください。)
Webアプリケーションに宣言によってセキュリティを実装するには、デプロイメント記述子(web.xml
およびweblogic.xml
)を使用してセキュリティ要件を定義します。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、サーブレット・コンテナがセキュリティ定義を使って、要件を実施します。デプロイメント記述子の使い方については、「セキュアなWebアプリケーションの開発」を参照してください。
デプロイメント記述子およびexternally-defined
要素を使用してWebアプリケーションのセキュリティを宣言によって構成する方法については、「externally-defined」を参照してください。
WebLogic Server管理コンソールを使用してWebアプリケーションのセキュリティを構成する方法の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
以下のトピックでは、Webアプリケーションのセキュリティ要件を定義するためにweb.xml
およびweblogic.xml
ファイルで使用されるデプロイメント記述子の要素について説明します。
以下のweb.xml
のセキュリティ関連のデプロイメント記述子の要素が、WebLogic Serverでサポートされています。
省略可能なauth-constraint
要素では、このセキュリティ制約で定義されたWebリソースの集合にアクセスするグループまたはプリンシパルを定義します。
注意:
auth-constraint
要素で保護されるリソースは、INTEGRAL
またはCONFIDENTIAL
の<transport-guarantee>
を含む表3-6でも保護する必要があります。
INTEGRAL
またはCONFIDENTIAL
のトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSSL (Secure Sockets Layer)接続を確立します。これにより、Webブラウザとサーバーの間で行われるネットワーク上のすべての通信が暗号化され、通信(ユーザー名とパスワードを含む)がクリア・テキストで行われることはありません。
「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic ServerではJSESSIONID
Cookieと暗号化された_WL_AUTHCOOKIE_JSESSIONID
Cookieの2つが使用されます。
次の表では、auth-constraint
要素内で定義できる要素について説明します。
表3-2 auth-constraint要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
<description> |
省略可能 |
このセキュリティ制約の説明文。 |
<role-name> |
省略可能 |
この |
security-constraint
要素は、web-resource-collection
要素で定義されたリソースの集合へのアクセス権限を定義するためにweb.xml
ファイルで使用されます。
注意:
auth-constraint
要素で保護されるリソースは、INTEGRAL
またはCONFIDENTIAL
の<transport-guarantee>
を含む表3-6でも保護する必要があります。
INTEGRAL
またはCONFIDENTIAL
のトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSSL (Secure Sockets Layer)接続を確立します。これにより、Webブラウザとサーバーの間で行われるネットワーク上のすべての通信が暗号化され、通信(ユーザー名とパスワードを含む)がクリア・テキストで行われることはありません。
「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic ServerではJSESSIONID
Cookieと暗号化された_WL_AUTHCOOKIE_JSESSIONID
Cookieの2つが使用されます。
次の表では、security-constraint要素内で定義できる要素について説明します。
表3-3 security-constraint要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
<web-resource-collection> |
必須 |
このセキュリティ制約が適用されるWebアプリケーションのコンポーネントを定義します。詳細については、以下を参照。web-resource-collection |
<auth-constraint> |
省略可能 |
このセキュリティ制約で定義されるWebリソースの集合にアクセスするグループまたはプリンシパルを定義します。詳細については、「auth-constraint」を参照してください。 |
<user-data-constraint> |
省略可能 |
クライアントとサーバー間でやり取りされるデータの保護方法を定義します。詳細については、user-data-constraintを参照してください。 |
例3-11は、security-constraint
要素を使用して、web.xml
でSecureOrdersEastリソースのセキュリティを定義する方法を示しています。
例3-11 セキュリティ制約の例
web.xml entries: <security-constraint> <web-resource-collection> <web-resource-name>SecureOrdersEast</web-resource-name> <description> Security constraint for resources in the orders/east directory </description> <url-pattern>/orders/east/*</url-pattern> <http-method>POST</http-method> <http-method>GET</http-method> </web-resource-collection> <auth-constraint> <description> constraint for east coast sales </description> <role-name>east</role-name> <role-name>manager</role-name> </auth-constraint> <user-data-constraint> <description>SSL not required</description> <transport-guarantee>NONE</transport-guarantee> </user-data-constraint> </security-constraint> ...
security-role
要素には、セキュリティ・ロールの定義が指定されます。定義は、セキュリティ・ロールの説明(オプション)とセキュリティ・ロール名から成ります。
次の表では、security-role
要素内で定義できる要素について説明します。
表3-4 security-role要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
<description> |
省略可能 |
セキュリティ・ロールの説明文。 |
<role-name> |
必須 |
ロール名。ここで使用する名前は、 |
security-role-ref要素は<security-role>
で定義されたセキュリティ・ロール名を、サーブレットのロジックでハード・コード化される代替ロール名にリンクします。この特別な抽象化レイヤーによって、サーブレット・コードを変更しなくてもデプロイメント時にサーブレットを構成できるようになります。
次の表では、security-role-ref
要素内で定義できる要素について説明します。
表3-5 security-role-ref要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
<description> |
省略可能 |
ロールの説明文。 |
<role-name> |
必須 |
サーブレット・コード内で使用されるセキュリティ・ロールまたはプリンシパルの名前を定義します。 |
<role-link> |
必須 |
後にデプロイメント記述子内の |
user-data-constraint
要素は、クライアントとサーバー間でやり取りされるデータの保護方法を定義します。
注意:
auth-constraint
要素で保護されるリソースは、INTEGRAL
またはCONFIDENTIAL
の<transport-guarantee>
を含む表3-6でも保護する必要があります。
INTEGRAL
またはCONFIDENTIAL
のトランスポート保証を使用してユーザーが認証を受けた場合、WebLogic ServerはSSL (Secure Sockets Layer)接続を確立します。これにより、Webブラウザとサーバーの間で行われるネットワーク上のすべての通信が暗号化され、通信(ユーザー名とパスワードを含む)がクリア・テキストで行われることはありません。
「セキュアなCookieを使用したセッション盗難の防止」で説明されているように、SSLが必要な場合、WebLogic ServerではJSESSIONID
Cookieと暗号化された_WL_AUTHCOOKIE_JSESSIONID
Cookieの2つが使用されます。
次の表では、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サーブレット仕様( パターン |
<http-method> |
省略可能 |
クライアントがWebリソースの集合にアクセスしようとするときにセキュリティ制約を適用する ここで |
以下のweblogic.xml
のセキュリティ関連のデプロイメント記述子の要素が、WebLogic Serverでサポートされています。
weblogic.xml
デプロイメント記述子の詳細は、Oracle WebLogic Serverアプリケーションの開発のXMLデプロイメント記述子を参照してください。
weblogic.xml
要素の詳細は、Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発のweblogic.xmlデプロイメント記述子の要素を参照してください。
externally-defined
要素を使用すると、web.xml
デプロイメント記述子のrole-name
要素によって定義されたセキュリティ・ロールが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、< >、#、|、&、~、?、( )、{ }を使用しないでください。
セキュリティ・ロール名では大文字と小文字が区別されます。
推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。
例3-12と例3-13は、weblogic.xml
ファイルでexternally-defined
要素を使用する方法を比較して示しています。例3-13で、weblogic.xml
内の「webuser」のexternally-defined
要素は、セキュリティがgetReceipts
メソッドにおいて正しく構成されるにはWebLogic Server管理コンソールで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>
WebLogic Server管理コンソールを使用してWebアプリケーションのセキュリティを構成する方法の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
run-as-principal-name
要素では、対応するweb.xml
ファイルのrun-as
要素で定義されるセキュリティ・ロールに使用するプリンシパル名を指定します。
run-as-role-assignment
要素は、対応するweb.xml
ファイルのrole-name
要素で定義されるロール名をシステム内の有効なユーザー名にマップします。この値は、servlet-descriptorのrun-as-principal-name
要素によって任意のサーブレットについてオーバーライドできます。ロール名のrun-as-role-assignment
要素がない場合は、security-role-assignment
要素に定義されている最初のprincipal-nameをWebアプリケーション・コンテナが選択します。
次の表では、run-as-role-assignment
要素内で定義できる要素について説明します。
表3-8 run-as-role-assignment要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
<role-name> |
必須 |
対応する |
<run-as-principal-name> |
必須 |
対応する |
例3-14は、run-as-role-assignment
要素を使用して、SnoopServlet
を常にユーザーjoe
として実行させる方法を示しています。
例3-14 run-as-role-assignment要素の例
web.xml: <servlet> <servlet-name>SnoopServlet</servlet-name> <servlet-class>extra.SnoopServlet</servlet-class> <run-as> <role-name>runasrole</role-name> </run-as> </servlet> <security-role> <role-name>runasrole</role-name> </security-role> weblogic.xml: <weblogic-web-app> <run-as-role-assignment> <role-name>runasrole</role-name> <run-as-principal-name>joe</run-as-principal-name> </run-as-role-assignment> </weblogic-web-app>
security-permission-spec要素は、セキュリティ・ポリシー・ファイル構文に基づいて単一のセキュリティ許可を指定します。セキュリティ許可仕様の実装については、次のURLを参照してください。
http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html#FileSyntax
注意:
オプションのcodebaseおよびsignedBy句は無視してください。
例3-15は、security-permission-spec要素を使用して、java.net.SocketPermission
クラスに許可を付与する方法を示しています。
例3-15 security-permission-spec要素の例
<weblogic-web-app> <security-permission> <description>Optional explanation goes here</description> <security-permission-spec> <!-- A single grant statement following the syntax of http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax, without the "codebase" and "signedBy" clauses, goes here. For example: --> grant { permission java.net.SocketPermission "*", "resolve"; }; </security-permission-spec> </security-permission> </weblogic-web-app>
例3-15では、permission java.net.SocketPermissionは許可クラス名を、"*"はターゲット名を、resolveはアクション(host/IP名サービスのルックアップを解決する)を示します。
security-role-assignment
要素は、セキュリティ・ロールとWebLogic Serverセキュリティ・レルムの1つまたは複数のプリンシパルとのマッピングを宣言します。
注意:
エンタープライズ・アプリケーションのweblogic-application.xmlデプロイメント記述子でsecurity-role-assignment要素を使用する方法の詳細は、Oracle WebLogic Serverアプリケーションの開発のエンタープライズ・アプリケーションのデプロイメント記述子の要素を参照してください。
例3-16は、security-role-assignment
要素を使用してプリンシパルをPayrollAdmin
ロールに割り当てる方法を示しています。
注意:
大量のプリンシパルをリストする必要がある場合は、ユーザーのかわりにグループを指定することを検討してください。指定したユーザーが多すぎると、パフォーマンスが低下するおそれがあります。
例3-16 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>
サーブレットを記述して、そのサーブレット・コードでプログラム的にユーザーとセキュリティ・ロールにアクセスできます。そのためには、サーブレットのコードでjavax.servlet.http.HttpServletRequest.getUserPrincipal
およびjavax.servlet.http.HttpServletRequest.isUserInRole(String role)
メソッドを使用します。
getUserPrincipal()
メソッドは、Webアプリケーションの現在のユーザーを特定するために使用します。このメソッドは、1ユーザーが存在する場合にWLSUser
Principal
を返します。WLSUser
Principal
が複数の場合、このメソッドは、Subject.getPrincipals().iterator()
メソッドで指定された順序の1番目を返します。WLSUser
Principal
が存在しない場合、getUserPrincipal()
メソッドはWLSGroup
Principal
以外の1番目を返します。Principal
が存在しない場合、またはすべてのPrincipal
がWLSGroup
型の場合、このメソッドはnull
を返します。この動作は、weblogic.security.SubjectUtils.getUserPrincipal()
メソッドのセマンティクスと同じです。
getUserPrincipal()
メソッドの使用方法の詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.html
を参照してください。
javax.servlet.http.HttpServletRequest.isUserInRole(String role)
メソッドは、認証されたユーザーが、指定された論理セキュリティ「ロール」を付与されているかどうかを示すブール値を返します。ユーザーが認証されていない場合、このメソッドはfalseを返します。
isUserInRole()
メソッドは、セキュリティ・ロールをセキュリティ・レルムのグループ名にマップします。例3-17は、web.xml
ファイルでセキュリティ・ロールを定義するために<servlet>
要素と一緒に使用される要素を示しています。
注意:
セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。
セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様でNmtokenに関して定義されているとおりです(http://www.w3.org/TR/REC-xml#NT-Nmtoken
)。
スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。
セキュリティ・ロール名では大文字と小文字が区別されます。
推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。
たとえば、クライアントがmanager
というセキュリティ・ロールのBill
というユーザーでログインに成功している場合、次のメソッドはtrueを返します。
request.isUserInRole("manager")
例3-18は例を示しています。
例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>
に対応します。
例3-18 セキュリティ・ロール・マッピングの例
Servlet code: out.println("Is the user a Manager? " + request.isUserInRole("manager")); web.xml entries: <servlet> . . . <role-name>manager</role-name> <role-link>mgr</role-link> . . . </servlet> <security-role> <role-name>mgr</role-name> </security-role> weblogic.xml entries: <security-role-assignment> <role-name>mgr</role-name> <principal-name>bostonManagers</principal-name> <principal-name>Bill</principal-name> <principal-name>Ralph</principal-name> </security-role-ref>
一部のアプリケーションでは、プログラムによる認証を使用するのが適切です。
WebLogic Serverは、サーバー側のAPIとしてweblogic.servlet.security.ServletAuthentication
を備えています。このAPIは、サーブレット・アプリケーション内からプログラムによる認証をサポートします。weblogic.servlet.security.ServletAuthentication
APIを使用すると、ユーザーを認証してログインできます。
いったんログインが完了すると、標準のメカニズムを使用してログインしたかのように感じられます。
ServletAuthentication
APIと一緒にWebLogicが提供するweblogic.security.SimpleCallbackHandler
クラスまたはweblogic.security.URLCallbackHandler
クラスのうちいずれかを使用できます。これらのクラスの詳細は、Oracle WebLogic Server用Java APIリファレンスを参照してください。
例3-19は、SimpleCallbackHandler
を使用する例を示しています。例3-20は、URLCallbackHandler
を使用する例を示しています。
例3-19 SimpleCallbackHandlerクラスを使用したプログラムによる認証コードの一部
CallbackHandler handler = new SimpleCallbackHandler(username, password); Subject mySubject = weblogic.security.services.Authentication.login(handler); weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request); // Where request is the httpservletrequest object.
例3-20 URLCallbackHandlerクラスを使用したプログラムによる認証コードの一部
CallbackHandler handler = new URLCallbackHandler(username, password); Subject mySubject = weblogic.security.services.Authentication.login(handler); weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request); // Where request is the httpservletrequest object.
HttpSessionがサーブレットで生成されると、一意のIDと関連付けられます。ブラウザは、このセッションIDをそのリクエストに付与し、サーバーが再びセッション・データを見つけられるようにする必要があります。
「セッション固定化」と呼ばれる種類の攻撃を回避するには、ログイン時にユーザーのセッションを変更する必要があります。これを実行するには、login
メソッドを呼び出した後、weblogic.servlet.security.ServletAuthentication
のgenerateNewSessionID
メソッドを呼び出します。
generateNewSessionID
メソッドは、現在のすべてのセッション情報IDを完全に別のセッションIDに移動し、当該セッションを新しいIDに関連付けます。
注意:
セッション自体に変更はなく、その識別子のみが変更されます。
レガシー・アプリケーションは、ログイン前後に残っているIDと同一のセッションIDに依存できます。generateNewSessionID
を呼び出すと、このようなアプリケーションが壊れてしまいます。このような依存関係はアプリケーションに構築しないことをお薦めします。ただし、構築する場合またはこの種類のレガシー・アプリケーションを処理する場合は、SSLを使用してアプリケーションに対するすべてのアクセスを保護することをお薦めします。
デフォルトでは、WebLogicコンテナはプログラム以外によるログインのIDを自動的に再生成します。
generateNewSessionID()
メソッドに関する追加情報は、ServletAuthentication
を参照してください。