10g（10.1.3.4.0）
B50832-01
 目次 |
 索引 |
| Oracle Containers for J2EE
セキュリティ・ガイド
10g（10.1.3.4.0） B50832-01 |
|
この章では、Webアプリケーションに影響するセキュリティの問題について説明します。この章の内容は次のとおりです。
関連項目
http://www.oracle.com/technology/tech/java/oc4j/1013/
how_to/index.html
この項では、Webアプリケーションに対して認証方式を指定する構成設定について説明します。内容は次のとおりです。
標準の認証方式をWebアプリケーション・レベルで指定するには、web.xmlの<login-config>要素と、その<auth-method>サブ要素を使用します。次に例を示します。
<web-app ... > ... <login-config> <auth-method>BASIC</auth-method> ... </login-config> ... </web-app>
表17-1は、web.xml内の標準的な<auth-method>の設定を示しています。
|
注意
|
|
関連項目
|
Oracle固有の認証方式をJ2EEアプリケーション・レベルで指定するには、orion-application.xmlで<jazn-web-app>要素とそのauth-method属性を使用します。OC4J 10.1.3.1実装でサポートされている設定は、SSO（Oracle Single Sign-Onの場合）、COREIDSSO（Oracle Access Managerシングル・サインオンの場合）、CUSTOM_AUTH（Java SSOを含めたアイデンティティ管理フレームワークを使用する場合）です。これらの機能の詳細は、「Oracle Application Serverシングル・サインオン代替方法の概要」を参照してください。次に示すのは、Oracle Single Sign-Onの場合の例です。
<orion-application ... > ... <jazn provider="LDAP" > <jazn-web-app auth-method="SSO"/> ... </jazn> ... </orion-application>
|
注意
|
OC4J 10.1.3.1実装のデフォルトの動作として、クライアントからBasic認証ヘッダーが送信された場合でも、Digest認証モジュールではBasic認証が処理されません。（これは、10.1.3.0.0実装のデフォルトの動作とは異なります。）クライアントからBasic認証ヘッダーが送信された場合にBasic認証のフォールバックを有効にするには、次の例のように、orion-application.xmlの<jazn>要素の<property>サブ要素で、digest.auth.basic.fallbackプロパティをtrueに設定します。（このプロパティのロジックは、10.1.3.0.0実装でのロジックの逆であることに注意してください。）
<jazn provider="XML" location="jazn-data.xml"> <property name="digest.auth.basic.fallback" value="true" /> ... </jazn>
Basic認証のフォールバックを使用しない場合は、このプロパティを設定しないか、または明示的にfalseに設定します。
この項では、標準およびOC4J固有のフォームベース認証の特徴について説明します。
FORMの設定には、ログイン・ページおよびエラー・ページのURLを指定する追加構成が、web.xmlの<login-config>要素に必要になります。この機能には、OC4J固有のものはありません。次に例を示します。
<login-config> <auth-method>FORM</auth-method> ... <form-login-config> <form-login-page>mylogin.jsp</form-login-page> <form-error-page>myerror.jsp</form-error-page> </form-login-config> </login-config>
OC4Jは、クライアント・サイド・リダイレクト用のoc4j.formauth.redirectプロパティをサポートしています。このプロパティがtrueに設定されている場合は、OC4J起動時にユーザーがフォームベース認証用に資格証明を入力すると、OC4Jによって適切なクライアント・サイド・リダイレクトが実行され、ブラウザにリスト表示されるリクエストURIが変更されます。このプロパティは、次のように設定されます。
-Doc4j.formauth.redirect=true
デフォルト設定は、falseです。
trueに設定すると、ユーザーがユーザーとパスワードを入力して、資格証明が十分とされてフォームベース認証に成功した時点で、保護リソースの内容が表示され、ブラウザに表示されるリクエストURIが、フォームベース認証を起動したURIと同じになります。（フォームベース認証が失敗した場合は、クライアントは前項の「フォームベース認証の標準構成の設定」で説明された構成で指定されたエラー・ページにリダイレクトされます。）
trueに設定しない場合は、任意のフォームベース認証後に、OC4J固有のj_security_checkリクエストURIがブラウザに表示されます。
例として、次のリソースがフォームベース認証で保護されていると想定します。
http://myhost:8888/testapp/SecureServlet
oc4j.formauth.redirect=trueの設定でフォームベース認証が成功した場合は、保護リソースの内容が表示されるときに、前述のSecureServlet URIがブラウザに表示されます。ただし、trueフラグが設定されていない場合は、ブラウザに表示されるリクエストURIは次のようになります。
http://myhost:8888/testapp/j_security_check
この項では、HTTPSを介してクライアント認証を行うためのOC4Jの構成方法、およびこの認証方式に対するOC4Jのロジック・フローについて説明します。
HTTPSを介したクライアント認証を使用するには、次の手順を実行します。
web.xmlの<auth-method>を、CLIENT-CERTに設定します。「web.xmlでのauth-methodの指定」を参照してください。
orion-application.xmlファイルの<jazn>要素に、OC4J mapping.attributeプロパティを設定します。
jazn.com（jazn.xmlで指定されるデフォルト・レルム）以外のデフォルト・レルムを使用するには、<jazn>要素のdefault-realm属性を介して指定します。
ファイルベース・プロバイダの場合、mapping.attributeのデフォルト値はCNです。Oracle Identity Management（LDAPベース・プロバイダ）または外部LDAPプロバイダの場合、デフォルト値はDNです。次に例を示します。ファイルベース・プロバイダに対してCNを明示的に設定し、デフォルト・レルムも指定しています。
<orion-application ... > ... <jazn provider="XML" ... default-realm="myrealm" ... > <property name="mapping.attribute" value="CN"/> ... </jazn> ... </orion-application>
|
重要
|
次に、OC4JにおけるCLIENT-CERT認証手順を示します。
mapping.attributeの値に従って、OracleAS JAAS Providerは証明書ユーザーの識別名から適切な値を取得します。たとえば、属性の設定がCNの場合、OracleAS JAAS Providerは識別名から一般名を取得します。
jazn-data.xml、LDAPベース・プロバイダの場合はOracle Internet Directoryなど）から、証明書ユーザーを検索します。検索フィルタは、mapping.attributeの設定によって決定されます。たとえば、属性の設定がCNの場合、一般名がユーザー・リポジトリ内の検索フィルタとなります。ただし、正確な動作は、ファイルベース・プロバイダとLDAPベース・プロバイダまたは外部LDAPプロバイダで異なる点に注意してください。たとえば、一般名がjohndoeの場合、それぞれの動作は次のようになります。
Subjectインスタンスに移入します。
この項では、ロール・タイプとロール・タイプ間のマッピング方法について説明します。
J2EEには、移植可能なセキュリティ・ロールの機能が組み込まれています。この機能は、サーブレットとJavaServer Pagesに対して、標準のデプロイメント・ディスクリプタweb.xml内に定義されています。これらのJ2EEロールは、アプリケーションに対する一連のリソース・アクセス権を定義する際に使用されます。たとえば、sr_developersというJ2EEロールをweb.xmlで構成するとします。そのためには、<security-role>要素（トップ・レベルの<web-app>要素のサブ要素）を使用します。
<web-app> ... <security-role> <role-name>sr_developers</role-name> </security-role> ... </web-app>
また、sr_developersロールのアクセス権もweb.xmlで定義します。ロールは、追加の標準ディスクリプタ要素を介して（たとえば、<web-app>のサブ要素でもある<security-constraint>要素下で）、機能および制約に関連付けられます。
<web-app> ... <security-constraint> <web-resource-collection> <web-resource-name>access to the entire application</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <!-- authorization --> <auth-constraint> <role-name>sr_developers</role-name> </auth-constraint> </security-constraint> ... </web-app>
プリンシパルまたはアプリケーション・コードで定義した論理ロールをJ2EEロールに関連付けると、J2EEロールの定義済アクセス権が、そのプリンシパルまたはアプリケーション論理ロールに割り当てられます。この作業はweb.xmlファイルで行うため、ロール定義を変更する際にアプリケーション・コードを更新する必要はありません。アプリケーション・ロールをJ2EEロールにリンクするには、<security-role-ref>要素（<servlet>要素のサブ要素）を使用します。
<web-app> ... <servlet> ... <security-role-ref> <role-name>ar_developers</role-name> <role-link>sr_developers</role-link> </security-role-ref> ... </servlet> ... </web-app>
<role-name>要素は、アプリケーション・コードにおけるロールを意味しています。<role-link>要素は、このアプリケーション・ロール（ar_developers）を、<security-role>要素で定義したJ2EEロール（sr_developers）にリンクすることを指定します。
この例では、sr_developersに属するユーザーとして動作しているサーブレットがHttpServletRequestメソッドisUserInRole("ar_developers")を起動すると、メソッドはtrueを戻します。
デプロイ・ロールおよびユーザーは、使用するセキュリティ・プロバイダで定義されます。たとえばファイルベース・プロバイダの場合、デプロイ・ユーザーおよびロールは、system-jazn-data.xmlファイル（またはオプションとして、ユーザー提供のjazn-data.xmlファイル）で定義されます。
次の例では、developersデプロイ・ロールを構成しています。
<jazn-data> ... <jazn-realm> ... <realm> ... <roles> ... <role> <name>developers</name> <members> <member> <type>user</type> <name>john</name> </member> </members> </role> ... </roles> ... </realm> ... </jazn-realm> ... </jazn-data>
Webコンテナで、そのコンテナが認識していないユーザーへのアクセスを許可しなければならない場合があります。このような場合は、標準のWebアプリケーション・ディスクリプタで<run-as>設定を宣言し、アクセスが許可されるロールを指定できます。
<servlet> ... <run-as> <role-name>sr_developers</role-name> </run-as> ... </servlet>
ロール名は、Webアプリケーションに対してすでに定義されているロールにしてください。Webコンテナは、すべてのコールについて指定されたアイデンティティをサーブレットからEJBレイヤーに伝播する必要があります。
OC4Jを使用すると、web.xmlファイルに定義されているJ2EEロールを、セキュリティ・プロバイダのデプロイ・ロールにマップできます。これは、デプロイ時にApplication Server Controlを介して行います。「Application Server Controlを介したセキュリティ・ロール・マッピングの指定」を参照してください。マッピングは、<security-role-mapping>の設定に反映されます。これは、J2EEアプリケーションの場合はorion-application.xmlファイルに、単一のWebアプリケーションの場合はorion-web.xmlファイルにあります。orion-application.xmlでは、<security-role-mapping>がトップ・レベルの<orion-application>要素のサブ要素となります。同様にorion-web.xmlでは、これがトップ・レベルの<orion-web-app>要素のサブ要素となります。
<security-role-mapping>要素内の<group>サブ要素は、セキュリティ・プロバイダのロールに対応します。
次に示すorion-application.xmlの構成では、J2EEロールsr_developers（web.xmlで定義）がデプロイ・ロールdevelopers（たとえばファイルベース・プロバイダのsystem-jazn-data.xmlで定義）にマップされています。
<orion-application> ... <security-role-mapping name="sr_developers"> <group name="developers" /> </security-role-mapping> ... </orion-appliction>
この関連付けにより、web.xml内でsr_developersロールに対してアクセス可能と構成されているリソースに、developersロールがアクセスできるようになります。
たとえば、developersロールのメンバーであるユーザーjohnについて考えてみます。このロールはJ2EEロールsr_developersにマップされているため、johnは、sr_developersロールからアクセス可能なアプリケーション・リソースにアクセスできます。
|
 Copyright © 2003, 2008 Oracle Corporation. All Rights Reserved. |
|