| ドキュメントのダウンロード | サイト マップ | Glossary | |
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Server > WebLogic Security プログラマーズ ガイド > Web アプリケーションのセキュリティ対策 |
|
WebLogic Security プログラマーズ ガイド
|
WebLogic Server は Web アプリケーションを保護する J2EE アーキテクチャ セキュリティ モデルをサポートします。これには、宣言による認可 (このマニュアルでは宣言によるセキュリティともいう) およびプログラムによる認可 (このマニュアルではプログラムによるセキュリティともいう) のサポートが含まれます。
注意: Web アプリケーションの保護には、デプロイメント記述子ファイルと Administration Console を使用できます。 このマニュアルでは、デプロイメント記述子ファイルの使用方法について説明します。Administration Console を使用しての Web アプリケーションの保護については、『WebLogic リソースのセキュリティ』を参照してください。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3 Authorization」に、以下のような記述があります。
「J2EE アーキテクチャにおいて、コンテナはホストするコンポーネントとその呼び出し側との間の認可境界として機能します。認可境界は、コンテナの認証境界内に存在するので、認可は正常に実行される認証との関連で考慮されます。着信呼び出しの場合、コンテナは呼び出し側の資格のセキュリティ属性と、対象コンポーネントのアクセス制御ルールを比較します。ルール要件が満たされていれば、呼び出しは許可されます。それ以外の場合、この呼び出しは拒否されます。」
「アクセス制御ルールの定義には、能力とパーミッションという 2 つの基本的アプローチが存在します。能力は呼び出し側が実行できる操作、パーミッションは操作を実行できるユーザを焦点とします。J2EE アプリケーション プログラミング モデルは、パーミッションを焦点とします。J2EE アーキテクチャにおいて、デプロイヤの役割はアプリケーションのパーミッション モデルをその操作環境におけるユーザの能力にマップすることです。」
次にこのマニュアルでは、J2EE アーキテクチャ、宣言による認可、およびプログラムによる認可を使用してアプリケーション リソースへのアクセスを制御する 2 つの方法について説明します。
Sun Microsystems, Inc. の発行によるマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html からオンラインで入手できます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.1 Authorization」に、以下のような記述があります。
WebLogic Server は Web アプリケーションにおいて宣言による認可を実装するためのデプロイメント記述子の使用をサポートしています。
注意: 宣言による認可は、このマニュアルでは宣言によるセキュリティとも呼ばれます。
Sun Microsystems, Inc. の発行によるマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html からオンラインで入手できます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.2 Programmatic Authorization」に、以下のような記述があります。
「J2EE コンテナは、コンポーネントにメソッド呼び出しをディスパッチする前に、アクセス制御の決定を行います。コンポーネントの論理または状態は、これらのアクセス決定を考慮に入れません。しかし、コンポーネントは EJBContext.isCallerInRole (エンタープライズ Bean コード用) および HttpServletRequest.isUserInRole (Web コンポーネント用) の 2 つのメソッドを使用して、きめ細かいアクセス制御を行うことが可能です。コンポーネントはこれらのメソッドを使用して、呼び出しのパラメータ、コンポーネントの初期状態、または呼び出しの時間などその他の要因に基づきコンポーネントによって選択された特権が、呼び出し側に付与されているかどうかを判断します。」
「これらの機能の 1 つを呼び出すコンポーネントのアプリケーション コンポーネント プロバイダは、すべての呼び出しで使用されるあらゆる個別の roleName 値を宣言する必要があります。これらの宣言は、デプロイメント記述子では security-role-ref 要素として登場します。各 security-role-ref 要素は、アプリケーションに roleName として組み込まれた特権名をセキュリティ ロールにリンクします。最終的には、デプロイヤはアプリケーションに組み込まれた特権名と、デプロイメント記述子で定義されたセキュリティ ロールの間のリンクを確立します。特権名とセキュリティ ロールの間のリンクは、同じアプリケーション内でもコンポーネントごとに異なる場合があります。」
「特定の特権をテストするだけでなく、アプリケーション コンポーネントでは EJBContext.getCallerPrincipal または HttpServletRequest.getUserPrincipal を使用して取得した呼び出し側 ID と、作成時のコンポーネントの状態に組み込まれている識別された呼び出し側 ID を比較できます。呼び出し側 ID が識別された呼び出し側のものに等しければ、コンポーネントは呼び出し側に処理の続行を許可できます。等しくなければ、コンポーネントは呼び出し側がそれ以上の対話を行わないようにできます。コンテナによって返された呼び出し側のプリンシパルは、呼び出し側が使用した認証メカニズムによって決まります。また、同じメカニズムによる同じユーザ認証に対してでも、異なったベンダからのコンテナは異なったプリンシパルを返す場合があります。プリンシパルの形式の変動性を考慮に入れるため、コンポーネントのアクセス決定に識別された呼び出し側の状態を適用することを選択した開発者は、同一ユーザを表す複数の識別された呼び出し側 ID がコンポーネントと関連付けられることを許容する必要があります。これは特に、アプリケーションの融通性や移植性が優先される場合に、推奨されます。
WebLogic Server は、Web アプリケーションにおけるプログラムによる認可を実装するための HttpServletRequest.isUserInRole メソッドと HttpServletRequest.getUserPrincipal メソッドの使用、および security-role-ref 要素の使用をサポートしています。
注意: プログラムによる認可は、このマニュアルではプログラムによるセキュリティとも呼ばれます。
Sun Microsystems, Inc. の発行によるマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html からオンラインで入手できます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.3 Declarative Versus Programmatic Authorization」に、以下のような記述があります。
「デプロイヤによってコンフィグレーションされる外部アクセス制御ポリシーと、コンポーネント プロバイダによってアプリケーションに組み込まれた内部ポリシーの間にはトレードオフが存在します。アプリケーションが作成された後では、外部ポリシーのほうが高い融通性を持ちます。アプリケーションが記述されている過程では、内部ポリシーのほうが融通性の高い機能を提供します。また、外部ポリシーはデプロイヤにとって透過的で完全に理解可能であるのに対し、内部ポリシーはアプリケーションに埋め込まれており、これを完全に理解できるのはアプリケーション開発者のみである可能性があります。ある特定のコンポーネントとメソッドについて認可モデルを選択する際には、これらのトレードオフを検討する必要があります。」
Sun Microsystems, Inc. の発行によるマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html からオンラインで入手できます。
Web ブラウザは、HyperText Transfer Protocol (HTTP) ポートまたは HTTP with SSL (HTTPS) ポートを介して WebLogic Server に接続できます。HTTP ポートではなく HTTPS ポートを利用するメリットは 2 つあります。HTTPS 接続を利用するメリットは以下のとおりです。
双方向 SSL 認証を行うようにサーバがコンフィグレーションされた場合は、サーバとクライアントの両方が互いにデジタル証明書を提示して、身元を証明する必要があります。
WebLogic Server では、ユーザが Web ブラウザを使用して HTTP ポート経由でサーバに接続するときにユーザ名とパスワードの認証が行われます。その場合、ブラウザと WebLogic Server のインスタンスは次のように対話してユーザを認証します (図 2-1 を参照)。
WebLogic Server は、Web ブラウザのユーザが HTTPS ポート経由でサーバに接続する場合に暗号化とデジタル証明書の認証を使用します。その場合、ブラウザと WebLogic Server インスタンスは次のように対話してユーザを認証および認可します (図 2-1 を参照)。
注意: Web サーバ プロキシ プラグインとの完全な双方向 SSL ハンドシェークを実施するように WebLogic Server でコンフィグレーションできなくても、プロキシ プラグインは必要に応じてサーバにクライアント証明書を提供するようにコンフィグレーションできます。 そのためには、WebLogic Server への HTTP ヘッダでクライアント証明書をエクスポートするようにプロキシ プラグインをコンフィグレーションします。 WebLogic Server にクライアント証明書をエクスポートするようにプロキシ プラグインをコンフィグレーションする方法については、『WebLogic Server における Web サーバ プラグインの使い方』の特定プラグインのコンフィグレーション情報を参照してください。
デフォルトでは、WebLogic Server はすべての Web アプリケーションに同じクッキー名 (JSESSIONID) を割り当てます。 どの種類の認証を使用する場合でも、同じクッキー名を使用する Web アプリケーションでは、認証用にシングル サインオンを使用します。ユーザが認証されると、その認証は、同じクッキー名を使用するすべての Web アプリケーションへのリクエストに対して有効になります。ユーザは再び認証を要求されることはありません。
Web アプリケーションごとに個別の認証が必要な場合は、Web アプリケーションにユニークなクッキー名またはクッキー パスを指定できます。CookieName パラメータでクッキー名を指定し、CookiePath パラメータでクッキー パスを指定します。これらのパラメータは、<session-descriptor> 要素の WebLogic 固有のデプロイメント記述子 weblogic.xml で定義されています。詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』の「session-descriptor 要素」を参照してください。
クッキー名を保持しつつ Web アプリケーションごとに別々の認証が必要な場合は、Web アプリケーションごとにクッキー パラメータ (CookiePath) を変えることができます。
サービス パック 3 では、セッション データを失うことなく、HTTP を使用して開始されたセッションで HTTPS リソースにユーザが安全にアクセスできるようにする新機能が追加されました。 この新機能を有効にするには、config.xml の WebServer 要素に AuthCookieEnabled="true" を追加します。
<WebServer Name="myserver" AuthCookieEnabled="true"/>
AuthCookieEnabled を true に設定すると、HTTPS 接続を介して認証するときに、WebLogic Server インスタンスはブラウザに新しいセキュアなクッキーを送信します。 一度セキュアなクッキーを設定すると、セッションはクッキーがブラウザから送信された場合しかセキュリティ制約のある他の HTTPS リソースにアクセスできません。
注意: 普通の HTTP で認証する場合、HTTPS リソースでセキュアなクッキーは設定されず、必要ともされません。 保護されていない HTTPS リソースにアクセスする場合、クッキーは検証されません (ブラウザから送信されないため)。 このため、ブラウザはユーザのログインなしで保護されていない HTTPs リソースにアクセスできます。
WebLogic Server は、Web ブラウザに関して以下の 3 タイプの認証をサポートしています。
BASIC 認証の場合、Web ブラウザは WebLogic リソースの要求に応じてログイン画面を表示します。 そのログイン画面は、ユーザ名とパスワードの入力をユーザに要求します。 図 2-2 は典型的なログイン画面です。
BASIC 認証を提供する Web アプリケーションを開発するには、次の手順を行います。
注意: <auth-constraint> タグは、正確に理解し使用してください。そうしないと、必要な保護をアーカイブできません。 <auth-constraint> タグの詳細については、auth-constraintを参照してください。 セキュリティ ロール名を指定する場合、以下の規約と制限に従ってください。
- セキュリティ ロール名の適切な構文は、Web 上 (http://www.w3.org/TR/REC-xml#NT-Nmtoken) で閲覧可能な XML (Extensible Markup Language) 勧告で Nmtoken に関して定義されているとおりです。
- スペース、カンマ、ハイフン、¥t、< >、#、|、&、、?、( )、{ } を使用しないでください。
コード リスト 2-1 BASIC 認証の web.xml ファイル
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>Success</web-resource-name>
<url-pattern>/welcome.jsp</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>webuser</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>default</realm-name>
</login-config>
<security-role>
<role-name>webuser</role-name>
</security-role>
</web-app>
コード リスト 2-2 BASIC 認証の weblogic.xml ファイル
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 7.0//EN"
"http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
<weblogic-web-app>
<security-role-assignment>
<role-name>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>
注意: リスト2-3 において、JSP がログインしたユーザの名前を取得するために API (request.getRemoteUser()) を呼び出していることに留意してください。 代わりに、別の API weblogic.security.Security.getCurrentSubject() を使用することもできます。
Web アプリケーションで FORM 認証を使用する場合は、Web アプリケーション リソースの要求に応じて Web ブラウザが表示するカスタム ログイン画面とログインが失敗した場合に表示されるエラー画面を用意します。ログイン画面は HTML ページ、JSP またはサーブレットを使用して生成できます。 フォームベースのログインのメリットは、これらの画面を完全に管理できるので、アプリケーションまたは会社の方針/ガイドラインの要件にあわせてそれらを設計できることです。
そのログイン画面は、ユーザ名とパスワードの入力をユーザに要求します。 図 2-4 は、JSP を使用して生成される典型的なログイン画面を、リスト2-4 はソース コードを示します。
図2-4 フォームベースのログイン画面 (login.jsp)
コード リスト 2-4 フォームベースのログイン画面のソース コード (login.jsp)
<html>
<head>)
<title>Security WebApp login page</title>
</head>
<body bgcolor="#cccccc">
<blockquote>
<img src=BEA_Button_Final_web.gif align=right>
<h2>Please enter your user name and password:</h2>
<p>
<form method="POST" action="j_security_check">
<table border=1>
<tr>
<td>Username:</td>
<td><input type="text" name="j_username"></td>
</tr>
<tr>
<td>Password:</td>
<td><input type="password" name="j_password"></td>
</tr>
<tr>
<td colspan=2 align=right><input type=submit
value="Submit"></td>
</tr>
</table>
</form>
</blockquote>
</body>
</html>
図 2-5 は、HTML を使用して生成される典型的なログイン エラー画面を、リスト2-5 はソース コードを示します。
<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 アプリケーションを開発するには、次の手順を行います。
注意: <auth-constraint> タグは、正確に理解し使用してください。そうしないと、必要な保護をアーカイブできません。 <auth-constraint> タグの詳細については、auth-constraintを参照してください。 セキュリティ ロール名を指定する場合、以下の規約と制限に従ってください。
- セキュリティ ロール名の適切な構文は、Web 上 (http://www.w3.org/TR/REC-xml#NT-Nmtoken) で閲覧可能な XML (Extensible Markup Language) 勧告で Nmtoken に関して定義されているとおりです。
- スペース、カンマ、ハイフン、¥t、< >、#、|、&、、?、( )、{ } を使用しないでください。
コード リスト 2-6 FORM 認証の web.xml ファイル
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<welcome-file-list>
<welcome-file>welcome.jsp</welcome-file>
</welcome-file-list>
<security-constraint>
<web-resource-collection>
<web-resource-name>AdminPages</web-resource-name>
<description>
These pages are only accessible by authorized
administrators.
</description>
<url-pattern>/admin/edit.jsp</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>
These are the roles who have access.
</description>
<role-name>
admin
</role-name>
</auth-constraint>
<user-data-constraint>
<description>
This is how the user data must be transmitted.
</description>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsp</form-login-page>
<form-error-page>/fail_login.html</form-error-page>
</form-login-config>
</login-config>
<security-role>
<description>
An administrator
</description>
<role-name>
admin
</role-name>
</security-role>
</web-app>
コード リスト 2-7 FORM 認証の weblogic.xml ファイル
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 7.0//EN"
"http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd">
<weblogic-web-app>
<security-role-assignment>
<role-name>admin</role-name>
<principal-name>supportGroup</principal-name>
</security-role-assignment>
</weblogic-web-app>
コード リスト 2-8 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=BEA_Button_Final_web.gif align=right>
<h1> Security Login Example </h1>
<p> Welcome <%= request.getRemoteUser() %>!
<p> If you are an administrator, you can configure the background
color of the Web Application.
<br> <b><a href="admin/edit.jsp">Configure background</a></b>.
<% if (request.getRemoteUser() != null) { %>
<p> Click here to <a href="logout.jsp">logout</a>.
<% } %> </blockquote>
</body>
</html>
注意: リスト2-8 において、JSP がログインしたユーザの名前を取得するために API (request.getRemoteUser()) を呼び出していることに留意してください。 代わりに、別の API weblogic.security.Security.getCurrentSubject() を使用することもできます。
ID アサーションを使用した Web アプリケーションの認証
Web アプリケーションで ID アサーションを使用すると、認証を目的にクライアントの ID を検証できます。 ID アサーションを使用するときには、以下の要件を満たす必要があります。
Web アプリケーションで双方向 SSL を使用すると、クライアントがその主張どおりの存在であることを検証できます。 双方向 SSL を使用するときには、以下の要件を満たす必要があります。
注意: SSL 認証を使用する場合、サーバの SSL コンフィグレーションを Administration Console で指定するので、web.xml および weblogic.xml ファイルを使用してサーバのコンフィグレーションを指定する必要はありません。 サーバの SSL コンフィグレーションの詳細については、『WebLogic Security の管理』の「SSL のコンフィグレーション」を参照してください。
Web ブラウザでは、Swing コンポーネントを使用して開発されたグラフィカル ユーザ インタフェース (GUI) を操作することもできます。 Java Foundation Classes (JFC) の一部である Swing コンポーネントは、JDK 1.1 または Java 2 プラットフォームで使用できます。
Swing コンポーネントを使用してアプリケーションおよびアプレットのグラフィカル ユーザ インタフェース (GUI) を作成する方法については、Sun Microsystems, Inc. 作成の「Creating a GUI with JFC/Swing」チュートリアル (Swing チュートリアルとも呼ばれる) を参照してください。 このチュートリアルは、http://java.sun.com/docs/books/tutorial/uiswing/ でアクセスできます。
Swing ベースの GUI を開発したら、FORM 認証 Web アプリケーションの開発を参照し、Swing ベースの画面を使用して、FORM 認証を提供する Web アプリケーションの開発に必要な手順を実行します。
注意: Swing ベースの GUI を開発する場合、swing イベント スレッドの子スレッドに Java 仮想マシン全体のユーザを使用しないでください。 これは J2EE に準拠していないので、通常はシン クライアントや IIOP では動作しません。 代わりに、以下のいずれかの方法を用います。
開発モードで動作しているサーバに Web アプリケーションをデプロイするには、次の手順を行います。
注意: 開発モードまたはプロダクション モードでの Web アプリケーションのデプロイの詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』の「Web アプリケーションのデプロイメント」を参照してください。
図2-6 Basicauth Web アプリケーションのディレクトリ構造
WL_HOME¥user_projects¥mydomain¥applications¥basicauth
WebLogic Server インスタンスが動作している場合、アプリケーションは自動デプロイされるはずです。Administration Console を使用すると、アプリケーションがデプロイされたことを確認できます。
WebLogic Server インスタンスが動作していない場合は、サーバを起動すると Web アプリケーションは自動デプロイされます。
セキュアな Web アプリケーションのデプロイの詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』の「Web アプリケーションのデプロイメント」を参照してください。
Web アプリケーションに宣言によってセキュリティを実装するには、デプロイメント記述子 (web.xml および weblogic.xml) を使用してセキュリティ要件を定義します。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、サーブレット コンテナがセキュリティ定義を使って、要件を実施します。
デプロイメント記述子を使用した簡単な Web アプリケーションでのセキュリティのコンフィグレーションについては、セキュアな Web アプリケーションの開発を参照してください。
セキュリティ関連のデプロイメント記述子については、Web アプリケーションのセキュリティ関連のデプロイメント記述子を参照してください。
Administration Console を使用して Web アプリケーションのセキュリティをコンフィグレーションする方法については、『WebLogic リソースのセキュリティ』を参照してください。
Web アプリケーションのセキュリティ関連のデプロイメント記述子
以下のトピックでは、Web アプリケーションのセキュリティ要件を定義するために web.xml および weblogic.xml ファイルで使用されるデプロイメント記述子の要素について説明します。
以下の web.xml のセキュリティ関連のデプロイメント記述子の要素は、WebLogic Server でセキュリティ要件を定義するために使用されます。
この節の情報は、Sun Microsystems, Inc. 提供の web.xml の文書型記述子 (DTD) に基づいています。 web.xml の DTD は、http://java.sun.com/dtd/web-app_2_3.dtd にあります。
省略可能な auth-constraint 要素では、このセキュリティ制約で定義された Web リソースの集合にアクセスするグループまたはプリンシパルを定義します。
注意: 認可制約 (<auth-constraint> タグで定義) は、認証の要件を確立し、制約されたリクエストの実行を許可された認証ロール (セキュリティ ロール) を指定します。 <auth-constraint> タグを使用して認可制約を定義する場合は、以下の点に注意してください。
以下の例は、<auth-constraint> タグの使い方を示しています。
<auth-constraint> タグの詳しい使い方については、http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html の Java サーブレット仕様バージョン 2.4 を参照してください。
次の表では、auth-constraint 要素内で定義できる要素について説明します。
|
このセキュリティ制約で定義されたリソースにアクセスできるセキュリティ ロールを定義する。 セキュリティ ロール名は、security-role-ref 要素を使用してプリンシパルにマップされる。security-role-refを参照。 |
auth-constraint 要素は、security-constraint 要素内で使用されます。
例 1 : <auth-constraint> タグなしで <security-constraint> タグを使用する
リスト2-9 は、検証および保護されないリソースを示しています。 この場合、<auth-constraint> タグが使用されないので、リソースは検証および保護されません。 このタイプの保護はすべてが保護される ("/*") 場合は便利ですが、静的なファイルまたは画像への自由なアクセスを許可することも必要です。
コード リスト 2-9 ケース 1 : 検証および保護されないリソース
<security-constraint>
<web-resource-collection>
<web-resource-name>Unchecked-Resource</web-resource-name>
<url-pattern>/foo/*</url-pattern>
</web-resource-collection>
</security-constraint>
例 2 : ロールを指定せずに <auth-constraint> タグを使用する
リスト2-10 では、ロールを指定しない <auth-constraint> タグが使用されています (したがって、リソースには誰もアクセスできない)。 このように <auth-constraint> タグを使用するのは、リソースへのダイレクトなアクセスを避ける場合には便利ですが、forwards、includes、servletContext.getResource()、getResourceAsStream() によるアクセスは許可する必要があります。
注意: このように <auth-constraint> タグを使用する代替手段として、リソースを WEB-INF ディレクトリに配置することもできます。このディレクトリに配置されたリソースへのダイレクトなアクセス リクエストを WebLogic Server は許可しません。
コード リスト 2-10 ロールが指定されない <auth-constraint> タグ
<security-constraint>
<web-resource-collection>
<web-resource-name>Excluded-Resource</web-resource-name>
<url-pattern>/foo/*</url-pattern>
</web-resource-collection>
<auth-constraint>
</auth-constraint>
</security-constraint>
例 3 : ロールを指定して <auth-constraint> タグを使用する
リスト2-11 では、ロールを指定して <auth-constraint> タグが使用されています。 この場合は、リソースが検証および保護され、adminrole ロールのユーザのみアクセスできるようになります。
コード リスト 2-11 ロールが指定された <auth-constraint> タグ
<security-constraint>
<web-resource-collection>
<web-resource-name>Checked-Resource</web-resource-name>
<url-pattern>/blah/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>adminrole</role-name>
</auth-constraint>
</security-constraint>
security-constraint 要素は、web-resource-collection 要素で定義されたリソースの集合へのアクセス特権を定義するために web.xml ファイルで使用されます。
次の表では、security-constraint 要素内で定義できる要素について説明します。
|
このセキュリティ制約が適用される Web アプリケーションのコンポーネントを定義する。 詳細については、web-resource-collectionを参照。 |
||
|
このセキュリティ制約で定義される Web リソースの集合にアクセスするグループまたはプリンシパルを定義する。詳細については、auth-constraintを参照。 |
||
|
クライアントとサーバ間でやり取りされるデータの保護方法を定義する。 詳細については、user-data-constraintを参照。 |
リスト2-12 は、web.xml ファイルで security-constraint 要素を使用して 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 固有のデプロイメント記述子 weblogic.xml で対応するエントリが必要になる。weblogic.xml によって、ロールはセキュリティ レルム内のプリンシパルにマップされる。 詳細については、security-role-assignmentを参照。 |
web.xml ファイルでの security-role 要素の使用例については、リスト2-1 を参照してください。
security-role-ref 要素は、<security-role> で定義されたセキュリティ ロール名を、サーブレットのロジックでハード コード化される代替ロール名にリンクします。 この特別な抽象化レイヤによって、サーブレット コードを変更しなくてもデプロイメント時にサーブレットをコンフィグレーションできるようになります。
次の表では、security-role-ref 要素内で定義できる要素について説明します。
web.xml ファイルでの security-role-ref 要素の使用例については、リスト2-17 を参照してください。
user-data-constraint 要素は、クライアントとサーバ間でやり取りされるデータの保護方法を定義します。
次の表では、user-data-constraint 要素内で定義できる要素について説明します。
|
クライアントとサーバ間でやり取りされるデータのセキュリティ要件を指定する。 注意: INTEGRAL または CONFIDENTIAL の転送保証を使用してユーザが認証を受けた場合、WebLogic Server はセキュア ソケット レイヤ (SSL) 接続を確立する。 |
user-data-constraint 要素は、security-constraint 要素内で使用されます。
web.xml ファイルでの user-data-constraint 要素の使用例については、リスト2-12 を参照してください。
web-resource-collection 要素は、セキュリティ制約を適用する Web アプリケーションのリソースおよび HTTP メソッドのサブセットを識別するために使用されます。 HTTP メソッドが指定されていない場合、セキュリティ制約はすべての HTTP メソッドに適用されます。
次の表では、web-resource-collection 要素内で定義できる要素について説明します。
|
クライアントが Web リソースの集合にアクセスしようとするときにセキュリティ制約を適用する HTTP メソッド。 HTTP メソッドが指定されていない場合、セキュリティ制約はすべての HTTP メソッドに適用される。 |
web-resource-collection 要素は、security-constraint 要素内で使用されます。
web.xml ファイルでの web-resource-collection 要素の使用例については、リスト2-12 を参照してください。
以下の weblogic.xml のセキュリティ関連のデプロイメント記述子の要素は、WebLogic Server のセキュリティ要件を定義するために使用されます。
weblogic.xml デプロイメント記述子の詳細については、http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd にある weblogic.xml の文書型記述子 (DTD) を参照してください。
WebLogic Server 7.0 SP1 以降では、Administration Console で指定するマッピングを、対となる web.xml ファイルの role-name 要素で定義した特定のセキュリティ ロールで使用することを明示的に示すために、global-role 要素を使用します。 この要素は、principal-name 要素の代わりに、プレースホルダとして使用されます。
global-role 要素を使用すると、特定の Web アプリケーションのデプロイメント記述子に定義されたセキュリティ ロールごとに特定のセキュリティ ロール マッピングを指定する必要がなくなります。代わりに、Administration Console を使用して定義済みの各ロールに対する特定のロール マッピングをいつでも指定および変更できます。 さらに、この要素は一部のアプリケーションに対して使用できるので、セキュリティ レルムの [一般] タブの [デプロイメント記述子内のセキュリティ データを無視] 属性を有効にする必要がありません。このため、同じセキュリティ レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、Administration Console を使用して他のアプリケーションのセキュリティを指定および変更できます。
- セキュリティ ロール名の適切な構文は、Web 上 (http://www.w3.org/TR/REC-xml#NT-Nmtoken) で閲覧可能な XML (Extensible Markup Language) 勧告で Nmtoken に関して定義されているとおりです。
- スペース、カンマ、ハイフン、¥t、< >、#、|、&、、?、( )、{ } を使用しないでください。
global-role 要素は、security-role-assignment 要素内で使用されます。
リスト2-13 とリスト2-14 は、weblogic.xml ファイルでの global-role 要素の使い方を比較により示しています。 リスト2-14 では、weblogic-ejb-jar.xml 内の「webuser」の global-role 要素は、セキュリティが getReceipts メソッドにおいて正しくコンフィグレーションされるためには、Administration Console で webuser に対応するプリンシパルが作成される必要があることを意味します。
コード リスト 2-13 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-14 Web アプリケーションのデプロイメント記述子での global-role 要素の使い方
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>
<global-role/>
</security-role-assignment>
Administration Console を使用して Web アプリケーションのセキュリティをコンフィグレーションする方法については、『WebLogic リソースのセキュリティ』を参照してください。
security-permission 要素は、J2EE Sandbox と関連するセキュリティ パーミッションを指定します。
security-permission 要素の使用例については、リスト2-15 を参照してください。
security-permission-spec 要素は、セキュリティ ポリシー ファイル構文に基づいて単一のセキュリティ パーミッションを指定します。 Sun のセキュリティ パーミッション仕様の実装については、次の URL を参照してください。
http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax
注意: オプションの codebase および signedBy 句は無視してください。
security-permission-spec 要素は、security-permission 要素内で使用されます。
リスト2-15 は、security-permission-spec 要素を使用して java.net.SocketPermission クラスにパーミッションを付与する方法を示しています。
コード リスト 2-15 security-permission-spec 要素の例
<weblogic-web-app>
<security-permission>
<description>Optional explanation goes here</description>
<security-permission-spec>
<!-
http://java.sun.com/j2se/1.3/docs/guide/security/PolicyFiles.html#FileSyntax の構文に準拠する、「codebase」句や「signedBy」句を含まない単一の grant 文をここに記述します。次に例を示します。
-->
grant {
permission java.net.SocketPermission "*", "resolve";
};
</security-permission-spec>
</security-permission>
</weblogic-web-app>
リスト2-15 では、permission java.net.SocketPermission はパーミッション クラス名を、"*" は対象名を、resolve (host/IP 名サービスのルックアップを解決する) はアクションを示します。
security-role-assignment 要素は、セキュリティ ロールと WebLogic Server セキュリティ レルムの 1 つまたは複数のプリンシパルとのマッピングを宣言します。
リスト2-16 は、security-role-assignment 要素を使用してプリンシパルを PayrollAdmin ロールに割り当てる方法を示しています。
コード リスト 2-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>
Web アプリケーションでのプログラムによるセキュリティの使用
サーブレットを記述して、そのサーブレット コードでプログラム的にユーザとセキュリティ ロールにアクセスできます。 そのためには、サーブレットのコードで javax.servlet.http.HttpServletRequest.getUserPrincipal および javax.servlet.http.HttpServletRequest.isUserInRole(String role) メソッドを使用します。
getUserPrincipal() メソッドは、Web アプリケーションの現在のユーザを特定する場合に使用します。 このメソッドは、1 ユーザが存在する場合に WLSUser Principal を返します。 WLSUser Principal が複数の場合、メソッドは、Subject.getPrincipals().iterator() メソッドで指定された順序の 1 番目を返します。 WLSUser Principal が存在しない場合、getUserPrincipal() メソッドは WLSGroup Principal 以外の 1 番目を返します。 Principal が存在しない場合、またはすべての Principal が WLSGroup タイプの場合、このメソッドは null を返します。 この動作は、weblogic.security.SubjectUtils.getUserPrincipal() メソッドのセマンティクスとまったく同じです。
getUserPrincipal() メソッドの使い方については、http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Security4.html を参照してください。
javax.servlet.http.HttpServletRequest.isUserInRole(String role) メソッドは、認証済みのユーザに指定された論理的セキュリティ「ロール」が付与されているかどうかを示すブール値を返します。ユーザが認証されていない場合、このメソッドは false を返します。
isUserInRole() メソッドは、セキュリティ ロールをセキュリティ レルムのグループ名にマップします。 リスト2-17 は、対となる web.xml ファイルでセキュリティ ロールを定義するために <servlet> 要素とともに使用される要素を示しています。
コード リスト 2-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> に対応します。
- セキュリティ ロール名の適切な構文は、Web 上 (http://www.w3.org/TR/REC-xml#NT-Nmtoken) で閲覧可能な XML (Extensible Markup Language) 勧告で Nmtoken に関して定義されているとおりです。
- スペース、カンマ、ハイフン、¥t、< >、#、|、&、、?、( )、{ } を使用しないでください。
たとえば、クライアントが manager というセキュリティ ロールの Bill というユーザでログインに成功している場合、次のメソッドは true を返します。
request.isUserInRole("manager")リスト2-18 に例を示します。
コード リスト 2-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 を使用すると、ユーザを認証し、そのユーザをログインさせ、デフォルトの (アクティブな) セキュリティ レルムで登録されるように現行セッションと関連付けるサーブレット コードを記述できます。いったんログインが完了すると、標準のメカニズムを使用してログインしたかのように感じられます。
ServletAuthentication API と一緒に WebLogic が提供する weblogic.security.SimpleCallbackHandler クラスまたは weblogic.security.URLCallbackHandler クラスのうちいずれかを使用できます。 これらのクラスの詳細については、WebLogic クラスに関する Javadoc を参照してください。
リスト2-19 は、SimpleCallbackHandler を使用した例です。 リスト2-20 は、URLCallbackHandler を使用した例です。
コード リスト 2-19 SimpleCallbackHandler クラスを使用したプログラムによる認証コードの一部分
CallbackHandler handler = new SimpleCallbackHandler(username, password);
Subject mySubject = weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
request は httpservletrequest オブジェクト
コード リスト 2-20 URLCallbackHandler クラスを使用したプログラムによる認証コードの一部分
CallbackHandler handler = new URLCallbackHandler(username, password);
Subject mySubject = weblogic.security.services.Authentication.login(handler);
weblogic.servlet.security.ServletAuthentication.runAs(mySubject, request);
request は httpservletrequest オブジェクト
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||