10g（10.1.3.1.0）
B31857-01
 目次 |
 索引 |
| Oracle Containers for J2EE セキュリティ・ガイド 10g（10.1.3.1.0） B31857-01 |
|
この章では、Oracle Access Managerセキュリティ・プロバイダ（旧称Oracle COREid Access and Identity）を認証、認可およびシングル・サインオンに使用する方法について説明します。この章は、Oracle Access Managerシステムのデプロイを行ったユーザーまたは計画しているユーザー向けです。Oracle Access Manager 10.1.4実装とOC4J 10.1.3.1実装の統合、およびOC4JにデプロイされたアプリケーションをOracle Access Managerの機能を介して保護する方法について説明します。これには、Webアプリケーションの詳細な構成手順、およびWebアプリケーション、EJB、Webサービス認証方式（Usernameトークン、X.509トークンおよびSAMLトークンを含む）の例が含まれます。
この章の内容は次のとおりです。
この項では、Oracle Access Managerの概要、前提条件およびアーキテクチャについて説明します。
Oracle Access Managerは、集中的なセキュリティ管理を提供するエンタープライズ・クラスの認証、認可および監査ソリューションであり、様々なアプリケーション・サーバー、レガシー・アプリケーションおよびデータベースにわたる異機種間アプリケーション環境でアクセス制御、シングル・サインオン（Oracle Single Sign-Onとは別）、パーソナライズおよびユーザー・プロファイル管理を行うための機能を備えています。Oracle Access Managerは、アクセス・ポリシーの作成、管理および強制を行う上で重要な機能を提供します。異なるデータ・セットへのアクセスを必要とする複数のユーザー・グループがあり、すべてのユーザー・グループが共通のデータ・セットへのアクセスを必要とする場合は、Oracle Access Managerを使用し、すべてのユーザーが適切なデータにのみアクセスできるように、各グループに正しいアクセス・レベルを許可できます。
Oracle Access Managerを、他の認証、シングル・サインオンおよび認可サービスと比較すると、機能面で次の違いがあります。
OC4J 10.1.3.x実装では、OracleAS JAAS Providerが、カスタム・ログイン・モジュールと特別な認証方式設定を使用して、Oracle Access Managerにおける統合をサポートします。
Oracle Access Managerには、次のコンポーネントがあります。
この項では、Oracle Access Managerを使用する前にインストールしておく必要があるものについて説明します。Oracle Access Managerの各コンポーネントのバージョンは10.1.4です。
上位レベルの前提条件としては、Oracle Access ManagerおよびOracle Application Serverのインストール、OC4J上でのAccess Manager SDKおよび使用アプリケーションの構成があります。
Oracle Access Manager側の詳細な要件は、次のとおりです。
OC4J側の詳細な要件は、次のとおりです。
mod_oc4j Apache modを含む、Oracle Application Server 10.1.3.x中間層のインストール。この中間層は、Oracle Access Manager側にインストールするWebサーバーがOracle HTTP Serverであるかどうかにかかわらず、そのWebサーバーから独立しています。 Oracle Access Managerを使用する場合は、Oracle HTTP Serverが必要です。スタンドアロンのOC4Jは使用できません。
次項の「Oracle Access Managerのアーキテクチャ」では、Oracle Access ManagerコンポーネントとOracle Application Server中間層インフラストラクチャの主要コンポーネントがどのように統合されるかを示します。
図11-1は、Oracle Access Managerのアーキテクチャを示します。
OC4JアプリケーションをOracle Access Managerとともに使用するための構成手順には、次の3つの段階があります。
web.xmlの設定、デプロイ時の設定、orion-application.xmlの設定（デプロイ前またはデプロイ後）およびJAASログイン・モジュールの設定が含まれます。「アプリケーションの構成」を参照してください。この章で後述する構成手順のいくつかでは、Policy Managerの実行が必要になります。次のようなURLを使用して実行し、ログインします。
http://host:port/access/oblix
これにより、この章で頻繁に使用するアクセス・システム・コンソールが表示されます。
この項では、この章で後述する内容に関連するOracle Access Managerのいくつかのコンセプトの背景について説明します。
Oracle Access Managerでは、リソース・タイプを使用して、保護対象のリソースの種類を、関連する操作とともに記述します。リソースに関連付けられる操作は、リソース・タイプの範囲内で決定できます。ポリシー・ドメインにリソースを追加するには、リソース・タイプおよび保護するリソースに関連付けられる操作を先に定義する必要があります。
たとえば、Oracle Access Managerはデフォルトで、HTTPおよびEJBという名前のリソース・タイプをサポートしています。HTTPリソース・タイプに対しては、CONNECT、DELETE、GET、POST、PUTおよびTRACEなどの操作が使用可能です。EJBリソース・タイプに対しては、Beanを実行する操作EXECUTEが使用可能です。カスタム・リソース・タイプに対しては、カスタム操作名を指定できます。
OC4Jは、Access Serverへのセッションを作成するためにAccess Manager SDKを使用します。SDKを使用するには、リソース・タイプおよびリソース操作が指定されている必要があります。このため、Oracle Access Managerログイン・モジュールを構成するときに、次の項目から成るOracle Access Managerリソース・タイプを構成する必要があります。
任意のユーザーを検証するには、Oracle Access Managerを認証方式用に構成する必要があります。認証方式はプラグインで構成されます。
OC4JによるOracle Access Managerのサポートでは、ユーザー資格証明をプロファイルにマッピングするcredential_mappingプラグインが使用され、必要に応じて、ユーザー・パスワードを検証するvalidate_passwordプラグインが使用されます。これらのプラグインは、この章の後出の説明に従って構成する必要があります。
さらに、OC4Jでは、エンドユーザー認証（IDアサーション）とOracle Access Managerを統合する次の2つの方法がサポートされています。
ObSSOCookieの使用。詳細は、次項の「Oracle Access Managerシングル・サインオンCookieの概要」を参照してください。
Oracle Access Managerは、ObSSOCookieという名前の暗号化セッションCookieを使用した、シングル・ドメインおよびマルチ・ドメインのシングル・サインオンを実装します。（これは、使用可能な2つのエンド・ユーザー認証方法の1つです。もう1つの、HTTPヘッダー変数を使用する方法については次の項を参照してください。）WebGateは、認証が成功すると、ユーザーのブラウザにこのCookieを送信します。送信されたCookieは、これ以降、このレベル以下の認証を必要とするその他の保護リソースに対する認証メカニズムとして機能します。
ユーザーがリソースへのアクセスをリクエストすると、リクエストはWebGateからAccess Serverに送信されます。ユーザーが検証されると、ObSSOCookieが設定され、OC4Jに渡されます。このシングル・サインオン機能では、Oracle Access Managerは、認証資格証明の入力を要求するかわりに、Cookieを後続のリクエストに対して使用します。
OC4Jは、ObSSOCookieを使用してAccess Serverに接続し、ユーザー・ロールを取得します。
Oracle Access Managerは、HTTPヘッダー変数を使用した認証をサポートしています。ユーザー名とパスワードがHTTPヘッダーで渡され、エンドユーザーをアサートします。（これは、使用可能な2つのエンドユーザー認証方法の1つです。もう1つのOracle Access Manager ObSSOCookieを使用する方法については、前項を参照してください。）
この方法を使用するには、このユーザー名およびパスワードをOC4JがAccess Serverへのアクセスで使用するように、Oracle Access Managerログイン・モジュールを構成する必要があります（「Oracle Access Managerログイン・モジュールの構成」を参照してください）。
HTTPヘッダー変数およびCookieを使用して、情報を下流のアプリケーションに渡す場合は、HTTPヘッダーのサイズ制限が4Kであることに注意してください。HTTPヘッダーのこのサイズ制限は、すべてのCookie、サーバー変数および環境変数、つまり、HTTPヘッダーのコンテンツの合計に対して適用されます。コンテンツが4Kの制限を超過しなければ、HTTPヘッダーが含むことのできる個々の要素の数には制限はありません。このため、HTTPヘッダーの使用可能な領域を評価する場合には、Oracle Access Managerとその他のアプリケーションで使用するデータのバイト・サイズを考慮に入れます。たとえば、Oracle Access Managerとその他のアプリケーションが、合計1KをHTTPヘッダーで使用する場合は、ユーザーのデータ用に3Kを使用できます。
この項では、Oracle Access Managerのインストール用の一時的な構成について説明します。
シングル・サインオン機能では、Basic認証方式に制限があるため、フォームベース認証方式をリソース保護のために使用する必要があります。（ただし、構成によってはパスワードなしの認証を使用する必要があります。「Oracle Access Manager Basic認証の構成」を参照してください。）
次に示す手順では、WebGateがリソースを保護できるように、Oracle Access Managerのフォームベース認証で使用されるログイン・ページを作成および保護します。後から、このフォームベース認証によって保護されるようにアプリケーションを構成します。
フォームベース認証用のログイン・ページを作成します。このページで設定するパラメータのいくつかに対応して、Polisy Managerおよび関連するプラグインで設定を行います。これについては、必要に応じて説明します。
ログイン・ページを中間層システムのOHS_HOME/document_rootディレクトリ（通常はORACLE_HOME/Apache/Apache/htdocs）の下に置きます。
次に、サンプルのログイン・ページ、login.htmlを示します。このページは、ORACLE_HOME/Apache/Apache/htdocs/loginディレクトリにあるものと想定します。
<html> <head> <title> COREid SSO Login Page</title> <body bgcolor="white"> <h1 align="center">COREid SSO Provider Example : Sign in</h1> <form method="POST" action="/coreid/access/test.html" > <table border="0" cellspacing="5"> <tr> <th align="right">Username:</th> <td align="left"><input type="text" name="usernamevar"></td> </tr> <tr> <th align="right">Password:</th> <td align="left"><input type="password" name="passwordvar"></td> </tr> <tr> <td align="right"><input type="submit" value="Log In"></td> <td align="left"><input type="reset"></td> </tr> </table> </form> </body> </html>
POSTメソッドに対するアクションURLは任意に指定できますが、次の手順でPolicy Managerの認証管理を構成する際に、同じアクションURLを指定する必要があります。
ユーザー名の変数（ここではusernamevar）は、Oracle Access Manager credential_mappingプラグインでの指定内容と一致する必要があります。パスワードの変数（ここではpasswordvar）は、Oracle Access Manager validate_passwordプラグインでの指定内容と一致する必要があります。
この手順では、Policy Managerを使用してフォームベース認証を定義します。Policy Managerで次のようにナビゲートします。
「アクセス・システム・コンソール」→「アクセス・システム構成」→「認証管理」
すべての認証方式をリストし、新しい認証方式がなければそれを追加します。「一般」タブで新しい認証方式を定義するには、次のように入力します。
Name: COREidSSOform Description: COREid SSO Form Based Level: 1 Challenge Method: Form Challenge Parameter: form: /login/login.html creds: usernamevar passwordvar action: /coreid/access/test.html passthrough: No SSL Required: No Challenge Redirect Enabled: Yes
任意の名前と説明を選択できます。ここで選択しているCOREidSSOformおよびCOREid SSO Form Basedは単なる例です。チャレンジ・パラメータには、login/login.htmlがフォームとして指定されています。これは前の手順でログイン・ページを作成したOracle HTTP Serverドキュメント・ルートに対する相対パスです。「チャレンジ・リダイレクト」は空白のままにしておきます。
ここの「creds」には、前の手順のログイン・ページでユーザーおよびパスワード用に指定した変数を指定する必要があります。これらの変数は、フォームベース認証用にcredential_mappingプラグインおよびvalidate_passwordプラグインでそれぞれ使用されるものです。
アクションURL（ここでは/coreid/access/test.html）は任意ですが、ログイン・ページのPOSTメソッドに対するアクションURLと同じものである必要があります。このURLは、この後の「Oracle Access Manager Basic認証の構成」で説明している、Basic（パスワードなし）認証方式で保護します。
次に、Policy Managerでフォームベース認証用にOracle Access Manager credential_mappingプラグインを構成する必要があります。これを使用して、ログイン・フォームを保護します。
次のメニュー・パスで、目的のページにナビゲートします。
「アクセス・システム・コンソール」→「アクセス・システム構成」→「認証管理」
すべての認証方式をリストし、その中からフォームベース方式を選択し、「プラグイン」タブを表示します。
credential_mappingプラグインを、次のような入力内容で変更します。
obMappingBase="cn=users,dc=us,dc=oracle,dc=com",obMappingFilter="(&(& (objectclass=inetorgperson)(uid=%usernamevar%))(|(! (obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))"
uidに入力する値（ここではusernamevar）は、ログイン・フォームのユーザー名に指定した変数、および前の各手順で示した、Policy Managerでのフォームベース認証の定義時に指定した変数と同じものである必要があります。
これは、OC4JにおけるOracle Access Managerログイン・モジュール構成のcoreid.name.attributeオプションの値とも一致します。
次に、Policy Managerでフォームベース認証用にOracle Access Manager validate_passwordプラグインを構成する必要があります。これを使用して、ログイン・フォームを保護します。
前の手順のcredential_mappingプラグインの場合と同じページにナビゲートします。validate_passwordプラグインを、次のような入力内容で変更します。
obCredentialPassword="passwordvar"
obCredentialPasswordに入力する値（ここではpasswordvar）は、ログイン・ページのパスワード変数、および前の各手順で示した、Policy Managerでのフォームベース認証の定義時に指定した変数と同じものである必要があります。
これは、Oracle Access Managerログイン・モジュール構成のcoreid.password.attributeオプションの値とも一致します。
パスワードで保護されない、Oracle Access Manager Basic認証方式を構成する必要があります。（この方式では、credential_mappingプラグインのみを使用し、validate_passwordプラグインは使用しません。）この方式は次の2つのリソースを保護するために使用します。
（ただし、ユーザーのアプリケーション自体は、「Oracle Access Managerフォームベース認証の構成」に従い、フォームベース認証で保護する必要があります。）
次の手順で、パスワードを使用せずにリソースを保護するBasic認証を定義します。
この手順では、Policy Managerを使用してBasic認証を構成します。Policy Managerで次のようにナビゲートします。
「アクセス・システム・コンソール」→「アクセス・システム構成」→「認証管理」
すべての認証方式をリストし、新しい認証方式がなければそれを追加します。「一般」タブで新しい認証方式を定義するには、次のように入力します。
Name: COREidSSONoPwd Description: Authentication without Password Level: 1 Challenge Method: Basic Challenge Parameter: realm:NetPoint Basic Over LDAP SSL Required: No Challenge Redirect Enabled: Yes
任意の名前と説明を選択できます。ここで選択しているCOREidSSONoPwdおよびAuthentication without Passwordは単なる例です。ここで示しているチャレンジ・パラメータのエントリは、ドロップダウン・リストにある選択肢の1つです。「チャレンジ・リダイレクト」は空白のままにしておきます。
次に、Policy ManagerでBasic認証用にOracle Access Manager credential_mappingプラグインを構成します。この構成はリソース保護のためですが、パスワードを使用していません。このため、WebGateが結果を捕捉できます。
次のメニュー・パスで、目的のページにナビゲートします。
「アクセス・システム・コンソール」→「アクセス・システム構成」→「認証管理」
すべての認証方式をリストし、その中からBasic方式を選択し、「プラグイン」タブを表示します。
credential_mappingプラグインを、次のような入力内容で変更します。
obMappingBase="cn=users,dc=us,dc=oracle,dc=com",obMappingFilter="(&(& (objectclass=inetorgperson)(uid=%usernamevar%))(|(! (obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))"
この入力内容は、フォームベース認証用のcredential_mappingプラグイン用のものと同じです。uidに入力する値（ここではusernamevar）は、ログイン・フォームに指定したユーザー名変数usernamevarと同じものである必要があります。
これは、Oracle Access Managerログイン・モジュール構成のcoreid.name.attributeオプションの値とも一致します。
Oracle Access Managerでは、リソース・タイプを使用して、保護対象のリソースの種類を、関連する操作とともに記述します。リソースに関連付けられる操作は、リソース・タイプの範囲内で決定できます。リソースに対してOracle Access Managerリソース・タイプを構成し、リソース・タイプ、アクションURLおよびアプリケーションを保護する必要があります。
リソースに対するリソース・タイプの構成は次の3つの部分に分かれます。いずれもPolicy Managerを介して実行します。
このリソース・タイプ情報は、後述するように、Oracle Access Managerログイン・モジュールで必要になります。OC4Jは、リソース・タイプをAccess Manager SDKのAPIで使用し、Oracle Access Manager ObSSOCookieまたはユーザー名に基づいてユーザー情報を取得します。
これらの構成手順が完了すると、リソースURLが、リソース・タイプに関連付けられ、構成したパスワードなしのBasic認証方式で保護されます。
Policy Managerでリソース・タイプの名前および操作を構成するには、次のようにナビゲートします。
「アクセス・システム・コンソール」→「アクセス・システム構成」→「共通情報の構成」→「リソース・タイプ定義」
すべてのリソース・タイプが表示されたページで、新しいリソース・タイプの追加を選択します。
次のように入力し、新しいリソース・タイプを定義します。
Resource Name: myresourcetype Display Name: My Resource Type Display Name Resource Matching: Case Insensitive Resource Operation: myresourceoperation
リソース・タイプとリソース操作には任意の名前を選択できますが、Oracle Access Managerログイン・モジュールの構成で、coreid.resource.typeおよびcoreid.resource.operationオプションの値として使用した名前と同じものを使用する必要があります。
Policy Managerで構成済リソース・タイプのURLを構成および保護するには、次のようにナビゲートします。
「Policy Manager」→「ポリシー・ドメインの作成」
ポリシー・ドメインに対するリンクを選択します。「リソース」タブで、次のようなエントリを使用します。
Resource Type: myresourcetype Host Identifiers: myhost URL Prefix: /myresourceurl Description: My Description
この構成の保護には、パスワードなしの方式を使用します。「Policy ManagerにおけるBasic認証の定義」で構成したBasic方式を使用します。
ドロップダウン・リストからリソース・タイプ（この例ではmyresourcetype）を選択し、次に適切なホスト名を選択します。
URL接頭辞は/で開始する必要があります。これはリソース・タイプの指定済URLになります。このURL接頭辞は、Oracle Access Managerログイン・モジュール構成のcoreid.resource.nameオプションの値と一致している必要があります。
説明は任意です。My Descriptionは単なる例です。
認証後、OC4Jは、認可をチェックするためユーザーのロールにアクセスする必要があります。これを可能にするには、Oracle Access Managerが正常に認証されたユーザーの適切なロールをOC4Jに戻すための、Oracle Access Managerの戻りアクションを設定する必要があります。
Oracle Access Managerの戻りアクションを設定するには、次のようにナビゲートします。
「Policy Manager」→「ポリシー・ドメイン」→myresourcetypeを選択→「認可ルール」タブ→ロール名を選択→「アクション」タブ
「認可成功」セクション下で、次のエントリを追加（myresourcetypeを使用した前述の例をそのまま使用）します。
Return Type: myresourcetype Return Name: myresourcetype Return Attribute: ObMyGroups
ObMyGroupsは、Oracle Access Managerで定義済のアクション属性であり、認証済ユーザーのすべてのロールを戻すために使用します。
Policy Managerを使用して、「Oracle Access Managerフォームベース認証の構成」で指定したアクションURLを保護します。「構成済リソース・タイプのURLの構成および保護」で説明している、リソース・タイプURLの保護と同じ手順を使用します。
/coreid/access/test.html）。この項では、中間層での各OC4Jインスタンスの構成手順について説明します。
前提条件として、WebGateを中間層のOracle HTTP Serverインスタンスにインストールする必要があります。このOracle HTTP Serverインスタンスにより、複数のOC4Jインスタンスをサポートできます（通常サポートします）。
この項では、次の手順を説明します。
通常、Oracle Access Manager SSOを使用する場合は、トポロジで複数のOC4Jインスタンスが使用されるため、Oracle HTTP Serverインスタンスを、複数のOC4Jインスタンスをルーティングおよび保持するように構成する必要があります。
createinstanceユーティリティによって作成します（『Oracle Containers for J2EE構成および管理ガイド』を参照してください）。
mod_oc4j構成ファイル、ORACLE_HOME/Apache/Apache/conf/mod_oc4j.conf内で構成される必要があります。この構成は、OC4Jインスタンスの作成時に自動的に行われます。
Oracle Access Manager SDKは、OC4Jと同じシステム上に、OC4Jインスタンスごとに1つずつインストールする必要があります。Access Manager SDKは、OC4Jが実行時にAccess Serverと通信するために必要です。OC4Jに対しては、SDK初期化のため、起動時にAccess Manager SDKの場所が指定されている必要があります（この章で後述するように、java.library.pathプロパティを使用します）。この初期化は、最低1つのアプリケーションがOracle Access Managerをセキュリティ・プロバイダとして使用している場合にのみ行われる点に注意してください。また、次の点にも注意してください。
Access_SDK_Home/access/oblix/tools/configureAccessGateディレクトリから、コマンドconfigureAccessGateを実行します。このユーティリティでは、Access Server ID、AccessGate IDおよびその他の関連パラメータが必須です。
jobaccess.jarを、OC4Jのパスにコピーします。このファイルは、Access_SDK_Home/AccessServerSDK/oblix/libディレクトリにあります。ディレクトリORACLE_HOME/j2ee/home/lib/extを（存在しない場合は）作成し、jobaccess.jarをこのディレクトリにコピーします。OC4Jインスタンスが実行時にjava.library.pathプロパティを使用してAccess Manager SDKにアクセスできるように、ORACLE_HOME/opmn/conf/opmn.xmlファイル内でこのプロパティをOC4Jインスタンスごとに構成する必要があります。このプロパティを、SDKの場所を参照するように設定します。
次に、Windowsシステムでの例を示します。
-Djava.library.path=C:¥CoreID¥AccessSDK¥AccessServerSDK¥oblix¥lib
次項の「Oracle Access Managerに対するopmn.xmlの構成」では、この設定をさらに詳しく示します。
OC4JがOPMNによって管理されている状況でOracle Access Managerを使用する場合は、次のようにOracle HTTP ServerおよびOC4Jに関してopmn.xmlに設定を追加します。
home、OC4J_SOAおよびOracle Access Managerを使用するアプリケーションがデプロイされるその他のOC4Jインスタンスで、次の作業を実行します。
LD_ASSUME_KERNEL環境変数を、値2.4.19に設定します。
LD_LIBRARY_PATH環境変数を、AccessServerSDKライブラリ・パスを指すように設定します。
java.library.pathに、AccessServerSDKライブラリ・パスを開始パラメータとして追加します。
OC4Jインスタンスを再起動します。
HTTP_Serverで、LD_ASSUME_KERNELを2.4.19に設定し、Oracle HTTP Serverインスタンスを再起動します。
次に示すのは、OC4J home インスタンス用に設定したopmn.xmlの例です。これらの設定を、OC4J_SOAインスタンスおよび該当するその他のOC4Jインスタンスに対して繰り返します。
<ias-component id="OC4J"> <process-type id="home" module-id="OC4J" status="enabled"> <environment> <variable id="LD_ASSUME_KERNEL" value="2.4.19"/> <variable id="LD_LIBRARY_PATH" value="/your_asdk_home/AccessServerSDK/oblix/lib" append="true"/> </environment> <module-data> <category id="start-parameters"> <data id="java-options" value="-server ... -Djava.library.path=/your_asdk_home/AccessServerSDK/oblix/lib ... /> </category> ... </module-data> ... </process-type> ... </ias-component>
次に示すのはOracle HTTP Serverの例です。
<ias-component id="HTTP_Server"> <process-type id="HTTP_Server" module-id="OHS"> <environment> <variable id="LD_ASSUME_KERNEL" value="2.4.19" /> </environment> ... </process-type> ... </ias-component>
使用するLDAPディレクトリ・サーバー（Oracle Internet Directoryなど）では、OC4JおよびApplication Server Control 10.1.3.x実装で次のアカウントが必要になります。
oc4jadminユーザー
oc4jadminを含んだoc4j-administratorsロール
oc4j-app-administratorsロール
oc4jadminを含んだascontrol_admin（Application Server Controlを含めたすべてのSOAコントロールの管理ロール）
ascontrol_appadmin（Application Server Controlの必須ロール）
ascontrol_monitor（Application Server Controlの必須ロール）
Oracle Internet Directoryを使用する場合は、「Oracle Internet DirectoryとOC4Jの関連付け」で説明されているように、OC4JインスタンスをOracle Internet Directoryインスタンスに関連付けるときにこれらのアカウントが自動的に作成されます。（「Oracle Internet Directoryに作成される必須アカウント」はこの項に含まれています。）
外部のLDAPプロバイダを使用する場合は、「管理ユーザーとロールの作成およびRMIパーミッションの付与」で説明されているように、手動でアカウントを作成する必要があります。
この項では、Webアプリケーションを対象とした次の手順を説明します。
アプリケーション保護の手順1は、標準J2EE機能を使用して、web.xmlファイル内の設定によって目的のURLまたはURL接頭辞を保護することです。
これらは、「Oracle Access ManagerでのアプリケーションURLの保護」で説明した、Oracle Access Manager構成によって保護するURLと同じものです。
Oracle Application Server 10.1.3.x実装では、Application Server ControlがまだOracle Access Managerをセキュリティ・プロバイダとしてサポートしていません。Application Server Controlコンソールを使用してアプリケーションをデプロイする場合は、ファイルベース・プロバイダを選択してください。この設定は、この章で説明している各構成手順でオーバーライドされます。
Oracle Access Manager Single Sign-OnをWebアプリケーションの認証方式として使用するには、OC4Jのorion-application.xmlファイルの<jazn-web-app>要素内で、auth-method属性をCOREIDSSOに設定します。これは、デプロイ前の手順（EARファイルへのパッケージ化）またはデプロイ後の手順として実行できます。
次に、orion-application.xmlにおけるエントリのサンプルを示します。ここでは、<jazn-web-app>は<jazn>要素のサブ要素です。
<orion-application ... > ... <jazn provider="XML" > <jazn-web-app auth-method="COREIDSSO"/> ... </jazn> ... </orion-application>
Policy Managerを使用し、フォームベース認証を介して、ユーザーのアプリケーションのURLまたはURL接頭辞を保護します。これらは、「web.xmlでのアプリケーションURLの保護」で使用したものと同じURLになります。次のようにナビゲートします。
「Policy Manager」→「ポリシー・ドメインの作成」
次に、該当するパブリック・ポリシー・ドメインを選択します。web.xmlで保護した各URLまたはURL接頭辞を、次の手順で保護します。
/fooなど）。
Webアプリケーションに対して、OC4J実装がOracle Access Managerをサポートするには、Oracle提供のログイン・モジュールCoreIDLoginModuleが必要です。次のテンプレートは、system-jazn-data.xmlファイルの一般的な構成を示します。<class>および<control-flag>要素の設定に注意してください。次に示す例に続いて、表11-1で使用可能なオプションについて説明します。個々のシナリオおよびそれぞれの構成のその他の例は、この章で後述します。
<application> <name>yourappname</name> <login-modules> <login-module> <class> oracle.security.jazn.login.module.coreid.CoreIDLoginModule </class> <control-flag>required</control-flag> <options> ... </options> </login-module> </login-modules> </application>
| オプション名 | 必須/オプション | オプションの値 |
|---|---|---|
|
addAllRoles |
必須 |
このフラグを |
|
coreid.resoure.type |
必須 |
関連項目: 「Oracle Access Managerリソース・タイプの概要」および「リソース・タイプの名前および操作の構成」 |
|
coreid.resource.operation |
必須 |
関連項目: 「リソース・タイプの名前および操作の構成」 |
|
coreid.resource.name |
必須 |
|
|
coreid.name.attribute |
必須 |
認証対象ユーザー名の変数。 関連項目: 「Oracle Access Manager認証の概要」および「credential_mappingプラグインのフォームベース認証用構成」 |
|
coreid.password.attribute |
必須（X.509トークンまたはSAML認証を使用する場合を除く） |
|
|
coreid.name.header |
オプション |
HTTPヘッダー変数を認証で使用する場合は、このパラメータが、OC4JがOracle Access Manager Access Serverに対する認証で使用するユーザー名になります。 関連項目: 「HTTPヘッダー変数を使用した認証」および「Oracle Access Managerを介してHTTPヘッダー変数を使用するWebアプリケーション」 |
|
coreid.password.header |
オプション |
HTTPヘッダー変数を認証で使用する場合は、このパラメータが、 |
|
注意
|
次のサンプルは、「Oracle Access Managerフォームベース認証の構成」、「Oracle Access Manager Basic認証の構成」および「リソース・タイプの構成」を通じて出現している例の全体像です。
<application> <name>foo</name> <login-modules> <login-module> <class> oracle.security.jazn.login.module.coreid.CoreIDLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>coreid.resource.type</name> <value>myresourcetype</value> </option> <option> <name>coreid.resource.operation</name> <value>myresourceoperation</value> </option> <option> <name>coreid.resource.name</name> <value>/myresourceurl</value> </option> <option> <name>coreid.name.attribute</name> <value>usernamevar</value> </option> <option> <name>coreid.password.attribute</name> <value>passwordvar</value> </option> </options> </login-module> </login-modules> </application>
（このサンプルでは、coreid.name.headerおよびcoreid.password.headerを除いて、Oracle Access Managerログイン・モジュールがサポートするすべてのオプションが使用されています。使用しないオプションの使用例は、この章で後述します。）
Webアプリケーションのデプロイ、OC4Jの再起動およびOracle HTTP Serverの再起動を行った後で、アプリケーションを実行します。次の例では、Oracle HTTP Serverがポート6666をリスニングすることを想定しています。
http://www.example.com:6666/foo
WebGateは、このリクエストを捕捉し、このURLに対する認証方式をチェックします。この章で前述した構成を使用すると、ユーザーに対し、「ログイン・フォームの作成」で作成したlogin.htmlログイン・フォームが表示され、入力を要求されます。入力後、次のように処理が行われます。
ObSSOCookieを設定し、このCookieおよび他のHTTPヘッダーをmod_oc4jに渡します。mod_oc4jは、リクエストを該当するOC4Jインスタンスにルーティングします。
アプリケーションで権限を必要とするすべてのOracle Access Managerプリンシパルに対し、必要なパーミッションを付与する必要があります。EJPアプリケーションの場合は、EJBアクセスに必要なRMIPermission loginを付与します。
この項の内容は次のとおりです。
EJBアプリケーションにOracle Access Managerを使用する場合は、EJBアクセスに必要なRMIパーミッションloginを、Oracle Access Managerプリンシパルに付与する必要があります。
次の例では、OracleAS JAAS Provider Admintoolを使用して、プリンシパルorcladminに対してこの作業を行っています。
% java -jar jazn.jar -grantperm oracle.security.jazn.realm.CoreIDPrincipal \ orcladmin com.evermind.server.rmi.RMIPermission login
この例を実行すると、system-jazn-data.xmlファイルに次のような構成が生成されます。
<jazn-policy> <grant> <grantee> <principals> <principal> <class>oracle.security.jazn.realm.CoreIDPrincipal</class> <name>orcladmin</name> </principal> </principals> </grantee> ... <permissions> <permission> <class>com.evermind.server.rmi.RMIPermission</class> <name>login</name> </permission> ... </permissions> ... </grant> ... </jazn-policy>
Oracle Access Managerを使用する場合は、認証はOracle Access Manager側で行われますが、JAAS認可はOC4J側で行われます。（その他のレベルの認可は、Oracle Access Manager側で行われます。）アプリケーションでのJAAS認可が正常に行われるためには、認証後にアプリケーション・サブジェクトに移入されるOracle Access Managerプリンシパルに適切なパーミッションを付与する必要があります。これらの権限は、system-jazn-data.xmlファイルに保存する必要があります。
ここでの説明は、プリンシパルBPMSystemAdminがServerPermission serverを必要としていることを想定しています。次の例では、これを行うために、OracleAS JAAS ProviderのAdmintoolを使用しています。
% java -jar jazn.jar -grantperm oracle.security.jazn.realm.CoreIDPrincipal \ BPMSystemAdmin com.collaxa.security.ServerPermission server
この例を実行すると、system-jazn-data.xmlファイルに次のような構成が生成されます。
<jazn-policy> <grant> <grantee> <principals> <principal> <class>oracle.security.jazn.realm.CoreIDPrincipal</class> <name>BPMSystemAdmin</name> </principal> </principals> </grantee> ... <permissions> <permission> <class>com.collaxa.security.ServerPermission</class> <name>server</name> <actions>all</actions> </permission> ... </permissions> ... </grant> ... </jazn-policy>
|
重要
|
次に、BPMSystemAdminロールのサンプルの構成を示します。
<role> <name>BPMSystemAdmin</name> <guid>3E9D3A5037A311DBBFA2B1BC62ED9FBC</guid> <members> <member> <type>user</type> <name>bpeladmin</name> </member> <member> <type>user</type> <name>oc4jadmin</name> </member> </members> </role>
|
注意
|
Oracle Access Managerプリンシパルのパーミッション構成では、構成された各プリンシパル名が、レルム名を含めたプリンシパル名と正確に一致している必要があります。レルム名は、プリンシパルがサブジェクトに移入されるときにOracle Access Managerから取り込まれます。
たとえば、BPMSystemAdminがOracle Access Managerのabcレルムに属している場合は、system-jazn-data.xml内でこのプリンシパル名が次のように指定されている必要があります。
<grantee> <principals> <principal> <class>oracle.security.jazn.realm.CoreIDPrincipal</class> <name>abc/BPMSystemAdmin</name> </principal> </principals> </grantee>
この項では、Oracle Access Managerを使用してApplication Server ControlやOWSMなどのOracle Application Server SOAアプリケーションを保護する際に特に注意する点について説明します。内容は次のとおりです。
Oracle Access Managerで保護されているOracle Application Server SOAアプリケーションのログアウトを正しく機能させるには、次の手順を実行します（Oracle HTTP ServerがPolicy ManagerのWebサーバーであると想定しています）。
logout.htmlであると想定してこの作業を行う場合は、logout.htmlをOracle HTTP ServerのApache/Apache/htdocsディレクトリにコピーします。
/logout.htmlを使用するようにSSOログアウトを構成します。これにより、このURLがログアウトURLとしてPolicy Managerに登録されます。これを行うには、Policy Managerで次のようにナビゲートします。「アクセス・システム・コンソール」→「アクセス・システム構成」→「AccessGate構成」→「WebGate構成。」
LogOutURLsを/logout.htmlに設定します。
jazn.xmlファイルの<jazn>要素で、プロパティcustom.sso.url.logoutを次のようにログアウト・ページのURLを指すように設定します。
<jazn ... > <property name="custom.sso.url.logout" value="/logout.html" /> ... </jazn>
ログイン・ページとログアウト・ページが同じCookieドメインに含まれていること、つまりログインおよびログアウト中に設定されたCookieが、共有ドメインにマップされることも確認してください。
Oracle Application Server SOAアプリケーションにログインしようとして（たとえばOWSMの場合はhttp://www.example.com:7778/ccore/index.htmlを使用して）資格証明を入力した後にフォーム・ログイン・ページでログインがハングした場合は、その原因の1つとしてSOAアプリケーション（OWSMなど）を実行するサーバーとOracle Access Managerを実行するサーバーの間で時刻同期が一致していないことが考えられます。この場合、WebGateはユーザーに対してセッションを作成できません。この問題が発生した場合は、両方のシステムが同期していることを管理者が確認する必要があります。
この項では、次のようにOracle Access Managerを使用したWebアプリケーションおよびEJBについて説明します。
Webアプリケーションは、オプションで、HTTPヘッダー変数を使用して認証を行うように構成できます。ユーザー名用のヘッダー変数は、Oracle Access Managerログイン・モジュール構成のcoreid.name.headerオプションと同じものです。パスワード用のヘッダー変数は、coreid.password.headerオプションと同じものです。
これらのヘッダー変数を使用するには、次の手順を実行する必要があります。
Policy Managerを使用して、credential_mappingおよびvalidate_passwordプラグインを有効化します。
|
関連項目
|
coreid.name.headerおよび（必要に応じて）coreid.password.headerのオプション設定を、system-jazn-data.xmlのOracle Access Managerログイン・モジュール構成に追加します。次の例では、パスワード認証が使用されています。必要なHTTPヘッダー変数は、myhttpuservarおよびmyhttppwdvarであると想定しています。
<options> ... <option> <name>coreid.name.header</name> <value>myhttpuservar</value> </option> <option> <name>coreid.password.header</name> <value>myhttppwdvar</value> </option> ... </options>
標準のWebアプリケーション構成において適切なセキュリティ制約を定義し、orion-application.xml内でauth-method="COREIDSSO"を設定します（「orion-application.xmlにおけるOracle Access Manager SSOの構成」を参照してください）。
HTTPヘッダー変数を指定せずにWebアプリケーションをセキュアにするには、Oracle Access Manager ObSSOCookieを使用して、認証情報を取得します。デフォルトでは、このCookieには、HTTPヘッダーのCookieが格納されます。
このCookieを使用するには、次の手順を実行する必要があります。
coreid.name.attributeおよび（必要に応じて）coreid.password.attributeのオプション設定を、system-jazn-data.xmlのOracle Access Managerログイン・モジュール構成に追加します。次の例では、パスワード認証が使用されています。credential_mappingおよびvalidate_passwordプラグインに対して定義したユーザー名およびパスワード変数が、usernamevarおよびpasswordvarであるものとします。
<options> ... <option> <name>coreid.name.attribute</name> <value>usernamevar</value> </option> <option> <name>coreid.password.attribute</name> <value>passwordvar</value> </option> ... </options>
標準のWebアプリケーション構成において適切なセキュリティ制約を定義し、orion-application.xml内でauth-method="COREIDSSO"を設定します（「orion-application.xmlにおけるOracle Access Manager SSOの構成」を参照してください）。
EJB認証の場合、OC4Jはユーザー名およびパスワードをEJBコンテキストから取得し、Oracle Access Managerログイン・モジュールに渡します。同じユーザー名およびパスワードが、Oracle Access Managerに対する認証でも使用されます。
EJBのシナリオでは、この章で前述したように、credential_mappingプラグインおよびvalidate_passwordプラグインの両方が必要です。プラグインで定義したユーザー名およびパスワード変数は、Oracle Access Managerログイン・モジュールのオプション設定でも使用する必要があります。「Oracle Access Managerフォームベース認証の構成」を参照してください。
クライアントは、EJBにアクセスする前に、認証を受けるためにユーザー名およびパスワードを送信する必要があります。
Oracle Access Managerログイン・モジュールを構成します。Oracle Access Managerの認証変数が次のようになっているものとします。
myejbappnameは、EJBアプリケーションの名前です。
myejbusernamevarは、credential_mappingプラグインで定義した、EJBユーザー名の変数名です。
myejbpwdvarは、validate_passwordプラグインで定義した、EJBユーザーのパスワードの変数名です。
<application> <name>myejbappname</name> <login-modules> <login-module> <class> oracle.security.jazn.login.module.coreid.CoreIDLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>coreid.resource.type</name> <value>myresourcetype</value> </option> <option> <name>coreid.resource.operation</name> <value>myresourceoperation</value> </option> <option> <name>coreid.resource.name</name> <value>/myresourceurl</value> </option> <option> <name>coreid.name.attribute</name> <value>myejbusernamevar</value> </option> <option> <name>coreid.password.attribute</name> <value>myejbpwdvar</value> </option> </options> </login-module> </login-modules> </application>
|
関連項目
|
Webサービスは、Oracle Access ManagerをWebサービス・クライアントの認証に使用できます。OC4Jでは、Oracle Access Managerに対して、次のようにUsernameトークン認証、X.509トークン認証およびSAMLトークン認証がサポートされています。
次の用途について後続の項で説明します。
関連項目
Usernameトークン・クライアントは、ユーザー名およびパスワードを認証に使用します。ユーザー名およびパスワードに対する変数は、Oracle Access Managerのcredential_mappingおよびvalidate_passwordプラグインで、対応するOracle Access Managerログイン・モジュール構成のcoreid.name.attributeおよびcoreid.password.attributeオプションの設定を使用して構成する必要があります。「Oracle Access Managerフォームベース認証の構成」を参照してください。
次の設定を想定して、後述のようにログイン・モジュールを構成します。
UsernameAppNameは、Usernameトークン認証を使用するWebサービス・アプリケーションの名前です。
UsernameNamevarは、credential_mappingプラグインで定義した、ユーザー名の変数名です。
UsernamePwdvarは、validate_passwordプラグインで定義した、ユーザーのパスワードの変数名です。
<application> <name>UsernameAppName</name> <login-modules> <login-module> <class> oracle.security.jazn.login.module.coreid.CoreIDLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>coreid.resource.type</name> <value>myresourcetype</value> </option> <option> <name>coreid.resource.operation</name> <value>myresourceoperation</value> </option> <option> <name>coreid.resource.name</name> <value>/myresourceurl</value> </option> <option> <name>coreid.name.attribute</name> <value>UsernameNamevar</value> </option> <option> <name>coreid.password.attribute</name> <value>UsernamePwdvar</value> </option> </options> </login-module> </login-modules> </application>
|
関連項目
|
X.509クライアントは、X.509エントリのCN値を使用して認証を行います。CNユーザー名に対する変数は、Oracle Access Managerのcredential_mappingプラグインで、対応するOracle Access Managerログイン・モジュール構成のcoreid.name.attributeオプションを使用して構成する必要があります。「Oracle Access Managerフォームベース認証の構成」を参照してください。
X.509トークン認証を使用する場合は、Oracle Access Manager validate_passwordプラグインの構成、またはログイン・モジュールのcoreid.password.attributeオプションの設定は行いません。
次の設定を想定して、後述のようにログイン・モジュールを構成します。
X509AppNameは、X509トークン認証を使用するWebサービス・アプリケーションの名前です。
cn_name_varは、credential_mappingプラグインで定義した、CNユーザー名の変数名です。
<application> <name>X509AppName</name> <login-modules> <login-module> <class> oracle.security.jazn.login.module.coreid.CoreIDLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>coreid.resource.type</name> <value>myresourcetype</value> </option> <option> <name>coreid.resource.operation</name> <value>myresourceoperation</value> </option> <option> <name>coreid.resource.name</name> <value>/myresourceurl</value> </option> <option> <name>coreid.name.attribute</name> <value>cn_name_var</value> </option> </options> </login-module> </login-modules> </application>
|
関連項目
|
SAMLクライアントに対しては、OC4Jがサブジェクト名を決定します。このため、SAMLサブジェクト認証用の変数名を、Oracle Access Manager credential_mappingプラグインで構成しておく必要があります。このcredential_mapping設定は、Oracle Access Managerログイン・モジュール構成のcoreid.name.attributeオプションの設定にも反映される必要があります。「Oracle Access Managerフォームベース認証の構成」を参照してください。OC4Jは、サブジェクト名およびcredential_mapping変数名をOracle Access Managerに渡し、認証を行います。
SAMLトークン認証を使用する場合は、Oracle Access Manager validate_passwordプラグインの構成、またはログイン・モジュールのcoreid.password.attributeオプションの設定は行いません。
次の設定を想定して、後述のようにログイン・モジュールを構成します。
SAMLAppNameは、SAMLトークン認証を使用するWebサービス・アプリケーションの名前です。
subject_name_varは、credential_mappingプラグインで定義した、サブジェクト名の変数名です。
SAMLのシナリオでは、SAMLログイン・モジュールSAMLLoginModuleも使用されます。これはCoreIDLoginModuleログイン・モジュールと一緒に、次の例のように構成する必要があります。この例では、www.example.comを発行者名として使用しています。
<application> <name>SAMLAppName</name> <login-modules> <login-module> <class> oracle.security.jazn.login.module.saml.SAMLLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>issuer.name.1</name> <value>www.example.com</value> </option> </options> </login-module> <login-module> <class> oracle.security.jazn.login.module.coreid.CoreIDLoginModule </class> <control-flag>required</control-flag> <options> <option> <name>addAllRoles</name> <value>true</value> </option> <option> <name>coreid.resource.type</name> <value>myresourcetype</value> </option> <option> <name>coreid.resource.operation</name> <value>myresourceoperation</value> </option> <option> <name>coreid.resource.name</name> <value>/myresourceurl</value> </option> <option> <name>coreid.name.attribute</name> <value>subject_name_var</value> </option> </options> </login-module> </login-modules> </application>
|
関連資料
|
表11-2には、Oracle Access Managerの設定および構成時のトラブルシューティングのヒントをいくつか示しています。
| 問題 | 原因/解決策 |
|---|---|
|
Oracle Access Manager SSOを使用するようにアプリケーションが構成されています。アプリケーションにアクセスしようとすると、Access Serverがクラッシュし、再起動します。 |
Oracle Internet Directoryで不適切な検索ベースを構成しているか、またはグループ名が正しく作成されていません。 |
|
Oracle Access Manager SSOアプリケーションにアクセスしようとすると、Class Not Found例外がスローされます。 |
Oracle Access Managerのファイル |
|
Oracle Access Manager SSOアプリケーションにアクセスしようとすると、内部サーバー・エラーが発生します。 |
OC4JサーバーにインストールされているAccess Manager SDKが、適切なAccess Serverを使用するよう構成されているかどうかを確認します。「各OC4Jインスタンスに対するAccess Manager SDKの構成」を参照してください。OC4Jが実行されているかどうかも確認します。 |
|
Oracle Access Manager SSOアプリケーションにアクセスしようとしても、ログイン・ページが表示されません。 |
Policy Managerを使用して、認証方式を正しい設定で有効にしているかどうかを確認します。「Oracle Access Managerフォームベース認証の構成」を参照してください。 |
|
Oracle Access Manager SSOアプリケーションにアクセスしようとしても、ログイン・ページが続行されません。 |
フォームベース認証方式が有効になっているか、ログイン・ページのフォーム変数名（ユーザーおよびパスワード）がOracle Access Managerのフォームベース認証方式で構成したものと同じであるか、さらに資格証明マッピング・スキームおよびパスワード検証スキームがフォームベース認証方式で構成されているかどうかを確認します。「Oracle Access Managerフォームベース認証の構成」を参照してください。 |
|
Oracle Access Managerを使用するようにアプリケーションを構成したが、常にunauthorizedまたはunauthenticatedエラーが表示されます。 |
|
|
Oracle Access Managerを使用するようにアプリケーションを構成したが、常に内部サーバー・エラーが表示されます。 |
Oracle Access Manager Identity Serverを使用するように構成したLDAPサーバー（たとえばOracle Internet Directory）が実行されていてアクセス可能であるかどうかを確認します。 |
|
Oracle Access Manager SSOを使用するようにアプリケーションを構成したが、ユーザー名およびパスワードを入力してアクセスしようとすると、アプリケーションがハングします。 |
フォーム・ページで使用されているアクションURLが、Basic方式などの、パスワードを使用しない認証方式で保護されているかどうかを確認します。（アクションURLをパスワード保護認証方式で保護すると、実行ループが発生します。）「ログイン・フォームの作成」を参照してください。 |
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|