| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11g リリース1(11.1.1) B56235-06 |
|
 前 |
 次 |
ここでは、Oracle Access Manager 10gを使用したシングル・サインオンの構成について説明します。内容は次のとおりです。
この項の内容は次のとおりです。
この項では、Oracle Access Managerのインストールおよび初期設定の概要と、Oracle Access Manager認証プロバイダのデプロイ時に使用するコンポーネントとファイルのインストール方法の追加情報を示します。
特に明記されていないかぎり、次の各項では、Oracle Access Manager IDアサーション・プロバイダとOracle Access Manager認証プロバイダの要件を両方とも説明します。
この項では、Oracle Access Managerを初めて使用するユーザーのために、インストールと設定の概要を簡潔に説明します。
アクセス・サーバー: Oracle Access Manager認証プロバイダでは、Webゲートまたはアクセス・ゲート用のアクセス・サーバーが2つ必要になります(1つのプライマリ・サーバーと1つのセカンダリ・サーバー)。現時点では、セカンダリ・アクセス・サーバーは1つしかサポートされません。アクセス・サーバーのインストールには、次の手順が含まれます。
アクセス・システム・コンソールで、プライマリ・サーバーのアクセス・サーバー構成プロファイルを追加します。「アクセス管理サービス」が「オン」(ポリシー・マネージャAPIのサポート・モードとも呼ばれます)になっていることを確認します。
「アクセス管理サービス」を「オン」にして、セカンダリ・アクセス・サーバー構成プロファイルを追加します。
プライマリ・アクセス・サーバーのインスタンスをインストールします。
セカンダリ・アクセス・サーバーのインスタンスをインストールします。
Webゲート/アクセス・ゲート: Webゲートまたはアクセス・ゲートのどちらが必要であるかは、使用するOracle Access Manager認証プロバイダによって決まります。次に例を示します。
シングル・サインオン用のIDアサーション・プロバイダ: 境界認証を定義するために、アプリケーションごとに個別のWebゲートと構成プロファイルが必要です。「アクセス管理サービス」が「オン」になっていることを確認します。
認証プロバイダまたはOracle Web Services Manager: アプリケーションごとに個別のアクセス・ゲートと構成プロファイルが必要です。「アクセス管理サービス」が「オン」になっていることを確認します。
OAM 10g Webゲート/アクセス・ゲート・プロファイルとポリシー・ドメインについて
この項では、Webゲート/アクセス・ゲート・プロファイルとポリシー・ドメイン、およびこれらの作成方法について説明します。
Webゲートとアクセス・ゲートには微妙な違いがありますが、多くの場合、これらの用語は同じ意味で使用されます。アクセス・システム・コンソールでは、Webゲートまたはアクセス・ゲートの構成プロファイルがアクセス・ゲート・プロファイルと呼ばれています。ポリシー・マネージャでは、Oracle Access Managerのポリシー・ドメインが作成されます。
アクセス・システム・コンソールを使用する方法: 特定のOracle Access Manager管理者権限を持つユーザーが、Oracle Access Managerで直接情報を入力して、パラメータを設定できます。この方法は、認証プロバイダを使用している場合、またはOracle Web Services ManagerポリシーでWebサービスを保護している場合に必要です。
OAMCfgToolを使用する方法: シングル・サインオン用のIDアサーション・プロバイダを実装するアプリケーション管理者は、OAMCfgToolを使用して新しいWeb層用の新しいWebゲート・プロファイルを作成できます。必須パラメータは、コマンドラインで指定する、環境に適した値を使用してプロビジョニングされます。必須ではないパラメータについては、デフォルト値が受け入れられます。アクセス管理サービスはオンに設定されます。プロファイルを作成したら、アクセス・システム・コンソールで値を変更できます。
各アクセス・ゲート・プロファイルには、次のパラメータが含まれている必要があります。アスタリスク(*)付きのパラメータは、OAMCfgToolを使用してプロビジョニングされます。
*アクセス・ゲート名: 空白を含まない一意の名前。OAMCfgToolツールでは、この名前はapp_domain値から導出され、末尾に_AGが付けられます。
*ホスト名: Webゲートまたはアクセス・ゲートがインストールされている(またはインストールされる)コンピュータの名前。OAMCfgToolでは、ホスト名としてapp_domain値が使用されます。
*アクセス・ゲートのパスワード: コンポーネントを検証および識別するための一意のパスワード。これにより、認可されていないアクセス・ゲートがアクセス・サーバーに接続してポリシー情報を取得する事態を防ぐことができます。OAMCfgToolでは、app_agent_passwordパラメータを使用して指定されます。このパスワードは、Webゲート/アクセス・ゲート・インスタンスごとに異なっている必要があります。
トランスポート・セキュリティ: アクセス・サーバーと関連するWebゲート間のトランスポート・セキュリティ・レベル(これらは一致する必要があります)。デフォルト値はOpenです。OAMCfgToolのoam_aaa_mode値を使用して、別の値を指定できます。
*優先HTTPホスト: ユーザーが保護されたWebサーバーへのアクセスを試みたときに、すべてのHTTPリクエストに表示されるホスト名。ユーザーのHTTPリクエストでどのように定義されたかに関係なく、HTTPリクエストのホスト名は、このフィールドに入力した値に変換されます。OAMCfgToolの優先HTTPホストはapp_domain値です。
優先ホスト機能により、ホストの識別子がホスト識別子リストに含まれていない場合に、セキュリティ・ホールが誤って作成される事態を防ぐことができます。ただし、この機能は仮想Webホスティングには使用できません。仮想ホスティングでは、ホスト識別子機能を使用する必要があります。
*プライマリHTTP Cookieドメイン: WebゲートがデプロイされているWebサーバー・ドメイン。Cookieドメインは、Webサーバー間のシングル・サインオンを有効にするために必要です。各Webサーバーの「プライマリHTTP Cookieドメイン」の値は一致している必要があります。この値を設定するには、OAMCfgToolのcookie_domainパラメータを使用します。
|
関連項目:
|
アクセス・ゲート・プロファイルとポリシー・ドメインの管理要件について
この項では、Oracle Access Managerの新しいWebゲート/アクセス・ゲート・プロファイル、ポリシー・ドメインの作成方法、およびその際に必要な管理権限について説明します。
Oracle Access Managerのマスター・アクセス管理者は、ポリシー・ドメイン・ルートを定義した後、最初のポリシー・ドメインを作成する必要があります。その後、最初のポリシー・ドメインの下にURLのポリシー・ドメインを作成し、それらのポリシー・ドメインの管理を他の管理者に委任できます。
アクセス・システム・コンソールを使用する方法: アクセス・システム・コンソールを使用して新しいアクセス・ゲート・プロファイルを作成し、それをアクセス・サーバーに関連付けて、認証スキームを作成するには、マスター・アクセス管理者または委任アクセス管理者である必要があります。マスター・アクセス管理者または委任アクセス管理者は、ポリシー・マネージャを使用してポリシー・ドメインを作成することもできます。この方法は、次のデプロイメントで必要です。
認証プロバイダ
Oracle Web Services ManagerによってWebサービスが保護されている場合にはIDアサーション・プロバイダ
OAMCfgToolを使用する方法: OAMCfgToolを使用するために、特定のOracle Access Manager管理者権限は必要ありません。OAMCfgToolにより、Webゲート・プロファイルの作成と関連付け、および新しいポリシー・ドメインの作成が自動化されます。ただし、この方法はIDアサーションでのみ使用できます。次のことが可能です。
新規Web層: OAMCfgToolを使用して、IDアサーション・プロバイダ専用の新しいWebゲート・プロファイルとポリシー・ドメインの作成を合理化できます。
OAMCfgToolを使用してプロファイルとポリシー・ドメインを作成した後、アクセス・システム・コンソールでこれらを変更できます。
既存Web層: Web層に1つ以上のWebゲートが存在する場合、新しいWebゲートは必要ありません。ただし、既存のホスト識別子を指定して、既存のWebゲートが新たに確立されたポリシーを実施できるようにすることができます。
|
関連項目:
|
次のタスク概要は、インストールする必要のあるコンポーネントとファイル、および詳細情報の参照先を示しています。
|
注意: コンポーネントがすでにインストールおよび設定されている場合は、新たにコンポーネントをインストールする必要はありません。ご使用のデプロイメントに該当しない手順は省略してください。 |
特に明記されていないかぎり、シングル・サインオン用のIDアサーション・プロバイダまたは認証プロバイダのどちらがデプロイされているか、またはOracle Web Services ManagerポリシーによってWebサービスが保護されているかどうかに関係なく、すべての詳細が適用されます。
タスクの概要: Oracle Access Manager認証プロバイダの必須コンポーネントおよびファイルのインストール
Oracle Access Managerアクセス・サーバーで使用するようにOracle Internet DirectoryまたはOracle Sun One LDAPディレクトリ・サーバーを構成します。ディレクトリ・サーバーがデプロイメント用に調整されていることを確認してください。
|
関連項目: 次のリリース11g (11.1.1.1.0)のマニュアル
|
Oracle WebLogic Server 10.3.1以降をインストールおよび設定します。
|
関連項目: このリストの手順3および『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』 |
オプション: Fusion Middleware製品(Oracle Identity Manager、Oracle SOA Suite、Oracle WebCenterなど)をインストールします。
|
注意: Fusion Middlewareアプリケーションがインストールされていない場合は、以降の手順に従って、必要なJARファイルおよびWARファイルを入手する必要があります。 |
次のFusion Middlewareパスで、必要なJARファイルの場所を確認します。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar
次のパスで、コンソール拡張WARファイルを見つけます。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprov ider.war
WARファイルを、WebLogic Serverホームの次のパスにコピーします。
WL_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war
必要に応じて、Oracle Access Manager 10g(10.1.4.3)のWebゲート用にOHS 11gをインストールします。
認証プロバイダまたはOracle Web Services Manager: カスタム・アクセス・ゲートでは、Webサーバーは必要ありません。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。
Oracle Access Manager IDアサーション・プロバイダ: Oracle HTTP Server 11gのWebサーバーが、Oracle WebLogic Serverのフロントエンドにリバース・プロキシとして構成されている必要があります。
Oracle Access Manager 10g(10.1.4.3)のコンポーネントをインストールし、次の手順に従って初期設定を行います。
アイデンティティ・サーバー、Webパスをインストールして、アイデンティティ・システムを設定します。
ポリシー・マネージャをインストールおよび設定します。ポリシー・マネージャを保護するポリシー(/access)とデフォルト認証スキームが作成および有効化されていることを確認してください。
アクセス・サーバー(Webゲートのプライマリ・サーバーとセカンダリ・サーバーとして1つずつ)をインストールします。
アクセス・システム・コンソールで、Webゲートのプライマリ・サーバーのアクセス・サーバー構成プロファイルを追加します。「アクセス管理サービス」が「オン」(ポリシー・マネージャAPIのサポート・モードとも呼ばれます)になっていることを確認します。
「アクセス管理サービス」を「オン」にして、セカンダリ・アクセス・サーバー構成プロファイルを追加します。
プライマリ・アクセス・サーバーのインスタンスをインストールしてから、セカンダリ・アクセス・サーバーのインスタンスをインストールします。
|
注意: 1つのセカンダリ・アクセス・サーバーのみがサポートされています。 |
シングル・サインオン用のIDアサーション・プロバイダのWebゲート: 1つ以上のWebゲートが存在する既存Web層では、新しいWebゲートまたはプロファイルは必要ありません。
新規Web層では、次の手順に従って、境界認証のWebゲートを定義するためのプロファイルを作成する必要があります。
アクセス・ゲート: 認証プロバイダまたはOracle Web Services Managerを使用する場合は、アクセス・システム・コンソールでカスタム・アクセス・ゲート用の新しいプロファイルを追加する必要があります。
アクセス・システム・コンソールでアクセス・ゲート構成プロファイルを追加し、「アクセス管理サービス」が「オン」になっていることを確認します。
アクセス・ゲート・プロファイルをプライマリおよびセカンダリ・アクセス・サーバーに関連付けます。
oamAuthnProvider.jarに含まれているカスタム・アクセス・ゲートをデプロイします。
それぞれのアプリケーションを保護するプロファイルとアクセス・ゲートがインストールされるまで、手順を繰り返します。
次のようにします。
簡易モードまたは証明書モード: 「Oracle Access Manager証明書のJavaキーストア型式への変換」
認証プロバイダまたはOracle Web Services Manager: Oracle Access Manager認証プロバイダを使用する場合、またはOracle Web Services ManagerポリシーによってWebサービスが保護されている場合は、「Oracle Access Manager 10gでのリソース・タイプの作成」を実行します。
シングル・サインオン用のIDアサーション・プロバイダ: 「Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成」で説明されているタスクを実行します。
すべてのJavaコンポーネントおよびアプリケーションでキーストア形式としてJKSを使用することをお薦めします。この項では、Oracle Access Manager X.509証明書をJavaキーストア(JKS)形式に変換する手順について説明します。この手順に適切に従うことで、Java NAPクライアントがOracle Access Managerアクセス・サーバーと簡易モードまたは証明書モードで通信するときに使用できるJKSストアが生成されます。
簡易モードまたは証明書モードで通信する際、アクセス・サーバーは、次のキー・ファイル、サーバー証明書ファイルおよびCAチェーン・ファイルを使用します。
aaa_key.pem: ルートCAにリクエストを送信するときに証明書生成ユーティリティによって生成されるランダム・キー情報。これは秘密鍵です。WebGateの証明書リクエストでは、証明書リクエスト・ファイルaaa_req.pemが生成されます。このWebGate証明書リクエストを、アクセス・サーバーによって信頼されるルートCAに送信する必要があります。ルートCAは、WebGate証明書を返します。この証明書は、WebGateのインストール中またはインストール後にインストールできます。
aaa_cert.pem: ルートCAによって署名される、アクセス・サーバーに対する実際の証明書。
aaa_chain.pem: ルートCAのパブリック証明書。これは、簡易モードまたは証明書モードで通信するピア同士が、SSLハンドシェイクを実行して、妥当性確認のための証明書を交換するときに使用されます。簡易モードでは、aaa_chain.pemは、AccessServer_install_dir/access/oblix/tools/openssl/simpleCA/cacert.pemにあるOpenSSL証明書です。
ここで、aaaは、ファイルについて指定する名前です(証明書ファイルおよびチェーン・ファイルにのみ適用されます)。
テキスト編集ユーティリティを使用して既存の証明書を編集し、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除できます。次に、編集された証明書をJKS形式に変換し、キーストアにインポートします。Javaキー・ツールでは、すでに保持している証明書に対する既存の秘密鍵をインポートできません。OpenSSLユーティリティを使用して、PEM形式ファイルをDER形式ファイルに変換する必要があります。
Oracle Access Manager証明書をJKS形式に変換してインポートする手順は次のとおりです。
Java 1.6または最新のバージョンをインストールして構成します。
編集する前に次のファイルをコピーして、元のファイルを保持します。
aaa_chain.pem
aaa_cert.pem
cacert.pem(簡易モードで構成する場合のみ)
TextPadを使用してaaa_chain.pemを編集し、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除し、そのファイルを新しい場所に保管して元のファイルを保持します。
-----BEGIN CERTIFICATE----- ... CERTIFICATE ... -----END CERTIFICATE-----
編集されたaaa_chain.pemに対して次のコマンドを実行します。
JDK_HOME\bin\keytool" -import -alias root_ca -file aaa_chain.pem -keystore
rootcerts
ここでは、別名(短縮名)root_caをキーに割り当てています。入力ファイルaaa_chain.pemは、手順3で手動で編集したファイルです。キーストア名は、rootcertsです。
新規作成したキーストアに格納されているキーにアクセスするためのパスワードを指定する必要があります。
|
注意: セキュリティを確保するために、キーツールでパスワードの入力を求めるプロンプトが表示されるようにすることをお薦めします。コマンド・ラインから「-storepass」フラグを省くと、このプロンプトが自動的に表示されます。 |
入力を求められたら、キーストアのパスワードを入力します。例:
Enter keystore password: <keystore_password> Re-enter new keystore password: <keystore_password>
このツールを信用するかどうかを質問されたら、「Yes」と入力します。
Trust this certificate? [no]: yes
次のコマンドを実行してパスワードを入力し、証明書がJKS形式にインポートされていることを確認します。
JDK_HOME\bin\keytool" -list -v -keystore "rootcerts" Enter keystore password: <keystore_password>
次のようなレスポンスを探します。
Keystore type: JKS Keystore provider: SUN Your keystore contains n entries Alias name: root_ca Creation date: April 19, 2009 Entry type: trustedCertEntry Owner: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, O="Oblix, Inc.", L=Cupertino, ST= California , C=US Issuer: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint, O="Oblix, Inc.", L=Cupertino, ST= California ,C=US Serial number: x Valid from: Tue Jul 25 23:33:57 GMT+05:30 2000 until: Sun Jul 25 23:33:57 GMT+05:30 2010 Certificate fingerprints MD5: CE:45:3A:66:53:0F:FD:D6:93:AD:A7:01:F3:C6:3E:BC SHA1: D6:86:9E:83:CF:E7:24:C6:6C:E1:1A:20:28:63:FE:FE:43:7F:68:95 Signature algorithm name: MD5withRSA Version: 1 *******************************************
他のPEMファイルについて、手順3 - 7を繰り返します(チェーンがない場合のaaa_chain.pemを除く)。
アクセス・サーバーのインストール・ディレクトリ・パスでOpenSSLユーティリティを使用して、aaa_key.pemファイルをDER形式に変換します。例:
AccessServer_install_dir\access\oblix\tools\openssl>openssl pkcs8 -topk8
-nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der –outform DER
ここで、入力ファイルはaaa_key.pem、出力ファイルはaaa_key.derです。追加のオプションは次のとおりです。
表17-1 PEMからDER形式ファイルを作成するためのオプション
| オプション | 説明 |
|---|---|
|
-topk8 |
従来の形式の秘密鍵を読み込んで、PKCS#8形式の鍵を書き出します。これにより、デフォルトと逆の状態になります。デフォルトでは、入力でPKCS#8の秘密鍵が要求され、従来の形式の秘密鍵が書き出されます。 |
|
-nocrypt |
出力で暗号化されていないPrivateKeyInfo構造が要求されます。 |
|
-inform |
入力形式を指定します。入力でPKCS#8形式の鍵が要求される場合、DERまたはPEMでエンコードされたバージョンのPKCS#8鍵が要求されます。それ以外の場合、DERまたはPEM形式の従来形式の秘密鍵が使用されます。 |
|
-outform |
出力形式を指定します。出力でPKCS#8形式の鍵が要求される場合、DERまたはPEMでエンコードされたバージョンのPKCS#8鍵が要求されます。それ以外の場合、DERまたはPEM形式の従来形式の秘密鍵が使用されます。 |
簡易モードまたは証明書モード: 簡易モードまたは証明書で構成されている場合、PEMファイル(この場合、aaa_cert.pem)で、Oracle Access Managerアクセス・サーバーに対するパスフレーズを入力します。
Passphrase for the certificate
次のコマンドを実行して、aaa_cert.pemファイルをDER形式に変換します。
AccessServer_install_dir\access\oblix\tools\openssl>openssl x509 -in
aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER
ImportKeyユーティリティを使用して、DER形式ファイルをJavaキーストアにインポートします。例:
Java_install_dir\doc>java -Dkeystore=jkscerts ImportKey aaa_key.der
aaa_cert.der
ウィンドウで結果を確認します。次の例のように表示されます。
Using keystore-file : jkscerts
One certificate, no chain
Key and certificate stored
Alias:importkey Password:your_password
次のようにします。
シングル・サインオン用のIDアサーション・プロバイダ: 「Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成」に移動してください。
認証プロバイダまたはOracle Web Services Manager: 「Oracle Access Manager 10gでのリソース・タイプの作成」の手順を実行してください。
この項では、ポリシー・ドメインで保護するリソース・タイプを識別するリソース・タイプをOracle Access Managerで作成する方法について説明します。このタスクはOracle Access Managerを使用する場合、およびOracle Web Services ManagerのポリシーでWebサービスを保護している場合に必要とされます。
ここで説明するリソース・タイプを定義するには、Oracle Access Managerアクセス・システム・コンソールを使用します。
|
注意: シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを使用している場合、このタスクは省略できます。その場合、デフォルトのhttpリソース・タイプのみが使用されます。 |
Oracle Access Managerでwl_authenリソース・タイプを定義する必要があるのは、次のコンポーネントを使用している場合のみです。
Oracle Access Manager認証プロバイダ
Oracle Web Services Manager用のIDアサーション・プロバイダ
Oracle Access Manager 10gでリソース・タイプを定義するには
アクセス・システム・コンソールに移動して、ログインします。
「アクセス・システム構成」タブを選択して、「共通情報の構成」、「リソース・タイプ定義」をクリックし、「すべてのリソース・タイプをリスト」ページを表示します。
「すべてのリソース・タイプをリスト」ページで、「追加」をクリックし、「新規リソース・タイプの定義」ページを表示します。
次の詳細を指定して、リソース・タイプを定義します。
名前: wl_authen
表示名: wl_authen
リソースの一致: 大/小文字を区別しない
リソース操作: LOGIN
定義したリソース・タイプを保存します。
次のようにします。
認証プロバイダ: 「Oracle Access Manager 10g用の認証プロバイダの構成」
Oracle Web Services Manager: 「Oracle Web Services ManagerおよびOAM 10g用のIDアサーションの構成」
この項では、Oracle Access Manager 10gでの10g Webゲートで保護されたアプリケーションのログアウトの構成について説明します。Oracle Access Manager 10gでは、様々な方法でグローバル・ログアウト(シングル・ログアウト(SLO)ともいいます)を処理できます。この項では、推奨方法について説明します。
|
注意: Oracle Access Manager SSOユーザー・セッションの追跡は、ドメインのCookie、つまりObSSOCookieを使用して実行されます。Webゲートは、ObSSOCookieを検索します。Oracle Access Managerのグローバル・ログアウトまたはSLOは、単にObSSOCookieをクリアすることを意味します。ObSSOCookieがない場合、Webゲートは再認証ワークフローを実施します。 |
ObSSOCookieをクリアする方法の詳細は、次の各項を参照してください。
ログアウトを構成するための推奨方法には、次の2つの手順があります。
Webゲートの構成は、次のもので構成されています。
logout.html: ログアウト・ページは、Webゲートのインストール・ディレクトリ内のWebサーバーで使用可能である必要があります(WebGate_install_dir/oamsso/logout.html)。
ファイルがWebサーバー上の別の場所に格納されている場合には、logout.htmlをロードするためのログアウト・リンクが正しく指定されていることを確認します。例17-1のlogout.htmlを参照してください。この例を参照すると、ニーズに応じてさらにカスタマイズすることができます。
logOutUrls(オプション): このパラメータがすでにWebゲートに対して構成されている場合には、値「/oamsso/logout.html」を既存のリストに追加する必要があります。
Webサーバーの構成: 10g Webゲートが構成されている、Oracle HTTP Server Webサーバーの構成ファイルhttpd.confを確認し、次の行が存在する場合には、それを削除します。
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
OAM 10gデプロイメントで10g Webゲートによって保護されているアプリケーションのログアウト構成に使用されるlogout.htmlを作成する際は、例17-1を使用します。
例17-1 logout.htmlのスクリプト
<html>
<head>
<script language="javascript" type="text/javascript">
function handleLogout() {
//get protocol used at the server (http/https)
var webServerProtocol = window.location.protocol;
//get server host:port
var webServerHostPort = window.location.host;
//get query string present in this URL
var origQueryString = window.location.search.substring(1);
//vars to parse the querystring
var params = new Array();
var par = new Array();
var val;
if (origQueryString != null && origQueryString != "") {
params = origQueryString.split("&");
//search for end_url and redirect the user to this
for (var i=0; i<params.length; i++) {
par = params[i].split("=");
if ("end_url" == par[0]) {
endUrlVal = par[1];
//check if val (value of end_url) begins with "/" or "%2F" (is it an URI?)
if (endUrlVal.substring(0,1) == "/" || endUrlVal.substring(0,1) == "%") {
if (endUrlVal.substring(0,1) == "%")
endUrlVal = "/" + endUrlVal.substring(3);
//modify the end_url value now
endUrlVal = webServerProtocol + "//" + webServerHostPort + endUrlVal;
}
//redirect the user to this URL
window.location.href = endUrlVal;
}
}
}
}
</script>
</head>
<body onLoad="handleLogout();">
<h3>You have been logged out<h3>
</body>
</html>
ログアウト用のアプリケーション構成は、ADFアプリケーションがOPSSと統合されているか統合されていないに応じて異なります。
|
注意: ログアウトの構成は、アプリケーションが1つのDNSドメイン内に存在することが前提となっています。別のDNSドメインにデプロイしたアプリケーション全体にわたってシングル・ログアウト(SLO)する場合には、各Webゲートを処理できるようにログアウト・スクリプトをカスタマイズする必要があります。複数のDNSドメインのデプロイを指定している場合には、Oracle Access Manager Access管理ガイドを参照してください。 |
アプリケーションのログアウトを構成する際には、次のいずれかを実行する必要があります。
非ADFアプリケーションは、ログアウト・リンク(/oamsso/logout.html?end_url=<target uri>)を呼び出すようにコード化されている必要があります。
OPSSと統合されているADFアプリケーションでは、OAM SSOプロバイダのOPSSが構成されている必要があり、アプリケーションではend_urlパラメータを送信する必要があります。
非ADFアプリケーション
非ADFアプリケーションは、ログアウト・リンク(/oamsso/logout.html?end_url=<target uri>)を呼び出すようにコード化されている必要があります。
このアプリケーションは、ログアウトしたユーザーの最終的なリダイレクト先を示すパラメータ(end_url)を渡すことができます。end_urlの一部であるパラメータの値は、URLまたはURIのいずれかです。たとえば、アプリケーションのログアウト・リンクは次のように指定できます。
/oamsso/logout.html?end_url=<someUri>
または
/oamsso/logout.html?end_url=<someUrl>
end_urlの問合せ文字列がURIの場合、logout.htmlがホスティングされるサーバーのhost:portを決定することにより、logout.htmlはURLを構成する必要があります。
ADFコード化アプリケーション
アプリケーションがOPSSと統合されたADFアプリケーションの場合、次の手順に従ってログアウトを構成できます。
ADFコード化アプリケーションの集中管理ログアウトを構成するには
OAM管理者にエージェントで構成されたlogout.htmlスクリプトの場所を確認します。それには、次の手順を実行する必要があります。
OAMのOPSSをSSOプロバイダとして構成し、次のようにWebLogic管理ドメインのjps-config.xmlを更新します。
次のディレクトリ・パスからwlst.sh (Linux)またはwlst.cmd (Windows)を実行します。
WLST_install_dir/middleware/oracle_common/common/bin
WLSのプロンプトで、OAM管理者IDとパスワード、およびWebゲートのホストとポートを入力します
wls:/> /connect("admin_ID", "admin_pw", "hostname:port"
デフォルト・ポート(7001)でローカルホスト上でサーバーが実行している場合、最後のパラメータはオプションです。
ADF認証用のログインURIとログアウトURIを入力します(エージェントによって構成されたlogout.htmlスクリプトの場所)。ホストとポートは必要ありません。
wls:/>addOAMSSOProvider(loginuri="/$<loginuri>",
logouturi="<logouturival>," autologinuri=None")
ここで、logouturivalはログアウト・スクリプト/oamsso/logout.htmlのURIです。logouturlは「logout」で始めるか(logout.gifとlogout.jpgは例外)、OAM管理者によって構成された他の値にできます。
必須: ADFアプリケーションは、ログアウトしたユーザーのリダイレクト先を示すend_urlパラメータを渡す必要があります。ADFアプリケーションの場合、アプリケーションによって次のURIが呼び出されたときにログアウトが開始されます。
/<app context root>/adfAuthentication?logout=true&end_url=<any uri>
アプリケーションにすでにカスタムのログアウトページがあり、いかなる理由でも変更しない場合を除いて、この方法を使用しないようお薦めします。
Webゲートは、文字列「logout.」が含まれているURLへのリクエストをすべてログアウトします。例外: logout.gifやlogout.jpgなどのイメージ・ファイルは例外です。これは、アプリケーションをOAM SLOと統合する最も簡単な方法です。ログアウト・ページが「logout.」で始まっている場合(例: logout.jsp)は、何もする必要はありません。
|
注意: ログアウト・ページが「logout.」で始まっている場合(例: logout.jsp)は、何もする必要はありません。 |
ログアウト・ページが「logout.」で始まっていない場合、ログアウトURLをWebGate LogOutUrlsパラメータに追加する必要があります。例: LogOutUrls = "/myapplication /customscript.jsp"。
この項では、Oracle Access Manager認証プロバイダに関係する共通およびプロバイダ固有のパラメータを列挙します。これらのパラメータは、Oracle WebLogic管理コンソールで指定します。詳細は、次を参照してください:
表17-2 Oracle Access Manager認証プロバイダの共通パラメータ
| パラメータ名 | パラメータの説明 |
|---|---|
|
名前 |
プロバイダの名前。読取り専用。 |
|
説明 |
プロバイダの説明。読取り専用。 |
|
バージョン |
プロバイダのバージョン。読取り専用。 |
|
制御フラグ |
プロバイダJAAS制御フラグ。REQUIRED、REQUISITE、OPTIONALまたはSUFFICIENTの1つを設定します。複数の認証プロバイダを構成する場合、このフラグを使用してログイン・シーケンスでのそれらの使用方法を制御します。「JAAS制御フラグ」を参照してください。 |
|
アクティブ・タイプ |
このパラメータは、Oracle Access Manager IDアサーション・プロバイダにのみ関連しています。このパラメータは、IDアサーション・プロバイダによって処理されるトークン・タイプを決定します。OAM 10gおよび10g Webゲートでは次のように設定します。
|
|
Base64でのデコーディングが必要 |
Falseは読取り専用(デフォルト)。 |
新しいセキュリティ・プロバイダを作成すると、WebLogic Server管理コンソールによって、JAAS制御フラグがOPTIONALに設定されます。すぐに使用できるセキュリティ・プロバイダのデフォルト値はREQUIREDです。制御フラグの詳細は、オンライン・ヘルプを参照してください。
表17-3は、Oracle Access Manager認証プロバイダまたはOracle Web Services ManagerのIDアサーション・プロバイダのプロバイダ固有のパラメータを示しています。
|
注意: OAM 11gでは、アクセス・サーバーはOAMサーバーと呼ばれています。 |
表17-3 プロバイダ固有のパラメータ
| パラメータ名 | パラメータの説明 |
|---|---|
|
トランスポート・セキュリティ |
アクセス・ゲートとアクセス・サーバーの間の通信モード。 |
|
プール内の最小アクセス・サーバー接続数 |
許可される最小接続数。デフォルト値は5です。 |
|
アクセス・ゲートのパスワード |
プロバイダによって使用されるアクセス・ゲートのパスワード。 |
|
キー・ストアのパスフレーズ |
キー・ストアにアクセスするためのパスワード。 |
|
アクセス・ゲート名 |
プロバイダによって使用されるアクセス・ゲートの名前。必須。 |
|
プライマリ・アクセス・サーバー |
プライマリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。必須。「OAM 10g用の認証プロバイダのインストールおよび設定」を参照してください。 |
|
プール内の最大アクセス・サーバー接続数 |
許可される最大接続数。デフォルトは10です。1に設定します。 |
|
簡易モードのパスフレーズ |
簡易通信モードまたは証明書通信モードに対してアクセス・ゲートとアクセス・サーバーによって共有されるパスワード。 |
|
トラスト・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSトラスト・ストアの絶対パス。 |
|
SSOヘッダー名 |
OAM_REMOTE_USER |
|
セカンダリ・アクセス・サーバー |
セカンダリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。「OAM 10g用の認証プロバイダのインストールおよび設定」を参照してください。 |
|
キー・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSキー・ストアの絶対パス。 |
表17-4は、Oracle Access Manager認証プロバイダのプロバイダ固有パラメータを示しています。
表17-4 Oracle Access Manager認証プロバイダのプロバイダ固有のパラメータ
| パラメータ名 | パラメータの説明 |
|---|---|
|
トランスポート・セキュリティ |
アクセス・ゲートとアクセス・サーバーの間の通信モード。 |
|
プール内の最大アクセス・サーバー接続数 |
許可される最大接続数。デフォルトは10です。1に設定します。 |
|
簡易モードのパスフレーズ |
簡易通信モードまたは証明書通信モードに対してアクセス・ゲートとアクセス・サーバーによって共有されるパスワード。 |
|
プール内の最小アクセス・サーバー接続数 |
許可される最小接続数。デフォルト値は5です。 |
|
トラスト・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSトラスト・ストアの絶対パス。 |
|
取得したユーザー名をプリンシパルとして使用する |
Oracle Access Managerから取得したユーザー名をサブジェクトのプリンシパルとして使用するかどうかを指定します。 |
|
アクセス・ゲートのパスワード |
プロバイダによって使用されるアクセス・ゲートのパスワード。 |
|
キー・ストアのパスフレーズ |
キー・ストアにアクセスするためのパスワード。 |
|
アクセス・ゲート名 |
プロバイダによって使用されるアクセス・ゲートの名前。必須。 |
|
セカンダリ・アクセス・サーバー |
セカンダリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。次の各項を参照してください。 |
|
キー・ストア |
プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSキー・ストアの絶対パス。 |
|
プライマリ・アクセス・サーバー |
プライマリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。必須。次の各項を参照してください。 |
この項では、OAMCfgToolについて説明します。このツールは、シングル・サインオンに使用されるOracle Access Manager 10g IDアサーション・プロバイダをデプロイしている場合にのみ使用できます。
OAMCfgToolは、一連のスクリプトを起動して情報をリクエストし、必要なプロファイルとポリシーをOracle Access Manager 10gに設定します。OAMCfgToolは、次のモードで実行されます。
CREATEモード
java -jar oamcfgtool.jar mode=CREATE param=value
VALIDATEモード
java -jar oamcfgtool.jar mode=VALIDATE param=value
DELETEモード
java -jar oamcfgtool.jar mode=DELETE param=value
LDIF出力ファイルを指定していない場合は、Oracle Access Managerを使用して構成されたDAPディレクトリ・サーバーに、構成の変更が直接書き込まれます。また、LDIFファイルがなければ、OAMアクセス・サーバーのキャッシュも構成の変更によって更新されます。
|
注意: 構成の変更がLDIFファイルに書き込まれる場合は、後からOracle Access Managerのディレクトリ・サーバーに構成の変更をロードすることができます。 |
ログ・レベルとログ詳細の出力ファイルも指定できます。OAMCfgToolの実行中にエラーが発生した場合は、コマンドラインでエラーが報告されます。
パスワード
OAMCfgTool では、LDAPユーザー、アプリケーション・エージェント、OAMモードおよびテスト・ユーザーの4つのパスワードが受け入れられます。
パラメータ-nopromptがない場合、OAMCfgToolはまずコマンドラインからパスワードをフェッチしようとします。パスワードが見つからない場合は、OAMCfgToolが一時停止し、コマンドラインにパスワードを入力するように要求します。
しかし、-nopromptパラメータが指定されている場合、OAMCfgToolはコマンドラインから渡されたパスワードをチェックします。
コマンドラインからパスワードが渡されなかった場合、OAMCfgToolはSystem.inから渡されたパスワードをチェックします。
System.inからパスワードが渡されない場合、OAMCfgToolは、必須のパスワードが提示されなかったことを示す例外を生成して実行を停止します。
パスワードは、echoコマンドを使用し、セパレータにはセミコロンを使用してシェルから渡すことができます。たとえば、次のように入力します。
4つのパスワードのすべてを指定する入力は次のとおりです。
$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) | java -jar oamcfgtool.jar <args> -noprompt
ldapUsrPwdとappAgentPwdのみを指定する入力は次のとおりです。
$ (echo ldapUserPwd; echo appAgentPwd) | java -jar oamcfgtool.jar <args> -noprompt
appAgentPwdのみを指定する入力は次のとおりです。
$ (echo; echo appAgentPwd) | java -jar oamcfgtool.jar <args> -noprompt
詳細は、「OAMCfgToolのパラメータと値」を参照してください。
この項では、環境に適した各種パラメータと値を指定してOAMCfgToolを使用する場合の処理について説明します。
この項では、OAM 10g用のOAMCfgToolの使用を中心に説明します。OAM 11gを使用している場合には、この項を省略して、第16章「Oracle Access Manager 11gを使用したシングル・サインオンの構成」を参照してください。
プロセスの概要: OAMCfgToolによる認証スキーム、ポリシー・ドメインおよびWebゲート・プロファイルの作成
app_domainパラメータは、ポリシー・マネージャのポリシー・ドメインを作成することでアプリケーション認証を可能にします。
web_domainパラメータは、リクエストの送信元であるWebゲート・ホストを送信先のアプリケーションに接続したり、ポリシーを既存Webゲートにリンクするホスト識別子を作成します。
protected_urisパラメータは、ホスト識別子を使用して、HTTPリソースを保護するためのアプリケーション固有のURLを定義します。
public_urisパラメータは、匿名認証スキームを使用して特定のURIのapp_domain名のhttpリソース(GETおよびPOST操作)を保護するポリシーを作成します。
LDAPパラメータではディレクトリ・サーバーが指定されます。Oracle Access Managerはこのサーバーを使用してすべてのLDAP問合せが実行される検索ベースを特定します。詳細は、表17-5を参照してください。
log fileおよびlog levelパラメータは、OAMCfgToolの出力ファイルとログ・レベルを指定します。
output_ldif_fileパラメータは、LDIFファイルの名前を定義します。ここで作成したLDIFファイルは、ユーザーの指定に応じて後でディレクトリ・サーバーにロードできます。このファイルを使用しない場合、構成変更はディレクトリ・サーバーに書き込まれます。
内容は次のとおりです。
表17-5は、OAMCfgToolのCREATEモードにおける必須パラメータとオプション・パラメータ、および値を示しています。パラメータは、一度に複数個指定できます。
表17-5 OAMCfgToolのCREATEモードでのパラメータと値
| パラメータ | CREATEモードの値 |
|---|---|
|
必須パラメータ |
必須パラメータの値 |
|
app_domain |
アプリケーションを保護するOracle Access Managerポリシー・ドメインの名前。ポリシー・マネージャ内では、ポリシー・ドメイン名と呼ばれています。 |
|
protected_uris |
保護されるアプリケーションのURIのカンマ区切りリスト(空白あり/なし)(例: /myapp/login)。 この表のパラメータuris_fileも参照してください。 |
|
uris_file |
任意の数の保護付きURIまたは公開URIが保存されたファイルへのフルパスで、パラメータprotected_urisまたはpublic_urisを使用する必要をなくします。このファイルでは次の構文および形式が使用されていることを確認します。 --少なくとも1つの保護付きURIが必要です。 --1つのファイルにつき1つの製品ファミリのみが許可されます。 --コメントは「#」で始まります。 --キーワード: public_uris。このキーワードの後に個別の行に公開URIをリストします。 --キーワード: protected_uris。このキーワードの後に個別の行に保護付きURIをリストします。 たとえば、次のようになります。 ######################## #Finance ######################## . ######################## protected_uris ######################## /finance/protected/test1 /finance/protected/test2 ######################## public_uris ######################## /finance/public /finance/protected/test1/public |
|
app_agent_password |
Webゲートに対してプロビジョニングされるパスワード。10gアクセス・システム・コンソール内のアクセス・ゲート・プロファイルでは、このパラメータがアクセス・ゲート・パスワードと呼ばれています。入力したパスワードは、コマンドラインにクリアテキストで表示されますが、ログ・ファイルには記録されません。 注意: Webゲート・プロファイルを作成しない場合、このパラメータは必要ありません。この表の後続部分にある |
|
ldap_host |
Oracle Access ManagerのLDAPディレクトリ・サーバーをホストするコンピュータのDNS名。これはOAMポリシー・データが格納されるディレクトリ・サーバーです。 注意: ディレクトリ・サーバーとのSSL対応通信はサポートされていません。 |
|
ldap_port |
LDAPディレクトリ・サーバーのポート。 |
|
ldap_userdn |
引用符で囲んだ文字列として入力されている、LDAP管理ユーザーの有効なDN。Oracle Access Managerでは、ルートDNまたはバインドDNと呼ばれています。 |
|
ldap_userpassword |
LDAP管理ユーザーのパスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。この表の後続部分にある「-noprompt」を参照してください。 この表の後続部分にある |
|
oam_aaa_host |
アクセス可能なアクセス・サーバーをホスティングしているコンピュータのDNS名。 必要に応じてディレクトリ・サーバーを変更すると、キャッシュ・フラッシュ・リクエストがこのアクセス・サーバーに送信され、アクセス・サーバーのキャッシュが適宜リフレッシュされます。 「primary_oam_servers」パラメータが指定されていない場合、作成中のWebゲート・プロファイルではoam_aaa_hostの指定に含まれるアクセス・サーバーがプライマリ・アクセス・サーバーとして使用されるように構成されます。デフォルトの接続数は1です。 この表の後続部分にあるprimary_oam_serversおよびsecondary_oam_serversも参照してください。 |
|
oam_aaa_port |
アクセス可能なアクセス・サーバーのリスニング・ポート。 |
|
オプション・パラメータ |
オプション・パラメータの値 |
|
help |
パラメータと説明のリストを提供します。 |
|
version |
OAMCfgToolのバージョンをリストします。 |
|
web_domain |
主にホスト識別子の指定に使用されます。 注意: OAMCfgToolは、次の2つのシナリオに示すように、ホスト識別子とWebゲート・プロファイルをまとめて作成するか、いずれも作成しません。 新規Web層の作成: パラメータ「web_domain」(「web_domain」の指定がない場合は「app_domain」)によって指定されたホスト識別子がOAMに存在しない場合は、OAMに次のものが作成されます。
仮想ホストの構成については、この表のパラメータhostname_variationsを参照してください。 既存Web層の使用(Webドメインの結合): 「web_domain」(「web_domain」がない場合は「app_domain」)の一部として指定されたホスト識別子がOAMに存在する場合は次のようになります。
注意: 新規Web層で作成されたホスト識別子は、使用中のポリシー・ドメインで使用されます。 仮想Webホスティングがサポートされる場合は、「ホスト名のバリエーション」ではなく、「優先HTTPホスト」フィールドに予約名を入力します。 この表のhostname_variationsパラメータおよび『Oracle Access Managerアクセス管理ガイド』を参照してください。 |
|
cookie_domain |
ObSSOCookieに使用するドメインの名前。アクセス・システム・コンソールのアクセス・ゲート・プロファイル内では、プライマリHTTP Cookieドメインと呼ばれています。 このパラメータは、新規Web層に新しいWebゲート・プロファイルを作成するときに使用します。 |
|
public_uris |
匿名認証スキームを使用して非保護にする必要があるURI。公開URIは、たとえば「uri1,uri2,uri3」などのカンマ区切りリストを指定することによって識別できます。 この表のパラメータuris_fileも参照してください。 |
|
ldap_base |
すべてのLDAP検索が実行されるベース。 |
|
oam_aaa_mode |
アクセス可能なAccess Serverのトランスポート・セキュリティ・モード。OPEN、SIMPLEまたはCERTを指定します。デフォルト値はOPENです。 |
|
oam_aaa_passphrase |
SIMPLEトランスポート・セキュリティ・モード専用のパスフレーズ。パスフレーズはクリアテキストで表示されますが、ログ・ファイルには記録されません。 「パスワード」の説明も参照してください。 |
|
log_file |
OAMCfgToolログ・ファイルの名前。デフォルトでは、画面出力されます。 |
|
log_level |
OAMCfgToolのロギングのレベル: ALL、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、OFF。 デフォルト= WARNING |
|
output_ldif_file |
OAMCfgTool操作の詳細が格納されるLDIFファイルの名前。このファイルは、後でLDAPディレクトリ・サーバーにロードされます。何も指定しない場合、変更は即時にLDAPディレクトリ・サーバーに書き込まれ、Oracle Access Managerのキャッシュがフラッシュされて新しい情報が使用可能になります。 |
|
noprompt |
OAMCfgToolによるパスワード・プロンプトを無効化して、次のパスワード・チェックを有効化します。
|
|
authenticating_wg_url |
認証Webゲートのホストおよびポートが含まれるURI(認証WebゲートとリソースWebゲートの両方がある場合)。例:
このパラメータによって、次の両認証スキームの「チャレンジ・リダイレクト・パラメータ」が構成されます。
注意: 「チャレンジ・リダイレクト」パラメータは、認証スキームの作成時に追加されます。既存の認証スキームの「チャレンジ・リダイレクト」パラメータは更新されません。 |
|
configOIMPwdPolicy |
Oracle Access Managerとの統合を自動化するOracle Identity Manager (OIM)パスワード・ポリシーを作成します。また、このポリシーで使用される当該の認証スキームで、パスワードをチェックするポリシーが有効化されます。 「OIM統合関連パラメータと値」も参照してください。 |
|
OimOhsHostPort |
Oracle Identity Manager (OIM)をOracle Access Managerを統合し、認証WebゲートとリソースWebゲートを統合する場合に必要です。 「OIM統合関連パラメータと値」も参照してください。 認証Webゲートがない場合は必要ではありません。この場合はOracle Identity Manager (OIM)パスワード・ポリシー(OraOIMDefPasswdPolicy)によって、Oracle Access Managerとの統合が自動化され、ポリシーで使用される当該認証スキームで、パスワードをチェックするポリシーが有効化されます。デフォルト値は付加されているOimOhsHostPortに値があるパスワード・ポリシー関連パラメータで使用されます。例: -OimLostPwdRedirectUrl (Lost Password Redirect URL): <OimOHSHostPort>/admin/faces/pages/forgotpwd.jspx -OimPwdRedirectUrl (Password Change Redirect URL): <OimOHSHostPort>/admin/faces/pages/pwdmgmt.jspx?backUrl=%RESOURCE% -OimLockoutRedirectUrl (Account Lockout Redirect URL): <OimOHSHostPort>/ApplicationLockoutURI OimOhsHostPortパラメータは、-configOimPwdPolicyフラグが存在する場合にのみ使用されます。 「OIM統合関連パラメータと値」も参照してください。 |
|
logouturi |
ログアウトに使用されるPerlスクリプトが構成されている認証Webゲート上のURLの場所を指定することによって、リソースWebゲート上のLogoutRedirectUrlの構成が容易になります。 logouturiパラメータの値はURIであることが要求されます。WebゲートLogoutRedirectUrlパラメータは、authenticating_wg_url and logouturiパラメータを使用して構成されます。 http://<awghost>:<awgport>/cgi-bin/logout.pl LogoutRedirectUrl http://myhost.us.myco.com:7777/cgi-bin/logout.pl. 注意: 認証WEBゲート上では、LogoutRedirectUrlパラメータを構成しないでください。認証WebゲートのLogoutRedirectUrlは、空白にしておきます。 次のサンプルは、アプリケーション・ドメインを作成し、新規Webゲートのプロビジョニングの際にログアウトURIを構成します。 $ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) java -jar oamcfgtool.jar app_domain=app_domain protected_uris="/protUri" ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager" oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_ base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_ url=http://myhost.us.myco.com:7777 -logouturi=/cgi-bin/logout.pl -noprompt 注意: 既存のWebゲートを使用する場合は、次に説明するようにwebgate_idパラメータを使用します。 |
|
webgate_id |
既存で、「LogoutRedirectUrl」が未構成のWebゲートの名前を指定します。 注意: Webゲート・プロファイルは、対応するホスト識別子がOracle Access Managerにまだ存在していない場合にのみ作成されます。また、次の条件も適用されます。
次に、webgate_idを使用したサンプル・コマンドを示します。 $ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) java -jar oamcfgtool.jar app_domain=myapp webgate_id=MyWebgate protected_uris="/protUri" ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager" oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_ base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_ url=http://myhost.us.myco.com:7777 -logouturi=/cgi-bin/logout.pl -noprompt |
|
hostname_variations |
Oracle Access Managerのホスト識別子のホスト名のバリエーション・セクションへの値の追加を可能にします。 ApacheベースのWebサーバー(OHSを含む)の仮想ホストを構成する場合は、このパラメータを次のように組み込みます。 java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ... hostname_variations=vhost1,vhost2 注意:
非ApacheベースのWebサーバーの仮想ホストを構成する場合は、パラメータpreferred_http_hostを次に説明するように組み込みます。 |
|
preferred_http_host |
Webゲート・プロファイルの優先HTTPホスト・フィールドを構成可能にします。 非ApacheベースのWebサーバーの仮想ホストを構成する場合は、次のようにHOST_HTTP_HEADERの値でこのパラメータを組み込みます。 java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ... hostname_variations=vhost1,vhost2 preferred_http_host=HOST_HTTP_HEADER パラメータ java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ... hostname_variations=hostname1,hostname2 preferred_http_host=SOME_ HOSTNAME_VARIATION_VALUE 仮想環境の注意が適用されます。また、Webゲート・プロファイルを作成している場合、このプロファイルの優先HTTPフィールドの値には、ホスト名のバリエーションの値から任意の値を設定できます。 一般に、非仮想ホスト環境でホスト識別子を作成する場合、追加のホスト名のバリエーションは必要ありません。OAMCfgToolによってWebゲート・プロファイルの優先HTTPホスト・フィールド、および作成しているホスト識別子のホスト名のバリエーション・セクションにデフォルト値が追加されます。 |
|
default_authn_scheme |
ポリシー・ドメインのデフォルトの認証スキームを構成します。認証スキーム名はアクセス・システム・コンソールでの表示どおりに渡す必要があります。 OAMCfgToolは、常に次の認証スキームのプロビジョニングを行います。
新規のデプロイメントでのツールの初回実行時に上記リストのスキームが作成されます。 パラメータ「default_authn_scheme」の一部として指定された認証スキームを使用して、構成しているポリシー・ドメインのデフォルト認証ルール・セクションが構成されます。 OAMのURIファイルを使用して、ポリシー・ドメインの保護付きポリシーの認証スキームを構成できます。保護付きポリシーはキーワード「protected_uris」の以降に指定されているポリシーです。URIファイルの認証スキーム名は次の形式で渡す必要があります(ポリシー名と認証スキーム名はタブ文字で区切る必要があります)。 <ポリシー名> 'タブ' <認証スキーム名> URIファイルのエントリの例は次のとおりです(詳細は、この表で前出のパラメータuris_fileを参照してください)。
#-----------------------------------------------------
protected_uris
protected policy1 Basic Over LDAP
/protected1 public1/mystuff.html
protected policy2 OraDefaultFormAuthNScheme
/protected2/public2/prot2 /.../{*.js,*.png,*.gif}
protected policy3 Client Certificate
/protected2/public2/prot2/.../{*.js,*.png,*.gif}
#------------------------------------------------------
URIファイルの上記のエントリによって、次の名前付きポリシーが生成されます。
|
|
max_oam_connections |
作成しているWebゲート・プロファイルに接続の最大数(「最大接続数」)を指定することによって、高可用性および複数のアクセス・サーバーの使用をサポートします。 |
|
primary_oam_servers |
作成しているWebゲート・プロファイルに複数のプライマリ・アクセス・サーバーを構成することによって、高可用性および複数のアクセス・サーバーの使用をサポートします。このパラメータの形式は次のとおりです。
注意:
|
|
secondary_oam_servers |
作成しているWebゲート・プロファイルに複数のセカンダリ・アクセス・サーバーを構成することによって、高可用性および複数のアクセス・サーバーの使用をサポートします。このパラメータの形式は次のとおりです。
注意:
|
表17-6は、OAMCfgToolのOIM統合関連パラメータと値を示しています。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のOracle Access Manager 10gとOracle Identity Manager 11gとの統合に関する項も参照してください。 |
表17-6 OIM統合関連の追加パラメータと値
| パラメータ | 説明 |
|---|---|
|
configOIMPwdPolicy |
Oracle Access Managerとの統合を自動化するOracle Identity Manager (OIM)パスワード・ポリシー(OraOIMDefPasswdPolicy)を作成します。また、このポリシーで使用される当該の認証スキームで、パスワードをチェックするポリシーが有効化されます。 たとえば、このポリシーをデフォルトの認証スキーム(OraDefaultFormAuthnScheme)で使用する場合、スキームの「Validate_Password」プラグインが更新され'obReadPasswdMode="LDAP",obWritePasswdMode="LDAP"'が組み込まれます。 注意: アイデンティティ・システム・コンソールのパスワード関連パラメータにはデフォルト値にOimOhsHostPortで指定された値を付加して使用します。 configOIMPwdPolicyを使用する場合は、これまでにこのツールを使用して作成されたデフォルトのOIMパスワード・ポリシーがないこと、および次のパラメータのいずれも渡さないことを確認します。 configOIMPwdPolicyを使用する場合は、これまでにこのツールを使用して作成されたデフォルトのOIMパスワード・ポリシーがないこと、および次のパラメータのいずれも渡さないことを確認します。 |
|
OimOhsHostPort |
Oracle Identity Manager (OIM)をOracle Access Managerを統合し、認証WebゲートとリソースWebゲートを統合する場合に必要です。 認証Webゲートがない場合は必要ではありません。この場合はOracle Identity Manager (OIM)パスワード・ポリシー(OraOIMDefPasswdPolicy)によって、Oracle Access Managerとの統合が自動化され、ポリシーで使用される当該認証スキームで、パスワードをチェックするポリシーが有効化されます。デフォルト値は付加されているOimOhsHostPortに値があるパスワード・ポリシー関連パラメータで使用されます。例: -OimLostPwdRedirectUrl (Lost Password Redirect URL): <OimOHSHostPort>/admin/faces/pages/forgotpwd.jspx -OimPwdRedirectUrl (Password Change Redirect URL): <OimOHSHostPort>/admin/faces/pages/pwdmgmt.jspx?backUrl=%RESOURCE% -OimLockoutRedirectUrl (Account Lockout Redirect URL): <OimOHSHostPort>/ApplicationLockoutURI OimOhsHostPortパラメータは、-configOimPwdPolicyフラグが存在する場合にのみ使用されます。 |
|
OimPwdRedirectUrl |
configOIMPwdPolicyで必須です。Oracle Access Managerのパスワード変更のリダイレクトURLパラメータを構成します。 |
|
OimLockoutRedirectUrl |
configOIMPwdPolicyで必須です。Oracle Access Managerのカスタム・アカウント・ロックアウトのリダイレクトURLパラメータを構成します。 |
|
OimLostPwdRedirectUrl |
configOIMPwdPolicyで必須です。Oracle Access Managerのロスト・パスワードのリダイレクトURLパラメータを構成します。 |
|
注意: これは1回のみ設定する必要があります。OraOIMDefPasswdPolicyポリシーが既存の場合、新たには作成されません。この操作の後はアイデンティティ・サーバーとアクセス・サーバーを再起動する必要があります。例17-2を参照してください。 |
例17-2 OIM統合関連パラメータの使用方法
$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) java -jar oamcfgtool.jar app_domain=app_domain protected_uris="/protUri" ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager" oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_ base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_ url=http://myhost.us.myco.com:7777 -configOIMPwdPolicy OimPwdRedirectUrl="http://oimredirectutl.com OimLockoutRedirectUrl="http://oimlockouturl.com" OimLostPwdRedirectUrl="http://oimLostpwdurl.com" -noprompt
マスター・アクセス管理者または委任アクセス管理者は、Oracle Access Managerを直接チェックして、ポリシー・ドメインとWebゲート・プロファイルの設定を検証できます。
|
注意: アクセス・ゲート・プロファイル作成の検証には、OAMCfgToolモードを使用できません。 |
OAMCfgToolをVALIDATEモードで使用することにより、シングル・サインオン構成のポリシー・ドメインが正しいことを確認できます。この場合、一連のリクエストは保護されたリソースに自動的に送信されます。
表17-7は、OAMCfgToolの必須パラメータとオプション・パラメータ、およびVALIDATEモードでの各値を示しています。
表17-7 OAMCfgToolのVALIDATEモードでのパラメータと値
| VALIDATEモードのパラメータ | 必須パラメータのVALIDATEモード値 |
|---|---|
|
必須パラメータ |
値 |
|
app_domain |
アプリケーションを保護するために作成されたOracle Access Managerポリシー・ドメインの名前。 |
|
ldap_host |
Oracle Access ManagerのLDAPディレクトリ・サーバーをホストするコンピュータのDNS名。 |
|
ldap_port |
LDAPディレクトリ・サーバーのポート。 |
|
ldap_userdn |
引用符で囲んだ文字列として入力されている、LDAP管理ユーザーの有効なDN。Oracle Access Managerでは、ルートDNまたはバインドDNと呼ばれています。 |
|
ldap_userpassword |
LDAP管理ユーザーのパスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。この表の「noprompt」も参照してください。 |
|
ldap_base |
すべてのLDAP検索が実行されるベース。Oracle Access Managerでは、検索ベースまたは構成ベースと呼ばれています。たとえば、dc=company、c=usのように指定します。 |
|
oam_aaa_host |
アクセス・サーバーをホスティングしているコンピュータのDNS名。 |
|
oam_aaa_port |
アクセス・サーバー・ホストのリスニング・ポート。 |
|
test_username |
ポリシー検証に使用するユーザー名。 |
|
test_userpassword |
ポリシー検証に使用されるユーザー・パスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。この表の「noprompt」も参照してください。 |
|
noprompt |
安全な受け渡しを保証するため、OAMCfgToolでSystem.inからのパスワードを読み取れるようにします。パスワードは、echoコマンドを使用し、セパレータにはセミコロンを使用してシェルから渡すことができます。ConfigToolでは、Ldapユーザーr、Appエージェント、OAM モード、およびテスト・ユーザーの4つのパスワードが受け入れられます。 表17-5の「noprompt」も参照してください。 |
|
オプション・パラメータ |
値 |
|
web_domain |
ホスト識別子。 |
|
ldap_base |
すべてのLDAP検索が実行されるベース。Oracle Access Managerでは、検索ベースまたは構成ベースと呼ばれています。たとえば、dc=company、c=usのように指定します。 |
|
oam_aaa_mode |
アクセス可能なAccess Serverのトランスポート・セキュリティ・モード。OPEN、SIMPLEまたはCERTを指定します。デフォルト値はOPENです。 |
|
oam_aaa_passphrase |
SIMPLEトランスポート・セキュリティ・モード専用のパスフレーズ。入力はクリアテキストで表示されます。しかし、ログ・ファイルには記録されません。 |
|
log_file |
OAMCfgToolログ・ファイルの名前。デフォルトでは、画面出力されます。 |
|
log_level |
OAMCfgToolロギング・レベル: ALL、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINESTおよびOFF(デフォルト)。 |
|
noprompt |
安全な受け渡しを保証するため、OAMCfgToolでSystem.inからのパスワードを読み取れるようにします。パスワードは、echoコマンドを使用し、セパレータにはセミコロンを使用してシェルから渡すことができます。OAMCfgToolでは、LDAPユーザー、Appエージェント、OAMモード、およびテスト・ユーザーの4つのパスワードが受け入れられます。 表17-5も参照してください。 |
OAMCfgToolをDELETEモードで使用すると、プロビジョニングしたポリシー、Webドメイン、Webゲートの登録および認証スキームを削除できます。
表17-8は、OAMCfgToolのDELETEモードにおける必須パラメータとオプション・パラメータ、および値を示しています。
表17-8 OAMCfgToolのDELETEモードのパラメータ
| DELETEモードのパラメータ | 必須パラメータのDELETEモード値 |
|---|---|
|
ldap_host |
Oracle Access ManagerのLDAPディレクトリ・サーバーをホストするコンピュータのDNS名。 |
|
ldap_port |
LDAPディレクトリ・サーバーのポート。 |
|
ldap_userdn |
引用符で囲んだ文字列として入力されている、LDAP管理ユーザーの有効なDN。Oracle Access Managerでは、ルートDNまたはバインドDNと呼ばれています。 |
|
ldap_userpassword |
LDAP管理ユーザーのパスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。表17-5の「-noprompt」も参照してください。 |
|
oam_aaa_host |
アクセス・サーバーをホスティングしているコンピュータのDNS名。 |
|
oam_aaa_port |
アクセス・サーバー・ホストのリスニング・ポート。 |
|
オプション・パラメータ |
値 |
|
app_domain |
アプリケーション・ドメイン全体を削除するには、URI関連パラメータなしでapp_domainのみを指定します。 |
|
web_domain |
web_domain=existing_host_Identifier このパラメータおよびWebゲート登録で特定されるホスト識別子を削除します。 表17-5も参照してください。 |
|
protected_uris |
保護されるアプリケーションのURIのカンマ区切りリスト(空白あり/なし)(例: /myapp/login)。 アプリケーション・ドメインから1つ以上の保護付きURIを削除します。 この表のパラメータuris_fileも参照してください。 |
|
public_uris |
アプリケーション・ドメインから1つ以上の公開URIを削除します。 この表のパラメータuris_fileも参照してください。 |
|
uris_file |
任意の数の保護付きURIまたは公開URIが保存されたファイルへのフルパスで、パラメータprotected_urisまたはpublic_urisを使用する必要をなくします。このファイルでは次の構文および形式が使用されていることを確認します。 表17-5も参照してください。 |
|
authn_scheme |
削除する認証スキームの名前。OraDefAuthSchemes、OraDefaultAWGFormAuthNScheme、およびOraDefaultI18NFormAuthNSchemeから指定します。 3つすべてを削除するには、OraDefAuthSchemesを指定します。 次のオプションを組み込むことができます。 -noconfirm: このパラメータを使用すると削除前の確認プロンプトが省略されます。 |
|
noprompt |
安全な受け渡しを保証するため、OAMCfgToolでSystem.inからのパスワードを読み取れるようにします。パスワードは、echoコマンドを使用し、セパレータにはセミコロンを使用してシェルから渡すことができます。OAMCfgToolでは、LDAPユーザー、Appエージェント、OAMモード、およびテスト・ユーザーの4つのパスワードが受け入れられます。 表17-5も参照してください。 |
この項では、Oracle Access Managerで表示した場合のOAMCfgToolの実行結果について説明します。
ポリシー・ドメイン
「ポリシー・ドメイン」の「一般」タブ
図17-1は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「一般」タブを示しています。説明は、自動的に表示されます。
|
注意: 説明について、Java APIは稼働プラットフォームの現在のユーザーとコンピュータ・ホスト名user@hostnameを取得します。 |
「ポリシー・ドメイン」の「リソース」タブ
図17-2は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「リソース」タブを示しています。httpはデフォルトのリソース・タイプです。ホスト識別子とURL接頭辞は、入力したOAMCfgToolパラメータとその値から導出されます。説明は、自動的に表示されます。
「ポリシー・ドメイン」の「認可ルール」タブ
図17-3は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「認可ルール」タブを示しています。図の後にサブ・タブの詳細を示します。OAMCfgToolを使用すると、ポリシー・ドメインの認可ルールが自動的に構成されます。
「ポリシー・ドメイン」の「デフォルト・ルール」タブ
図17-4は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「デフォルト・ルール」タブを示しています。ポリシー・ドメインに対してすべての値が自動的に構成されます。図の後にサブ・タブの詳細を示します。
「ポリシー・ドメイン」の「ポリシー」タブ
図17-5は、OAMCfgToolで指定したパラメータと値を使用して作成した、サンプル・ポリシー・ドメインの「ポリシー」タブにある「一般」サブ・タブを示しています。ホスト識別子は、app_domain値に基づきます。図の後に他のサブ・タブの詳細を示します。
「ポリシー・ドメイン」の「委任アクセス管理」タブ
図17-6は、OAMCfgToolを使用して作成されたサンプル・ポリシー・ドメインの「委任アクセス管理」タブを示しています。このツールでは、マスターWebリソース管理の委任権限を設定するパラメータは指定されていません。
|
関連項目: 『Oracle Access Managerアクセス管理ガイド』のポリシー・ドメインによるリソースの保護に関する項 |
ホスト識別子
OAMCfgToolで作成したホスト識別子は、アクセス・システム・コンソールの「アクセス・システム構成」タブで確認できます。
図17-7は、OAMCfgToolを使用して作成されたサンプル・ホスト識別子を示しています。ここで説明されているように、必須パラメータはOAMCfgToolのapp_domainパラメータに入力した値から導出されます。説明は、OAMCfgToolが表示します。
アクセス・ゲート・プロファイル
図17-8は、OAMCfgToolを使用し、web_domainパラメータを省略して作成されたサンプル・アクセス・ゲート・プロファイルを示しています。このプロファイルは、アクセス・システム・コンソールにあります。ここで説明するように、プロファイルの必須パラメータはOAMCfgToolで入力された値から導出されます。その他のプロファイル・パラメータはデフォルト値が使用されます。説明は、OAMCfgToolが表示します。
表17-9に、このリリースに関する既知の問題を示します。ツール、パラメータおよび値の詳細は、「OAMCfgToolの概要」を参照してください。
表17-9 OAMCfgToolの既知の問題
| バグ番号 | 説明 |
|---|---|
|
該当なし |
Oracle Fusion MiddlewareアプリケーションをインストールしていないときにアクセスするOracle Access Manager認証プロバイダとOAMCfgToolのJARファイルのダウンロード元は、変更される可能性があります。この章に記載されている場所とは異なっている場合、リリース・ノートを参照して最新情報を確認してください。 |
|
8362080 |
OAMCfgToolには、CREATE、VALIDATE、およびDELETEのモードがあります。上書きオプションはありません。 |
|
8362039 |
OAMCfgToolでは、Web層のホストおよびポートを指定するための明示的なオプションは提供されません。かわりに、web_domainが指定されていない場合、app_domain値によってWebゲート名、ホストおよび優先HTTPホストが指定されます。例:
|
|
該当なし |
OAMCfgToolでは、web_domainパラメータがコマンドラインに含まれている場合、Webゲートのパスワードを指定する必要があります。指定しない場合、コマンドラインは失敗する可能性があります。 app_agent_passwordパラメータは、等号(=)に続く任意の文字列をパスワードとして受け入れます。たとえば、app_agent_password=と入力し、空白を入力してからweb_domain=valueと入力すると、app_agent_passwordは、空白の後にweb_domainが付いた文字列であるとみなされます。 |
|
該当なし |
ディレクトリ・サーバーとのSSL対応通信は、OAMCfgToolによってサポートされていません。 |
この項では、シングル・サインオン用のOracle Access Manager IDアサーションの構成に固有の手順について説明します。
前提条件
認証プロバイダまたはOracle Web Services Managerに関して特に明記されていないかぎり、次のタスクを含め、「OAM 10g用の認証プロバイダのインストールおよび設定」で説明されているすべてのタスクを実行する必要があります。
認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール
|
注意: 実装に応じて、次の処理を実行します。
|
アプリケーションでシングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを構成するには、次のタスクの概要で説明されている手順を実行します。
タスクの概要: シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダのデプロイおよび構成
次の項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンをアプリケーションで設定するための手順について説明します。
|
注意: このタスクはOAM 11gとOAM 10gの両方で同じです。 |
この項では、Oracle Access Manager IDアサーションのアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle Access Manager IDアサーション・プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をCLIENT-CERTに指定する必要があります。
auth-methodには、BASIC、FORMまたはCLIENT-CERTの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。
|
注意: WebLogicを介して直接アプリケーションにアクセスして、WebLogic認証スキームを呼び出すようにする場合には、CLIENT-CERT、FORMを指定できます。 |
IDアサーション・プロバイダおよびOAM 10gに対してweb.xmlで認証を指定するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。
your_app/WEB-INF/web.xml
login-configでauth-methodを検索し、CLIENT-CERTと入力します。
<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>
ファイルを保存します。
アプリケーションを再デプロイして再起動します。
アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。
「Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認」に進みます。
Oracle HTTP Serverには、mod_weblogicプラグイン・モジュール(11gではmod_wl_ohs.so)が含まれ、あらかじめ有効化されています。次の手順を実行してこれを確認するか、またはこの手順を省略できます。
Oracle HTTP Server 11gを使用する場合、mod_weblogic構成がmod_wl_ohs.confにデフォルトで含まれ、このファイルのパスがhttpd.confに含まれます。mod_weblogic構成が存在しない場合は、httpd.confを編集する必要があります。
IDアサーション・プロバイダおよびOAM 10gに対してmod_weblogicを構成するには
httpd.confを見つけます。例:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
ファイル内に次の文があり、デプロイメントに適した値が指定されていることを確認します(必要に応じてコメントを追加または削除します)。
<IfModule mod_weblogic.c> WebLogicHost yourHost.yourDomain.com WebLogicPort yourWlsPortNumber </IfModule> <Location http://request-uri-pattern> SetHandler weblogic-handler </Location>
ファイルを保存します。
Oracle WebLogicの接続フィルタ・メカニズムを構成すると、アクセス制御リストを作成したり、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストのみからリクエストを受け入れることができます。
|
注意: この項は、OSSOとOracle Access Managerのいずれを使用していても同じです。 |
ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。これは、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレスまたはDNSノード名をフィルタリングするように構成できるため、ファイアウォールのような機能を果たします。これは通常、Oracle WebLogic Serverと外部エンティティ間で信頼を確立する際に使用します。
接続フィルタを構成してmod_weblogicとOHS 11gが実行されているホストからのリクエストのみを許可するには、ここで説明する手順を実行します。
|
注意: この章では、Apache用WebLogic Serverプラグインの汎用名(mod_weblogic)を使用します。Oracle HTTP Server 11gの場合、このプラグインの名前はmod_wl_ohsで、実際のバイナリ名はmod_wl_ohs.soです。例では実装のための正確な構文を示します。 |
WebLogic Serverでは、デフォルト接続フィルタweblogic.security.net.ConnectionFilterImplが提供されます。このフィルタは、すべての着信接続を受け入れ、サーバーによる現在の接続フィルタの取得を許可する静的ファクトリ・メソッドも提供します。アクセスを拒否するようにこの接続フィルタを構成するには、WebLogic Server管理コンソールで接続フィルタ・ルールを入力します。
また、weblogic.security.netパッケージにクラスを実装することにより、カスタム接続フィルタを使用することもできます。デフォルト接続フィルタと同様、カスタム接続フィルタはWebLogic Server管理コンソールで構成します。
接続フィルタ・ルール: フィルタ・ルールの形式は、フィルタ・ルールの入力にフィルタ・ファイルまたは管理コンソールのどちらを使用するかによって異なります。管理コンソールでは、次の形式でフィルタ・ルールを入力します。
targetAddress localAddress localPort action protocols
表17-10は、接続フィルタの各パラメータを説明しています。
表17-10 接続フィルタ・ルール
| パラメータ | 説明 |
|---|---|
|
target |
フィルタ対象の1つ以上のシステムを指定します。 |
|
localAddress |
WebLogic Serverインスタンスのホスト・アドレスを定義します。(アスタリスク(*)を指定すると、すべてのローカルIPアドレスが返されます。) |
|
localPort |
WebLogic Serverインスタンスのリスニング・ポートを定義します。(アスタリスク(*)を指定すると、サーバー上のすべての使用可能なポートが返されます。) |
|
action |
実行するアクションを指定します。この値は、allowまたはdenyである必要があります。 |
|
protocols |
フィルタ対象のプロトコル名の一覧。プロトコル名として、http、https、t3、t3s、giop、giops、dcom、ftpおよびldapを指定できます。プロトコル名を定義しない場合、すべてのプロトコルがフィルタ・ルールと一致します。 |
「接続ログの有効化」属性によって、正常な接続とサーバー上の接続データがログに記録されます。この情報は、サーバー接続の問題をデバッグする際に使用できます。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogicドメインのセキュリティの構成に関する項 |
11gのOracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成するには
Oracle WebLogic管理コンソールにログインします。
「ドメイン構成」の下の「ドメイン」をクリックします。
「セキュリティ」タブ→「フィルタ」タブをクリックします。
「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。
ドメインで使用する次の接続フィルタを指定します。
デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。
カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHでも指定する必要があります。
適切な接続フィルタ・ルールの構文を入力します。
「保存」をクリックします。
Oracle WebLogic Serverを再起動します。
この項では、OAM 10g用のOAMCfgToolの使用を中心に説明します。OAM 11gを使用している場合には、この項を省略して、「セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング」の説明にあるタスクを実行してください。
アプリケーションを設定したら、Oracle Access Managerを使用して保護する必要があります。このタスクの自動化を支援する、OAMCfgToolというコマンドライン・ツールが用意されています。このツールは、Fusion MiddlewareアプリケーションのOAM 10g用oamcfgtool.jarファイル内にあります。
この手順は、アクセス・システム・コンソールとポリシー・マネージャで手動で実行できますが、オプションのOAMCfgToolを使用して、フォームベース認証スキーム、アプリケーションのポリシー・ドメイン、およびシングル・サインオン用IDアサーションで必要とされるOracle Access Managerアクセス・ポリシーを設定および検証することができます。また、新規Web層に新しいWebゲート・プロファイルを作成したり、既存Web層のWebゲート・プロファイルを変更することもできます。
詳細は、「認証スキーム、ポリシー・ドメイン、およびWebゲート・プロファイルの作成」を参照してください。
この項では、OAMCfgToolの実行時にモデルとして使用できる手順について説明します。
この例では、新しいWebゲート・プロファイルを必要とする新規Web層を想定しています。このため、web_domain=パラメータは省略されます。新しいプロファイルが作成され、app_domain値から名前が付けられます(_AGが付加されます)。
次の手順は、このツールの使用方法の一例にすぎません。その値は、使用する環境によって異なります。
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、OAMCfgToolはすでにインストールされています。この場合、手順1を省略します。 |
OAMCfgToolを使用してフォーム認証スキーム、ポリシー・ドメインおよびアクセス・ポリシーを作成するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Fusion Middlewareアプリケーションがない場合には、OAMCfgTool を入手します。
Oracle Technology Networkにログインします:
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Managerのコア・コンポーネント(10.1.4.3.0)を使用してOAMCfgTool ZIPファイルを見つけます。
oamcfgtool<version>.zip
oamcfgtool.jarを抽出し、Webゲートをホスティングしているコンピュータにコピーします。
JDK 1.6(または最新バージョン)がインストール済および構成済であることを確認します。
保護するアプリケーションをホスティングしているコンピュータにログインし、OAMCfgToolが含まれているファイル・システム・ディレクトリに移動します。
|
注意:
|
Webゲート・プロファイル、認証スキームおよびポリシー・ドメインを作成します。表17-5の説明に従い、環境に適した値を使用して次のコマンドを実行します。例:
(echo ldappwd | java -jar oamcfgtool.jar mode=CREATE app_domain=IASSO_App1 protected_uris=/myapp/login cookie_domain=<preferred_http_cookie_domain> ldap_host=wxyz ldap_port=6633 ldap_userdn=orcladmin oam_aaa_host=abcd oam_aaa_port=7789 oam_aaa_mode=cert log_file=OAMCfg_date.log log_level=INFO output_ldif_file=<LDIF_filename> -noprompt
このツールで指定した情報を確認します。たとえば、ステップ3のパラメータと値は次のとおりです。
Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation.
Operation Summary:
Policy Domain : IASSO_App1
Host Identifier: IASSO_App1
Access Gate ID : IASSO_App1_AG
出力LDIFの作成: LDIFをインポートし、その情報をディレクトリ・サーバーに書き込みます。該当しない場合は、この手順を省略します。
検証: OAMCfgToolを実行して、作成されたポリシー・ドメインを検証します(表17-7を参照)。例:
(echo ldappwd | java -jar oamcfgtool.jar mode=VALIDATE app_domain=IASSO_App1 protected_uris=/myapp/login ldap_host=wxyz ldap_port=6633 ldap_userdn=orcladmin oam_aaa_host=abcd oam_aaa_port=7789 log_file=OAMCfg_date.log log_level=INFO test_username=gcf test_userpassword=<test_userpassword> -noprompt
Webゲートがインストールされていない新規Webゲート・プロファイル: Webゲートをインストールするときに、プロファイルの作成時に指定した値と同じ値(および、インストールの完了に必要なその他の値)を指定します。
Webゲートがインストールされている新規Webゲート・プロファイル: OAMCfgToolのCreateコマンド出力を使用してOracle Access ManagerのconfigureWebGateツールを実行し、インストールされているWebゲートを設定します。例:
次の場所に移動します。
WebGate_install_dir\access\oblix\tools\configureWebGate
ここで、WebGate_install_dirは、Webゲートのインストール先ディレクトリです。
次のコマンドを実行し、OAMCfgToolで指定した値とプロファイルの完了に必要なその他の値を使用して、Webゲートを構成します。例:
configureWebGate -i WebGate_install_dir -t WebGate WebGate_Name -P WebGate_password -m <open|simple|cert> -h Access_Server_Host_Name -p Access_Server_Port -a Access_Server_ID -r Access_Server_Pass_Phrase (must be the same as the WebGate_password) -Z Access_Server_Retry count
|
関連項目: 『Oracle Access Managerアクセス管理ガイド』のアクセス・ゲートとWebゲートの構成に関する項 |
アクセス・システム・コンソールでのプロファイルの確認: 次の手順を実行して、Webゲート・プロファイルを表示または変更します。
マスター・アクセス管理者または委任アクセス管理者として、アクセス・システム・コンソールにログインします。例:
http://hostname:port/access/oblix
hostnameはWebパスのWebサーバーをホストするコンピュータで、portはWebパスのWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。
「アクセス・システム構成」をクリックし、「アクセス・ゲート構成」をクリックします。
「すべて」ボタンをクリックしてすべてのプロファイルを検索し(または、リストから検索属性と条件を選択し)、「実行」をクリックします。
Webゲートの名前をクリックして、その詳細を表示します。
「取消」をクリックしてこのページの変更内容を消去するか、「変更」をクリックして、『Oracle Access Managerアクセス管理ガイド』の説明に従って値を変更します。
保護するアプリケーションごとに、ステップ3から8を繰り返します。
「WebLogicドメインでのプロバイダの構成」に進みます。
この項の内容は次のとおりです。
この項では、WebLogicセキュリティ・レルムの認証プロバイダを初めて使用するユーザーのために、いくつかのタイプの認証プロバイダのみを説明します。
WebLogicセキュリティ・レルムごとに、少なくとも1つの認証プロバイダを構成する必要があります。WebLogicセキュリティ・フレームワークは、マルチパート認証用に複数の認証プロバイダ(および複数のLoginModule)をサポートするように設計されています。このため、1つのセキュリティ・レルムで複数の認証プロバイダと複数のタイプの認証プロバイダを使用できます。制御フラグ属性により、認証プロセスにおいて各認証プロバイダのLoginModuleがどのように使用されるかが決定されます。
Oracle WebLogic Serverは、次のものを含め、複数のタイプの認証プロバイダとIDアサーション・プロバイダを提供します。
デフォルトのWebLogic認証プロバイダ(デフォルトの認証プロバイダ)では、ユーザーとグループを1箇所で、つまり、WebLogic Serverの組込みLDAPサーバーで管理できます。この認証プロバイダは、Oracle WebLogic Serverでの管理ユーザー・ログインに使用されます。
IDアサーション・プロバイダは、トークンベース認証を使用します。Oracle Access Manager IDアサーション・プロバイダはその一例です。
LDAP認証プロバイダは、ユーザーおよびグループ情報を外部LDAPサーバーに格納します。このプロバイダは主に、一般的なディレクトリ・スキーマが反映されるように、対応するLDAPサーバーがデフォルトで構成されている点が異なります。
Oracle WebLogic Server 10.3.1以降は、OracleInternetDirectoryAuthenticatorを提供します。
複数の認証プロバイダを構成する場合、各プロバイダに対してJAAS制御フラグを使用して、ログイン・シーケンスでの認証プロバイダの使用方法を制御します。たとえば、次のJAAS制御フラグ設定を選択できます。
REQUIRED: 認証プロバイダが常に呼び出され、ユーザーはその認証テストを常にパスする必要があります。認証の成否に関係なく、プロバイダ・リストの最後まで認証が続行されます。
SUFFICIENT: ユーザーは、認証プロバイダの認証テストをパスする必要はありません。認証に成功した場合、後続の認証プロバイダは実行されません。認証に失敗した場合、プロバイダ・リストの最後まで認証が続行されます。
OPTIONAL: ユーザーは、認証プロバイダの認証テストをパスしても失敗してもかまいません。ただし、セキュリティ・レルムに構成されているすべての認証プロバイダでJAAS制御フラグがOPTIONALに設定されている場合は、ユーザーは構成されているプロバイダのいずれかの認証テストをパスする必要があります。
既存のセキュリティ・レルムに認証プロバイダを追加した場合、制御フラグはデフォルトでOPTIONALに設定されます。場合によっては、認証シーケンスで各認証プロバイダが適切に機能するように、制御フラグの設定とプロバイダの順序を変更する必要があります。
|
関連項目: すべての認証プロバイダのリストと、ユーザーおよびグループ属性をLDAPスキーマと一致させるためのOracle Internet Directoryプロバイダの構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項を参照してください。 |
この項では、WLSTを初めて使用するユーザーのために、WLSTについて説明します。
Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して、WebLogicドメインにプロバイダを追加できます。
WLSTはJythonベースのコマンドライン・スクリプト環境で、WebLogic Serverドメインの管理と監視のために使用できます。通常、このツールはオンラインまたはオフラインで使用できます。このツールは、ファイルで提供されるバッチ(ユーザーの入力を介在せずに、スクリプトが一連のWLSTコマンドを呼び出すスクリプト・モード)において、コマンドラインで対話的に実行することができます。また、Javaコードに組み込むことも可能です。
WebLogicドメインに認証プロバイダを追加する場合、WLSTをオンラインで使用して認証プロバイダと対話し、ユーザー、グループおよびロールを追加、削除または変更できます。
WLSTをオフラインで使用してドメイン・テンプレートを作成する場合、WLSTによって認証プロバイダのデータ・ストアとその他のドメイン文書がパッケージ化されます。ドメイン・テンプレートからドメインを作成すると、新しいドメインは、ドメイン・テンプレートの認証プロバイダのデータ・ストアとまったく同じコピーになります。ただし、WLSTをオフラインで使用して認証プロバイダのデータ・ストア内のデータを変更することはできません。
|
注意: WLSTをオフラインで使用して、認証プロバイダのデータ・ストア内のデータを変更することはできません。 |
|
関連項目:
|
Oracle Application Development Framework (Oracle ADF)セキュリティを使用し、Oracle Access Manager Single Sign On (SSO)と統合し、ユーザー認証にOracle Platform Security Services (OPSS) SSOを使用するWebアプリケーションをOracle WebLogic Server上で実行できます。ただし、Webアプリケーションを実行する前に、アプリケーションのターゲットのOracle WebLogic Server上で、Oracle Access Managerセキュリティ・プロバイダ用にドメインレベルのjps-config.xmlファイルを構成する必要があります。
ドメインレベルのjps-config.xmlファイルは次のパスに存在します。デプロイ済のアプリケーションのjps-config.xmlファイルと混同しないでください。
domain_home/config/fmwconfig/jps-config.xml
Webアプリケーションのデプロイ前またはデプロイ後に、Oracle Access Manager固有のWLSTスクリプトを使用して、ドメインレベルのjps-config.xmlファイルを構成できます。このOracle JRF WLSTスクリプトの名前は次のとおりです。
Linux: wlst.sh
Windows: wlst.cmd
JDevを使用して実行している場合、Oracle JRF WLSTスクリプトは次のパスにあります。
$JDEV_HOME/oracle_common/common/bin/
JRF WebLogicをスタンドアロンでインストールしている場合のパスは次のとおりです。
$Middleware_home/oracle_common/wlst
|
注意: Oracle JRF WLSTスクリプトが必要です。Oracle Java Required Files (JRF)用のWLSTを実行している場合は、$JDEV_HOME/wlserver_10.3/common/binにあるWLSTスクリプトを使用しないでください。 |
コマンド構文
addOAMSSOProvider(loginuri, logouturi, autologinuri)
表17-11では、addOAMSSOProviderコマンドラインにおける各引数の期待値を定義しています。
表17-11 addOAMSSOProviderコマンドライン引数
| 引数 | 定義 |
|---|---|
|
loginuri |
ログイン・ページのURIを指定します。 |
|
logouturi |
ログアウト・ページのURIを指定します。 |
|
autologinuri |
自動ログイン・ページのURIを指定します。 |
|
関連項目:
|
前提条件
このタスクを開始する前に、次の項の説明にあるとおりにこれまでのすべてのタスクが実行済であることを確認します。
Oracle ADFセキュリティが有効なFusion Webアプリケーション用のドメインレベルのjps-config.xmlを変更するには:
Oracle WebLogic ServerおよびOracle ADFセキュリティを使用しているWebアプリケーションをホストするコンピュータ上で、Oracle JRF WLSTスクリプトを見つけます。例:
cd $ORACLE_HOME/oracle_common/common/bin
Oracle WebLogic Serverをホストするコンピュータに接続します。
connect login_id password hostname:port
たとえば、Oracle WebLogic管理サーバーのホストは、ポート7001を使用するlocalhostであることが考えられます。ただし、これは使用する環境によって異なる可能性があります。
ADFセキュリティが有効なアプリケーション用の値を使用して、次のコマンドライン引数を入力します。
addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",
logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")
Oracle WebLogic Serverを停止して起動します。
この章で説明されているように次のタスクを実行します。
アプリケーションを実行します。
この項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンを実行するために、WebLogicセキュリティ・ドメインのプロバイダを構成する方法について説明します。次の認証プロバイダ・タイプを構成して並べ替える必要があります。
次の手順では、WebLogic管理コンソールを使用します。
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダJARファイルはすでにインストールされています。ステップ1を省略してください。 |
シングル・サインオン用のOracle Access ManagerプロバイダをWebLogicドメインに設定するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順でダウンロードします。
Oracle Technology Networkにログインします:
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。
oamAuthnProvider<version number>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle Fusion Middlewareアプリケーションをインストール済の場合:
次のパスでoamauthenticationprovider.warを見つけます。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi der.war
oamauthenticationprovider.warを次の場所にコピーします。
BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication provider.war
WebLogic管理コンソールにログインします。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
OAM IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。
「認証」→「新規」をクリックし、名前を入力してから次のプロバイダ・タイプを選択します。
名前: OAM Identity Asserter
タイプ: OAMIdentityAsserter
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「共通」タブをクリックし、「制御フラグ」をREQUIREDに設定して「保存」をクリックします。
OID認証プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator
タイプ: OracleInternetDirectoryAuthenticator
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。
「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。
ポート: LDAPホストのリスニング・ポート。例: 6050。
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。
資格証明: LDAPの管理ユーザー・パスワード。
ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。
すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))
ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。
グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)。
デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。
保存します。
デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。
「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。
保存します。
プロバイダを並べ替えます。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。
「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: (REQUIRED)
OID認証プロバイダ: (SUFFICIENT)
デフォルトの認証プロバイダ: (SUFFICIENT)
「OK」をクリックして変更を保存します。
変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。
Oracle WebLogic Serverを再起動します。
次のようにします。
成功: 「IDアサーション・プロバイダおよびOAM 10gのログイン・フォームの設定」に進みます。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール」で説明されているように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
この項では、シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダで提供されるログイン・フォームの概要を示し、このフォームをデプロイするための手順について説明します。
図17-9のフォームは、Oracle HTTP Server 11g Webサーバー用のWebゲート・インストールで提供されます。このフォームには、2つのフィールド(「ユーザーID」および「パスワード」)と「ログイン」ボタンがあります。このフォーム上の変数は、フォーム・ログイン認証スキームで必要とされます。この認証スキームはOAMCfgToolによって生成され、IDアサーション用リソースを保護しているポリシー・ドメインで使用されます。
|
注意: このログイン・フォームの変数は変更しないでください。これらの変数は、Oracle Access Manager IDアサーション・プロバイダで使用する必要があります。 |
Webゲートのインストールおよび構成中に、Oracle HTTP Server 11g Webサーバーのhttpd.confファイルに次の情報が追加されます。これにより、Oracle HTTP Server 11gのWebゲートがデフォルト・ログイン・フォームを検索できるようになります。
Alias /oamsso "/oam/webgate/access/oamsso"
次の3行が存在する場合には、削除します。
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
次の手順を参考にして、環境に適したログイン・フォームを設定してください。
|
注意: このログイン・フォームは、OAM 10gでの10g Webゲート専用です。 |
IDアサーション・プロバイダおよびOAM 10gのログイン・フォームを設定するには
アプリケーションをホスティングしているコンピュータの次のOracle HTTP Server11g Webゲート・パスに、ログイン・フォームが存在することを確認します。
WebGate_install_dir/access/oamsso/login.html
ブラウザから、次のURLにアクセスします。
http://WebGatehost:port/oamsso/login.html
ログイン・プロセスで認証ユーザーを、元のリクエストしたアプリケーションURLにリダイレクトできるようにするために、ポリシー・マネージャのリソースを保護するように/accessポリシーが作成および有効化されていることを確認します。
次の手順に進みます。
次の手順では、Oracle Access Manager IDアサーションの設定をテストする方法について説明します。
また、10g Oracle Access Manager Access管理者ガイドの説明にあるように、Oracle Access Manager 10gのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。
OAM 10gでのSSO用のIDアサーションを検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。例:
http://ohs_server:port/<protected url>
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
Oracle Access Manager認証プロバイダを構成するには、この項の各タスクを実行する必要があります。
前提条件
IDアサーション固有の手順として特に明記されていないかぎり、「OAM 10g用の認証プロバイダのインストールおよび設定」で説明されているすべてのタスクを完了する必要があります。
認証プロバイダおよびOAM 10g用のコンポーネントとファイルをインストールし、その際にアクセス・システム・コンソールでカスタム・アクセス・ゲートのアクセス・ゲート・プロファイルを手動で作成し、ポリシー・マネージャの設定でデフォルト値を受け入れます。
Oracle Access Manager証明書のJavaキーストア形式への変換(簡易または証明書トランスポート・セキュリティ・モードを使用する場合)
Oracle Access Manager認証プロバイダを構成するためのその他のタスクについては、次のタスク概要で説明します。
|
注意: この項のタスクを実行するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。Oracle Access Manager以外に、このタスクを自動化できるツールはありません。 |
タスクの概要: Oracle Access Manager認証プロバイダの構成
前提条件のすべてのタスクが実行されていることの確認
この項では、ポリシー・ドメインにおける認証スキームの作成方法について説明します。ポリシー・ドメインは、後で認証プロバイダに対して定義します。Oracle Access Manager認証スキームは、ポリシー・ドメインの前に作成しておく必要があります。
認証プロバイダを使用する場合、ユーザーには、アプリケーションのweb.xml内で構成されている認証方式に基づいて資格証明の入力が要求されます。ただし、ポリシー・ドメインではOracle Access Manager認証スキームが必要です。
認証プロバイダの認証スキームを作成した後、そのスキームを使用するには、Oracle Access Managerでポリシー・ドメインを作成する必要があります。
Oracle Access Managerのポリシー・ドメインには、各種の情報が含まれています。図17-10に示されているように、個別のタブにそれぞれの詳細を入力できます。
図17-10 Oracle Access Managerポリシー・マネージャの「ポリシー・ドメインの作成」ページ
詳細は、次の項目を参照してください。
この項では、ポリシー・マネージャの各タブについて説明します。これらのタブを使用してポリシー・ドメインとアクセス・ポリシーの詳細を入力できます。ポリシー・ドメインのすべてのタブを使用しない場合もありますが、次のような一般情報が提供されます。
「一般」タブ: このポリシー・ドメインの名前を指定する簡潔な英数字の文字列を入力します。「名前」フィールドでは、空白を使用できます。説明はオプションです。すべての詳細を保存し、ドメインを使用する準備が整うまで、このポリシー・ドメインを有効にしないでください。
「リソース」タブ: このポリシー・ドメインによって保護されるリソースを追加します。URL接頭辞を使用して、ポリシー・ドメインのコンテンツを定義します。説明はオプションです。
「認可ルール」タブ: 認可ルールを指定します。認可ルールは、一般情報、「アクセスの許可」と「アクセスの拒否」の各条件、および後で認可条件式で使用されるルールのアクション(存在する場合)で構成されます。定義するそれぞれの認可ルールに対し、1つの認証スキームを指定する必要があります。
「デフォルト・ルール」タブ: リソースが特定のポリシーによって保護されている場合を除き、ポリシー・ドメインによって保護されるリソースに適用するデフォルト・ルールを作成します。このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加します。
認証ルール: ポリシー・ドメインには、少なくとも1つの認証ルールが含まれている必要があります。認証ルールは、1つの認証スキームと複数の認証アクションを指定します。
認可条件式: これには、認可ルールとそれらを組み合せる演算子が含まれています。認証プロバイダ機能では、すべてのユーザーにアクセスを許可する認可ルールが必要です。
監査ルール: マスター監査ルールが定義されていない場合は、アクセス・システム管理者に連絡するよう指示されます。
「ポリシー」タブ: ルールが定義されていない場合、ポリシー・ドメインのデフォルト・ルールが有効です。作成した各ポリシーに対して、特定の認証ルール、認可条件式および監査ルールを割り当てることができます。詳細に記載されたURLパターンを使用して、ポリシーを作成できます。ポリシーを設定する前に、保護するURLに対して必要なアクセス制御レベルを決定してください。
「委任管理者」タブ: ポリシー・ドメインにURL接頭辞を追加する場合、委任アクセス管理者は、そのURL接頭辞をホスティングするサーバーを指定する必要があります。
|
関連項目: 「認証プロバイダのポリシー・ドメインとアクセス・ポリシーの作成」、および『Oracle Access Managerアクセス管理ガイド』の次の各項
|
認証プロバイダの実装では、ポリシー・ドメインにいくつかのデフォルト値と一意の値を指定する必要があります。ポリシー・ドメインを作成、表示または変更するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。
次の手順では、認証プロバイダに対して次のようなポリシー・ドメインを作成します。
(ポリシー・マネージャで設定された)デフォルトのBasic認証スキームを内部的に使用して、ユーザーを認証し、/Authen/Basicという接頭辞の付いたURLリソースを保護します。
以前に定義されたタイプwl_authenのリソースを保護します。「Oracle Access Manager 10gでのリソース・タイプの作成」も参照してください。
以前に作成したOracle Access Manager認証スキームを使用して、ユーザーの資格証明をリクエストします。
|
注意: 認証プロバイダでは、アプリケーションの |
デフォルト認証ルールとアクションが必要です。次の手順で、認証の成功時にユーザーとグループが返されるようにこれらを構成します。
アクションが定義されていないデフォルト認可ルールが必要です。これを、次の手順で構成して、すべてのユーザーにアクセスを許可するようにします。
|
注意: 認証プロバイダでは、認可は実行されません。ただし、認可ルールを作成して、すべてのユーザーにアクセスを許可する必要があります(認可条件式は必要ありません)。 |
次の例は、説明のみを目的としています。環境に応じて適切な値を入力してください。
Oracle Access Manager認証プロバイダのポリシー・ドメインを作成するには
ポリシー・マネージャに移動して、ログインします例:
http://Webserver:port/access/oblix
ここで、Webserverはポリシー・マネージャのWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システムに接続します。
「ポリシー・マネージャ」をクリックします。
左側のナビゲーション・ペインの「ポリシー・ドメインの作成」をクリックして、「ポリシー・ドメインの作成」ページを表示します。
「一般」タブ: ポリシー・ドメイン・リストを示すページに表示される名前とオプションの説明を入力し、「保存」をクリックします。例:
名前: Default OAM Authenticator
説明: For Username Resolution
|
注意: すべての指定が完了するまで、このポリシー・ドメインを有効にしないでください。 |
「リソース」タブ: 「リソース」タブ→「追加」ボタンをクリックし、リソース・タイプを選択してURL接頭辞を入力します。次の内容を保存します。
リソース・タイプ: wl_authen
ホスト識別子(オプション): アクセス・ゲートの優先HTTPホストを選択します。
URL接頭辞: /Authen/Basic
説明: OAM Authenticator validates user name, password
「追加」をクリックします。
リソース・タイプ: wl_authen
URL接頭辞: /Authen/UsernameAssertion
説明: Authenticator Resource to validate user name
「保存」をクリックします。
「デフォルト・ルール」タブ: このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加します。リソースが特定のポリシーによって保護されている場合を除き、ポリシー・ドメインのデフォルト・ルールがポリシー・ドメイン内のリソースに適用されます。
「デフォルト・ルール」をクリックし、「追加」をクリックしてBasic認証スキームのルールを作成します。
認証ルール: ポリシー・ドメインには、少なくとも1つの認証ルールが含まれている必要があります。認証ルールは、1つの認証スキームと複数の認証アクションを指定します。名前とオプションの説明を入力し、「認証スキーム」を選択します。
「認証ルール」をクリックし、「一般」タブに次の情報を入力します。
名前: Basic Authentication Scheme
説明: User name and password based authentication
認証スキーム: Basic Over LDAP
「保存」をクリックします。
|
注意: 認証プロバイダでは、ObMyGroups属性のルールでAuthentication Success Returnアクションのみが必要です。このアクセス・サーバー固有の属性は、ユーザーが属しているすべてのグループを返します。手順Cで説明されているように、他の2つの実装でもこのアクションが必要です。 |
認証ルール、アクション: 認証プロバイダを使用する場合(またはOracle Access Managerに存在する管理者ユーザーとしてOracle WebLogicを起動する場合、あるいはOracle Web Services Managerを使用している場合)に指定します。
「アクション」タブ→「追加」をクリックします。
「認証成功」に、次の情報を入力します。
リダイレクションURL: 空白
戻り値
タイプ: WL_REALM
名前: obmygroups
戻り属性: obmygroups
この戻り属性は、ユーザーが属しているすべてのグループを返すようにアクセス・サーバーに指示します。
次に、LDAPディレクトリ・サーバーでユーザーを一意に識別するために、ユーザー名のログイン・パラメータの名前を入力します。
タイプ: WL_REALM
名前: uid
戻り属性: uid
この戻り属性は、ユーザー名のログイン・パラメータの名前を返します。これは、Oracle Access Managerで使用されるLDAPディレクトリ・サーバーのユーザーを一意に識別するために役立ちます。
認可ルール: 「認可ルール」タブをクリックし、「追加」をクリックして、
ルール名と簡単な説明(省略可能)を指定します。例:
名前: Default rule for Authenticator.
説明: Default rule enables Authenticator function for anyone.
「有効」リストから「はい」を選択して、「保存」をクリックします。
ルールをクリックして、「アクセスの許可」タブをクリックし、「追加」をクリックして、「ロール」で、「すべてのユーザー」を選択して、保護されているリソースへのアクセスをすべてのユーザーに許可します。
「保存」をクリックします。
「ポリシー」タブ: 「ポリシー」タブ→「追加」をクリックします。
情報を入力し、「一般」の詳細を保存します。
名前: Default Username Resolution Policy
説明: Default Username Policy for Authenticator
リソース・タイプ: wl_authen
リソース操作: LOGIN
リソース: /Authen/UsernameAssertion
他の項目は変更せず、そのままにしておきます。
「保存」をクリックします。
「認証ルール」サブ・タブ→「追加」をクリックし、「一般」の詳細を入力します(名前、オプションの説明、認証スキーム)。
名前: Username Resolution Authentication Rule
認証スキーム: UsernameAssertion認証スキーム
「認証プロバイダの認証スキームの作成」を参照してください。
「保存」をクリックします。
「アクション」サブ・タブをクリックし、「認証成功」に次の情報を追加します。
戻り型: WL_REALM
戻り名: uid
戻り属性: uid
|
注意: 「戻り属性」には、必ず値を入力してください。 |
「アクション」サブ・タブをクリックし、「認証成功」に次の情報を追加します。
戻り型: WL_REALM
戻り名: obmygroups
戻り属性: obmygroups
|
注意:
|
委任アクセス管理: ポリシー・ドメインにURL接頭辞を追加する場合、委任アクセス管理者は、そのURL接頭辞をホスティングするサーバーを指定する必要があります。
|
関連項目: 『Oracle Access Managerアクセス管理ガイド』のポリシー・ドメイン管理の委任に関する項 |
この項では、WebLogicドメインに適切な認証プロバイダを追加および構成するための手順について説明します。
Oracle Access Manager認証プロバイダは、WebLogicドメインのデフォルト認証プロバイダに従って構成する必要があります。
次の手順では、WebLogic管理コンソールを使用してこのタスクを実行する方法について説明します。これらは、Oracle WebLogic Scripting Tool (WLST)を使用して追加することもできます。
|
関連項目:
|
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なファイルはすでにインストールされているので、ステップ1は省略できます。 |
WebLogicドメインにOracle Access Manager認証プロバイダを構成するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。
Oracle Technology Networkにログインします:
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。例:
oamAuthnProvider<version>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle WebLogic管理コンソールに移動します。
Oracle Fusion Middlewareアプリケーションをインストール済の場合:
次のパスでoamauthenticationprovider.warを見つけます。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi der.war
oamauthenticationprovider.warを次の場所にコピーします。
BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication provider.war
Oracle WebLogic管理コンソールに移動します。
必要に応じて、「ロックして編集」をクリックします。
OAM認証プロバイダ:
「セキュリティ・レルム」をクリックし、構成するレルムを選択します。
「プロバイダ」→「認証」を選択し、「新規」をクリックして、「新しい認証プロバイダの作成」ページを表示します。
名前を入力して、タイプを選択します。
名前: OAMAuthN
タイプ: OAMAuthenticator
OK
作成した認証プロバイダの名前をクリックして、「プロバイダ構成」ページを表示します。
「プロバイダ構成」ページで、次のように必要な値を設定します。
アクセス・ゲート名: プロバイダによって使用されるアクセス・ゲートの名前。これは、アクセス・システム・コンソールのアクセス・ゲート構成プロファイル内の名前と完全に一致している必要があります。
|
注意: 認証プロバイダ用のアクセス・ゲート構成プロファイルが1つしかない場合もあります。 |
アクセス・ゲートのパスワード: アクセス・システム・コンソールでアクセス・ゲート構成プロファイルに対してパスワードが定義されている場合は、それと同じパスワード。
プライマリ・アクセス・サーバー: アクセス・システム・コンソールでこのアクセス・ゲートに関連付けられているプライマリ・アクセス・サーバーのhost:port。
詳細構成: 次に、いくつかの詳細構成の値を示します。
トランスポート・セキュリティ: アクセス・サーバーとアクセス・ゲート間の通信モード(オープン、簡易、証明書)。
トランスポート・セキュリティが簡易または証明書である場合、次のパラメータと値を含めてください。
トラスト・ストア: プロバイダとOracle Access Server間のSSL通信で使用されるJKSトラスト・ストアの絶対パス。
キー・ストア: プロバイダとOracle Access Server間のSSL通信で使用されるJKSキー・ストアの絶対パス。
キー・ストアのパスフレーズ: キー・ストアにアクセスするためのパスワード。
簡易モード・パスフレーズ: アクセス・ゲートとアクセス・サーバーで共有される簡易通信モード用パスワード。
セカンダリ・アクセス・サーバー: アクセス・システム・コンソールでこのアクセス・ゲートに関連付けられているセカンダリ・アクセス・サーバーのhost:port。
プール内の最大アクセス・サーバー接続数: アクセス・ゲートがアクセス・サーバーに対してオープンする最大接続数。デフォルト値は10です。
|
注意: WebLogic管理コンソールでのプール内の最大アクセス・サーバー接続数(またはプール内の最小アクセス・サーバー接続数)の設定は、アクセス・システム・コンソール内でプロファイルに指定されている「最大接続数」または「最小接続数」とは異なります。 |
プール内の最小アクセス・サーバー接続数: 認証プロバイダからアクセス・サーバーへの認証リクエストの送信に使用する最小接続数。デフォルト値は5です。
パラメータ「制御フラグ」がOPTIONALに初期設定されていることを確認します。
|
注意: 認証プロバイダが機能し、正しく構成されていることを確認するまで、パラメータ「制御フラグ」をREQUIREDに設定しないでください。 |
チェンジ・センターで、変更のアクティブ化をクリックします。
DefaultAuthenticator: 「プロバイダ」タブでDefaultAuthenticatorを選択します。これにより、その制御フラグがSUFFICIENTに変更されます。
並べ替え: 「プロバイダ」タブで、DefaultAuthenticatorが先頭になるように(DefaultAuthenticatorの後にOAMAuthenticator)プロバイダを並べ替えます。
|
注意: Oracle Access Managerの認証プロバイダ・フラグがREQUIREDに設定されている場合、またはOracle Access Manager認証プロバイダのみが使用可能な場合、このタスクに対する実行権限を持っている管理者グループにOracle WebLogic Serverを起動するLDAPユーザーが含まれるように、次の手順を実行します。デフォルトでは、Oracle WebLogic ServerのAdminロールに管理者グループが含まれています。 |
Oracle Access Manager認証プロバイダのREQUIREDまたは唯一の認証プロバイダである場合: 次の手順を実行して、Oracle WebLogic Serverを起動するためのユーザー権限を設定します。
管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ(または、起動権限を付与する必要があるその他のグループ)を作成します。
|
注意: その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。 |
Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。
WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ロールとポリシー」→「グローバル・ロール」を選択します。
Adminロールの「条件の表示」を選択します。
グループを追加して「保存」をクリックします。
WebLogic Serverを再起動します。
サーバーを起動すると、認証プロバイダ・パラメータ「制御フラグ」が適切な値(REQUIRED、OPTIONAL、またはSUFFICIENT)にリセットされます。
この項では、Oracle Access Manager認証プロバイダのアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle Access Manager認証プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をBASICに指定する必要があります。
auth-methodには、BASICまたはFORMの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。
|
注意: Oracle Access Manager認証プロバイダの場合、web.xml内のlogin-configにauth-method BASICを指定することをお薦めします。 |
認証プロバイダのアプリケーション認証方式を構成するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。
WEB-INF/web.xml
login-configでauth-methodを検索し、BASICと入力します。例:
<security-constraint> <web-resource-collection> <web-resource-name>protected</web-resource-name> <url-pattern>/servlet</url-pattern> </web-resource-collection> <auth-constraint> <role-name>auth-users</role-name> </auth-constraint> </security-constraint> <login-config> <auth-method>BASIC</auth-method> </login-config> <security-role> <description>Authenticated Users</description> <role-name>auth-users</role-name> </security-role>
ファイルを保存します。
アプリケーションを再デプロイして再起動します。
アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。
この項では、認証ユーザーをLDAP内のグループにマップする方法について説明します。このためには、weblogic.xmlファイルを編集する必要があります。たとえば、ロール名auth-usersをLDAP内のmanagersというグループにマップできます。
Oracle Access Manager認証プロバイダ用に認証ユーザーをLDAP内のグループにマップするには
アプリケーションのweblogic.xmlファイルに移動します。
ファイル内の任意の場所に、環境に応じて次の情報を追加します。
<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<security-role-assignment>
<principal-name>managers</principal-name>
<role-name>auth-users</role-name>
</security-role-assignment>
</weblogic-web-app>
ファイルを保存します。
WebLogic Serverを再起動します。
次の手順に進みます。
認証プロバイダの実装タスクをすべて実行した後、有効な資格証明を使用してアプリケーションへのログインを試行して実装をテストできます。構成が正しくない場合、有効なユーザーがアクセスを拒否されます。
次の手順では、認証プロバイダの設定をテストする方法について説明します。『Oracle Access Managerアクセス管理ガイド』の説明に従って、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。
Oracle Access Manager認証プロバイダの実装を検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。例:
http://yourdomain.com:port
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
この項では、Oracle Web Services ManagerがWebサービスを保護している場合に、ObSSOCookieトークンの検証を有効にするようにOracle Access Manager IDアサーション・プロバイダを設定する方法について説明します。
Oracle Access Manager IDアサーション・プロバイダがヘッダーとObSSOCookieトークンの両方の検証モードで構成されている場合、ヘッダーが優先されます。ヘッダーが存在しない場合は、IDアサーション・プロバイダはアクセス・サーバーにアクセスしてObSSOCookieトークンを検証します。
Oracle Access Manager IDアサーション・プロバイダは、次の2つのモードで機能します。
デフォルト・モードの操作では、Webゲートが境界に設定したヘッダーがアサートされます。
もう1つのモードでは、oamAuthnProvider.jarにあるカスタム・アクセス・ゲートを使用します。この場合(ヘッダーも存在しない場合)、IDアサーション・プロバイダはアクセス・サーバーにアクセスしてObSSOCookieトークンを検証します。
|
注意: Oracle Web Services Managerでは、アクセス・ゲートが必要です。 |
前提条件
認証プロバイダおよびOAM 10g用のコンポーネントとファイルをインストールし、その際にアクセス・システム・コンソールでカスタム・アクセス・ゲートのアクセス・ゲート・プロファイルを手動で作成し、ポリシー・マネージャの設定でデフォルト値を受け入れます。
タスクの概要: Oracle Web Services Manager用のIDアサーション・プロバイダのデプロイ
前提条件のすべてのタスクが実行されていることの確認
この項では、Oracle Web Services ManagerがWebサービスを保護している場合に、Oracle Access Manager IDアサーション・プロバイダによって使用されるポリシー・ドメインを設定する方法について説明します。ポリシー・ドメインを作成、表示または変更するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。
このポリシー・ドメインでは、次の一意の値が必要です。
(ポリシー・マネージャで設定された)デフォルトのBasic Over LDAP認証スキームを内部的に使用して、ユーザーを認証し、/Authen/SSOTokenという接頭辞の付いたURLリソースを保護します。
「Oracle Access Manager 10gでのリソース・タイプの作成」で定義した、タイプwl_authenのリソースを保護します。
アクションが定義されていないデフォルト認証ルールが必要です。これは、次の手順で設定します。
アクションが定義されているデフォルト認可ルールが必要です。これは、次の手順で設定します。
次の手順では、Oracle Web Services ManagerとOracle Access Manager IDアサーション・プロバイダによって使用されるポリシー・ドメインを作成する方法について説明します。
Oracle Web Services Managerを使用するIDアサーション・プロバイダのポリシー・ドメインを作成するには
ポリシー・マネージャに移動して、ログインします例:
http://Webserver:port/access/oblix
ここで、Webserverはポリシー・マネージャのWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。
「ポリシー・マネージャ」をクリックします。
左側のナビゲーション・ペインの「ポリシー・ドメインの作成」をクリックして、「ポリシー・ドメインの作成」ページを表示します。
「一般」タブ: ポリシー・ドメイン・リストを示すページに表示される名前とオプションの説明を入力し、「保存」をクリックします。例:
名前: OAM IA OWSM
説明: Used by Identity Asserter with Oracle Web Services Manager
|
注意: すべての詳細が完了するまで、このポリシー・ドメインを有効にしないでください。 |
「リソース」タブ: 「リソース」タブ→「追加」ボタンをクリックし、リソース・タイプを選択してURL接頭辞を入力します。次の内容を保存します。
リソース・タイプ: wl_authen
URL接頭辞: /Authen/SSOToken
説明: Used by IA OWS to validate SSO token
保存します。
「認可ルール」タブ: 後で認可条件式で使用する認可ルールを追加します。
「認可ルール」タブ→「追加」ボタンをクリックします。
「一般」タブ: 認可ルールの名前と、オプションで簡潔な説明を入力します。
名前: Default_OAM_IA_OWS_AuthZ_Rule
説明: For use with OWS and Identity Asserter
有効: はい
許可を優先: いいえ
タイミング条件: このシナリオには必要ありません。
アクション: このタブでの設定は必要ありません。かわりに、「デフォルト・ルール」タブでこれらを設定します。
アクセスの許可: ルールの「アクセスの許可」部分を適用するユーザーの詳細を追加します。
ロール: 任意の個人
アクセスの拒否: このシナリオでは必要ありません。
認可ルールの「一般」タブに戻り、ルールを有効にして、後で認可条件式に追加できるようにします。
|
関連項目: 認可スキームとルールの構成の詳細は、『Oracle Access Managerアクセス管理ガイド』の第6章を参照してください。 |
「デフォルト・ルール」タブ: このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加できます。リソースが特定のポリシーによって保護されている場合を除き、これらのデフォルト・ルールがポリシー・ドメイン内のリソースに適用されます。
「デフォルト・ルール」→「追加」をクリックします。
認証ルール: ポリシー・ドメインには、少なくとも1つの認証ルールが含まれている必要があります。認証ルールは、1つの認証スキームとオプションの認証アクションを指定します。名前とオプションの説明を入力し、「認証スキーム」を選択します。
「一般」タブ: 次のように入力します。
名前: Default AuthN Rule
説明: Default Rule for OAM IA OSW
認証スキーム: Basic Over LDAP
「保存」をクリックします。
「アクション」タブ: Oracle Web Services Managerのデフォルト・ルールでは、認証アクションは必要ありません。
|
注意: Oracle Web Services Managerを使用している場合は、認可ルールが必要です。 |
認可条件式: 条件式を含むポリシーによってリソースが保護されている場合を除き、ポリシー・ドメインのデフォルト・ルールの認可条件式は、ドメイン内のすべてのリソースに適用されます。
「認可条件式」タブ→「追加」をクリックします。
「式」タブ: ステップ6で作成した認可ルールを選択します。
認可ルールDefault_OAM_IA_OWS_AuthZ_Ruleを選択します。
「追加」をクリックします。
「保存」をクリックします。
「アクション」タブ: ステップ6で、ルールの「アクセスの許可」部分を適用するユーザーを定義しました。ここでは、ルールと式の両方について、認証成功のアクションを指定します。
「アクション」→「追加」をクリックし、次のように認証が成功した場合に呼び出されるアクションを指定して、「認可成功」の戻りアクションを作成します。
認可成功: 「アクセスの許可」の条件に適用されます。
戻り型: WL_REALM
戻り名: uid
戻り属性: uid
「保存」をクリックします。
|
注意: 戻り属性 |
「ポリシー」タブ: ポリシーは必要ありません。デフォルト・ルールが適用されます。
委任アクセス管理: ポリシー・ドメインにURL接頭辞を追加する場合、委任アクセス管理者は、そのURL接頭辞をホスティングするサーバーを指定する必要があります。
|
関連項目: 『Oracle Access Managerアクセス管理ガイド』のポリシー・ドメイン管理の委任に関する項 |
ポリシー・ドメインの検証: 「ポリシー・ドメイン」をクリックし、作成した新しいポリシー・ドメインをクリックした後、「ページとして表示」をクリックしてすべての詳細をまとめて表示します。
Oracle Web Services ManagerがWebサービスを保護している場合に、Oracle Access Manager IDアサーション・プロバイダを使用するには、WebLogicドメインでいくつかの認証プロバイダを構成し、並べ替える必要があります。
この手順は、Oracle Access Manager IDアサーション・プロバイダの場合とほとんど同じです。この場合の相違点は、Oracle Web Services Managerはカスタム・アクセス・ゲートを必要とし、追加のプロバイダ固有の値が必要になることです。
プライマリ・アクセス・サーバー: ホストとポート番号を指定します。例: abcd:7777。
アクセス・ゲート名: アプリケーションを保護するアクセス・ゲートの名前。例: mmmm。
アクセス・ゲートのパスワード: アクセス・システム・コンソールで指定したアクセス・ゲート・パスワード。
これらは、Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して追加できます。
|
関連項目:
|
|
注意: Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダ・ファイルはすでにインストールされています。ステップ1を省略してください。 |
WebLogicドメインでプロバイダを設定するには
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。
Oracle Technology Networkにログインします:
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。例:
oamAuthnProvider<version>.zip
Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。
BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar
Oracle WebLogic管理コンソールにログインします。
OAM IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「新規」をクリックし、名前を入力してから次のプロバイダ・タイプを選択します。
名前: OAM Identity Asserter
タイプ: OAMIdentityAsserter
OK
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「共通」タブで、「制御フラグ」をREQUIREDに設定して「保存」をクリックします。
プラットフォーム固有のタブをクリックし、次のパラメータを構成します。
プライマリ・アクセス・サーバー: ホストとポート番号を指定します。例: abcd:7777。
アクセス・ゲート名: アプリケーションを保護するアクセス・ゲートの名前。例: mmmm。
アクセス・ゲートのパスワード: アクセス・システム・コンソールで指定したアクセス・ゲート・パスワード。
保存します。
OID認証プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator
タイプ: OracleInternetDirectoryAuthenticator
「OK」をクリックします。
認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。
「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。
「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。
ポート: LDAPホストのリスニング・ポート。例: 6050。
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。
資格証明: LDAPの管理ユーザー・パスワード。
ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。
すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))
ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。
グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)。
|
注意: デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。 |
「保存」をクリックします。
デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。
「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。
「保存」をクリックします。
プロバイダを並べ替えます。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。
「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: (REQUIRED)
OID認証プロバイダ: (SUFFICIENT)
デフォルトの認証プロバイダ: (SUFFICIENT)
「OK」をクリックして変更を保存します。
変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。
Oracle WebLogic Serverを再起動します。
次のようにします。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール」で説明されているように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
Oracle Web Services ManagerとOracle Access Manager IDアサーション・プロバイダとの併用を検証するには、IDアサーション・プロバイダとOracle Web Services Managerのポリシーによって保護されているWebサービスにアクセスします。アクセスが許可されれば、実装は機能しています。失敗した場合は、「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。
Fusion Middleware 11gには、コンテナ・ユーザー・セッションとSSOセッションを同期する新しいコンポーネントが導入されています。SSO同期フィルタは、Oracle WebLogicシステム・フィルタの実装です。SSO同期フィルタは、コンテナへのすべてのリクエストをインターセプトし、保護されたリソース・リクエストを操作して、コンテナのユーザー・セッションとOSSOのユーザー識別ヘッダー(Proxy-Remote-User)、またはOracle Access Manager SSOセッションCookie (ObSSOCookie)内のユーザー・データとの同期を試みます。
SSO同期フィルタは、Javaサーブレット仕様バージョン2.3に基づくサーブレット・フィルタの実装です。SSO同期フィルタにより、アプリケーションはSSOユーザー・セッションを追跡して各セッションと同期する必要がなくなります。アプリケーションは、コンテナのユーザー・セッションと同期するだけで済みます。
SSO同期フィルタは、コンテナへの各リクエストをインターセプトし、そのリクエストに添付されているHTTPヘッダーに基づいて操作するかどうかを決定します。フィルタは、SSOエージェントがこれらのヘッダーをWeb層で設定していることを必要とします。保護されていないアプリケーション領域にアクセスする場合、フィルタはパススルーとして機能します。保護されたリソースにアクセスした後、Web層のSSOエージェントは、Oracle Access ManagerなどのSSOシステムで認証を実行するようユーザーに指示します。認証後、Oracle Access Manager IDアサーション・プロバイダによってユーザー・アイデンティティがJAASサブジェクトとしてコンテナに確立され、ユーザー・セッションが作成されます。WebLogicでは、ユーザー・セッション・データがHTTPセッションCookieの一部(JSESSIONID)として保持されます。
アプリケーション・リソースへの後続アクセスでは、SSO同期フィルタに次の2つの情報が提供されます。
OSSOのユーザー識別ヘッダー(Proxy-Remote-User)
Oracle Access Manager SSOセッションCookie (ObSSOCookie)内のユーザー・データ
SSO同期フィルタの役割は、コンテナのユーザー・アイデンティティとSSOセッションのユーザー・アイデンティティが一致していることを確認することです。不一致がある場合、フィルタはそのコンテナのユーザー・セッションを無効にします。このため、ダウンストリーム・アプリケーションはコンテナのユーザー・セッションを追跡するだけで済み、使用しているSSO環境に関係なく一貫した方法で作用できます。
注意:
デフォルトで有効: SSO同期フィルタは、構成されたトークンからユーザー情報をフェッチし、既存セッション(存在する場合)からユーザーを取得し、CurrentSessionUserが着信SSOユーザーと一致していない場合はセッションを無効にしてリクエストされたURLにリダイレクトします。そうでない場合、リクエストは単にパススルーされます。
ドメインでOSSOまたはOracle Access Managerアサーション・プロバイダを構成していない場合、フィルタはWebLogic Serverの起動中に自動的に無効になります。
デフォルトですべてのURIに対して有効(/*): アプリケーション・コードでの変更は不要です。
OSSOトークン/ヘッダーに対する構成: Proxy-Remote-Userが検索され、大/小文字を区別しない一致が実行されます。
Oracle Access Manager SSOトークン/ヘッダーに対する構成: OAM_REMOTE_USERとREMOTE_USERが検索され、大/小文字を区別しない一致が実行されます。
グローバル・ログアウト: SSO同期フィルタは、OSSOまたはOracle Access Managerソリューションを使用するOracle Fusion Middlewareアプリケーションに対してシングル・ログアウト操作を提供します。これは、シングル・サインオンと同様に処理されます。グローバル・ログアウトが実行されると、セッションのクリーンアップが実行されていないアプリケーションに対して後続アクセスが行われたときに、SSOフィルタによってセッションが調整されます。
OSSOまたはOracle Access Managerソリューションを使用するアプリケーションは、OSSOログアウトまたはOracle Access Managerログアウトのコールを実行する前にそのセッションを無効にする必要があります。OSSOログアウトの詳細は、例18-2「動的ディレクティブによるSSOログアウト」を参照してください。Oracle Access Managerログアウトの詳細は、「Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成」を参照してください。
アプリケーション・セッション・タイムアウト: 通常、SSO Cookieはユーザーの非アクティブ/アイドル・タイムを追跡し、タイムアウトが発生した場合はユーザーにログインを要求します。OSSOとOracle Access Managerも例外ではありません。Oracle Access Managerでは、より高度なアプローチが採用されており、SSOセッションの作成時間と最終リフレッシュ時間に加えて、最大アイドル・セッション時間と最長アイドル・セッション時間が追跡されます。
独自のセッションを保持しているアプリケーションとSSOシステムの統合に関する一般的な推奨事項は、SSOのセッション・タイムアウトとアプリケーションのセッション・タイムアウト間で一貫した操作性が得られるように、アプリケーションのセッション・タイムアウトをSSOのセッション・タイムアウトに近い値に構成することです。
様々な優先システム・プロパティをWebLogicに渡すことにより、アプリケーションの要件に応じてSSO同期フィルタの動作を変更できます。このためには、Oracle WebLogic起動スクリプトを変更して、setDomainEnv.shにEXTRA_JAVA_PROPERTIESがあるか確認します。表17-12に、各プロパティと同期動作を示します。
表17-12 SSO同期フィルタの各プロパティと同期動作
| 領域 | 優先システム・プロパティ | システム・プロパティのデフォルト値 | 同期フィルタのデフォルト動作 |
|---|---|---|---|
|
ステータス(有効または無効) |
sso.filter.enable |
構成なし |
有効 |
|
大/小文字を区別した一致 |
sso.filter.name.exact.match |
構成なし |
大/小文字を区別しない一致 |
|
構成されたトークン |
sso.filter.ssotoken |
構成なし |
|
|
URIマッピング |
なし |
なし |
/* |
一部のアプリケーションに対してフィルタを有効にすることはできません。SSO同期フィルタは、システム・フィルタです。このため、デプロイされているすべてのアプリケーションに対して有効になります(URIマッピングは/*)。
|
注意: 一部のアプリケーションに対してフィルタを有効にすることはできません。 |
次の手順に、SSO同期フィルタのプロパティと動作の変更に関するヒントを示します。
SSO同期フィルタのプロパティと動作を変更するには
フィルタの無効化: システム・プロパティsso.filter.enableをfalseに変更し(jvmに-Dとして渡す)、Oracle WebLogic Serverを再起動します。これにより、フィルタ・ステータスが切り替わります。
ユーザー識別ヘッダーと事前構成済同期フィルタ・トークンの不一致: システム・プロパティsso.filter.ssotokenを使用して、同期フィルタによって検索されるSSOトークンを上書きします。
たとえば、WebLogic Serverの起動スクリプト(-Dsso.filter.ssotoken=HEADERNAME)でWebLogic Server JVMに渡し、サーバーを再起動します。
Oracleサポート・サービスにお問合せの際は、「WebLogic管理コンソールでのデバッグの設定」の説明に従ってデバッグを設定するように求められる場合があります。
この項には次のトピックが含まれます:
Oracle Fusion MiddlewareとOracle Access Managerは、Internet Protocol Version 4 (IPv4)とInternet Protocol Version 6 (IPv6)をサポートしています。IPv6の特筆すべき機能は、Pv4 (32ビット)よりも大きいアドレス空間(128ビット)をサポートしていることです。これにより、Web上でアドレッシングできるコンピュータの数が飛躍的に増えます。
|
関連項目: IPv6使用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。 |
Apacheブリッジが失敗する場合、接続できるバックエンド・サーバーが存在しないことを示すメッセージが表示されることがあります。この場合、接続はタイムアウトします。
Oracle WebLogic Serverが停止しているか、mod_weblogicに不正な値が設定されている可能性があります。
Apacheブリッジの失敗からリカバリするには
Oracle WebLogic Serverが使用可能であることを確認します。
WebゲートのWebサーバーのhttpd.confで、ホスト情報とポート情報が正しく指定されていることを確認します。例:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
<IfModule mod_weblogic.c>
WebLogicHost yourHost.yourDomain.com
WebLogicPort yourWlsPortNumber
</IfModule>
認証されたユーザーが、リクエストしたリソースへのアクセス権限を持っていない可能性があります。
ユーザー・ログインが決定的ではない場合や無効な場合、ユーザーは認証されますが、リスエストしたリソースに対して認可されたとは認識されません。この場合、問題を指摘する明示的なエラー・メッセージは表示されません。かわりに、再度ログインするよう求められます。
認証に成功した後、ブラウザ・ウィンドウの「戻る」ボタンを押すと、access/oblix/apps/webgate/bin/webgate.soに対するエラーが表示されることがあります。
フォームベース認証を使用している場合、Oracle Access Managerにより、リクエストされたリソースに関する情報を保持するフォーム・ログインCookieが作成されます。認証に成功すると、Cookieの状態が変更されます。ユーザーが「戻る」ボタンをクリックすると、ログイン・フォームが表示されます。再ポストされると、フォーム・ログインCookieにはリダイレクトの詳細が含まれなくなります。
また、フォーム・ログインCookieと一緒にObSSOCookieも送信されます。ObSSOCookieは正しくチェックされます。フォーム・ログインCookieの状態が変更されているため、フォームベース認証は行われず、フォーム・アクションはリソースのリクエストとみなされます。
解決策
元のURLを使用して、リクエストを再試行してください。
Oracle Access Managerの認証プロバイダ・フラグがREQUIREDに設定されている場合、またはOracle Access Manager認証プロバイダのみが使用可能な場合、このタスクに対する実行権限を持っている管理者グループにOracle WebLogic Serverを起動するLDAPユーザーが含まれるように、次の手順を実行します。デフォルトでは、Oracle WebLogic ServerのAdminロールに管理者グループが含まれています。
その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。
WebLogic Serverを再起動できるようにするには
管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ(または、起動権限を付与する必要があるその他のグループ)を作成します。
Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。
WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ロールとポリシー」→「グローバル・ロール」を選択します。
Adminロールの「構成の表示」を選択します。
グループを追加して「保存」をクリックします。
初期状態のOracle Access Managerでは、ロード・バランシングされるアクセス・ゲートはサポートされていません。かわりに、サード・パーティのロード・バランサを使用する必要があります。
WebGateAおよびWebGateBという2つのWebゲートがあるとします。OAMCfgToolを使用して、2つのWebゲートで共有されるプロファイルを作成できます。
Oracle Fusion Middlewareアプリケーションをインストール済の場合、OAMCfgToolはすでにインストールされています。この場合、手順1を省略します。
解決策:
Oracle Fusion Middlewareアプリケーションがない場合: Oracle Fusion Middlewareアプリケーションがインストールされていない場合には、OAMCfgToolを入手します。
Oracle Technology Networkにログインします:
http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html
Access Managerのコア・コンポーネント(10.1.4.3.0)を使用してOAMCfgTool ZIPファイルを見つけます。
oamcfgtool<version>.zip
oamcfgtool.jarを抽出し、Webゲートをホスティングしているコンピュータにコピーします。
WebGateAのコンピュータにログインします(Webゲートがまだインストールされていない場合も含む)。
OAMCfgToolが含まれているファイル・システム・ディレクトリに移動し、次のようなコマンドを実行して、2つのWebゲートによって共有される1つのアクセス・ゲート・プロファイルを作成します。例:
java -jar oamcfgtool.jar mode=CREATE app_domain=SharedA_B app_agent_password=<WebGate_password> cookie_domain=<preferred_http_cookie_domain> ldap_host=wxyz ldap_port=6633 ldap_userdn=orcladmin ldap_userpassword=<ldap_userpassword> oam_aaa_host=abcd oam_aaa_port=7789 oam_aaa_mode=cert log_file=OAMCfg_date.log log_level=INFO output_ldif_file=<LDIF_filename>
このツールで指定した情報を確認します。たとえば、ステップ3のパラメータと値は次のとおりです。
Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation.
Operation Summary:
Policy Domain : SharedA_B
Host Identifier: SharedA_B_WD
Access Gate ID : SharedA_B_AG
|
注意:
|
出力LDIFの作成: LDIFをインポートし、その情報をディレクトリ・サーバーに書き込みます。該当しない場合は、この手順を省略します。
Webゲートがインストールされていない場合: WebGateAとWebGateBをインストールし、プロファイルの作成時に指定した値と同じ値(および、インストールの正常完了に必要なその他の値)を指定します。
Webゲートがインストールされている場合: OAMCfgToolのCreateコマンド出力を使用してOracle Access ManagerのconfigureWebGateツールを実行し、Webゲートを設定します。例:
次の場所に移動します。
WebGate_install_dir\access\oblix\tools\configureWebGate
ここで、WebGate_install_dirは、Webゲートのインストール先ディレクトリです。
次のコマンドを実行し、OAMCfgToolで指定した値とインストールの完了に必要なその他の値を使用して、Webゲートを構成します。例:
configureWebGate -i WebGate_install_dir -t WebGate SharedA_B_AG -P WebGate_password -m <open|simple|cert> -h Access_Server_Host_Name -p Access_Server_Port -a Access_Server_ID -r Access_Server_Pass_Phrase (must be the same as the WebGate_password) -Z Access_Server_Retry count
|
関連項目: 『Oracle Access Managerアクセス管理ガイド』のアクセス・ゲートとWebゲートの構成に関する項 |
前述の手順を繰り返して、WebGateBを構成します。
アクセス・システム・コンソールでのプロファイルの確認: 次の手順を実行して、Webゲート・プロファイルを表示または変更します。
マスター・アクセス管理者または委任アクセス管理者として、アクセス・システム・コンソールにログインします。例:
http://hostname:port/access/oblix
hostnameはWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。
「アクセス・システム構成」をクリックし、「アクセス・ゲート構成」をクリックします。
「すべて」ボタンをクリックしてすべてのプロファイルを検索し(または、リストから検索属性と条件を選択し)、「実行」をクリックします。
Webゲートの名前をクリックして、その詳細を表示します。
「取消」をクリックしてこのページの変更内容を消去するか、「変更」をクリックして、『Oracle Access Managerアクセス管理ガイド』の説明に従って値を変更します。
ロード・バランサのホスト識別子に、両方のWebゲートのホスト名バリエーション(WebGateAおよびWebGateB)を追加します。
次のようなエラー・メッセージが表示されます。
401 Authorization Required
これは通常、Oracle Access Manager認証プロバイダが正しく構成されていないことを意味します。正しい構成のリストについては、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。
次のようなエラー・メッセージが表示されます。
403 Forbiden
これは通常、ポリシー・ドメインで認証後のアクションが正しく構成されていないことを意味します。ポリシー・ドメインの認証成功アクションで、(「戻り値」フィールドではなく)「戻り属性」フィールドにobmygroupsとuidが設定されていることを確認してください。
詳細は、「Oracle Access Manager認証プロバイダのポリシー・ドメインの構成」を参照してください。
このエラーは通常、サーバーがリクエストURIに合致するものを見つけられなかったことを示します。このメッセージは、Oracle WebLogic Serverがリソースを見つけられないことを通知します。
状況が一時的であるか、永続的であるかどうかは示されません。
サーバーが一時的または永続的にクライアントに情報を提供できない場合、ステータス・コード403 (Forbidden)が使用されることがあります。
内部的に構成できるなんらかのメカニズムによって、古いリソースが永続的に使用不可で、転送アドレスが存在しないことを通知できる場合は、410 (Gone)ステータス・コードが使用されます。
エラー404からリカバリするには
リソースがOracle WebLogic Serverにデプロイされていることを確認します。たとえば、パターンが/private1/Helloである場合、ルートがprivate1のサーバー上でHelloにアクセスできるかどうかを確認します。
この問題は、Oracle Access Managerでフォーム認証スキームが適切に構成されていない場合に発生します。ただし、OAMCfgToolを使用してポリシー・ドメインを設定する場合、この問題は発生しません。例:
次のような兆候があります。
ログイン・フォームの「ユーザー名」フィールドと「パスワード」フィールドが、フォーム認証スキームの詳細と合致している必要があります。
フォーム認証スキームで、credential_mappingフィルタが正しく指定されている必要があります。
ログイン・フォームのアクションURLがポリシーによって保護されている必要があります。
ログイン・フォームのアクションURLが、認証スキームのチャレンジ・パラメータに指定されたアクション値と合致している必要があります。
WebLogic ServerユーザーがOracle Access Managerの管理者グループに含まれていない場合、Oracle WebLogic Serverが再起動し、認証プロバイダの初期化に失敗する可能性があります。この場合、$DOMAIN_HOME/servers/AdminServer/logs/AdminServer.logのAdminServer.logに、次のいずれかのメッセージが表示されます。
)<Failed ---- FatalError:InvalidSchemeMapping ... Authentication Failed. ... Login failed. ...
解決策
実装で、Oracleが提供するデフォルト・ログイン・フォームが使用されていることを確認します。
Oracle Access Managerアイデンティティ・システムでAdministratorsという名前のグループを作成し、Oracle WebLogic Serverユーザーを含めます。
|
関連項目: 「Oracle Access Manager IDおよび共通管理ガイド」 |
Oracle Access Managerアイデンティティ・システム内で定義されたAdministratorsグループに属するユーザーの資格証明を使用して、Oracle WebLogic Serverにログインします。
Oracle WebLogic Serverを再起動します。
このフラグをREQUIREDに設定し、他のパラメータを不適切な値に設定した場合、サーバーは起動しません。
この問題を回避するには、このパラメータ値をOPTIONALに設定して、Oracle Access Manager認証プロバイダが適切に構成されていることを確認します。この方法で適切に動作することを確認した後にのみ、制御フラグをREQUIREDにリセットしてください。
詳細は、「WebLogicドメインでの認証プロバイダの構成」を参照してください。
この問題は通常、ユーザー名またはパスワードが正しくないことを示しています。エラーは表示されません。
正しいユーザー名とパスワードが入力されていることを確認してください。ユーザーのログイン名は、フォーム・ログイン認証スキームで構成された属性の値である必要があります。たとえば、チャレンジ・パラメータcreds: useridのようになります。
ユーザーがログアウトした場合、またはユーザーのセッションがタイムアウトした場合は、ユーザーは再認証を要求されます。ただし、次のことが発生する場合があります。
ログアウト: ログアウトした後、ユーザーが同じブラウザ・ウィンドウでアプリケーションにアクセスしようとすると、再認証なしでアプリケーションにアクセスできます。
セッション・タイムアウト: ユーザーがセッション・タイムアウトした後、再認証が要求されます。ただし、ユーザーが別のユーザーIDを入力した場合に、前のユーザーと同じ権限が付与されます。
ObSSOCookieがまだ存在しています。ObSSOCookieをクリアするには、いくつかの構成をアプリケーション・レベルで行う必要があります。適切に動作させるには、WebLogicアプリケーションのセッション・タイムアウト値とWebゲートのセッション・タイムアウト値を合致させる必要があります。
WebLogicアプリケーション・コンソールでIDアサーション・プロバイダを設定している場合、IDアサーション・プロバイダを使用するWebアプリケーションのauth-methodがCLIENT-CERTに設定されている必要があります。詳細は、「Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成」を参照してください。
リクエストされたURLまたはリソースがこのサーバーに見つからなかったことを示すメッセージが表示された場合、リバース・プロキシWebサーバーがリクエストをOracle WebLogic Serverに転送していない可能性があります。
リバース・プロキシがリクエストをOracle WebLogic Serverに転送していることを確認するには
リバース・プロキシWebゲートのWebサーバーで、httpd.confファイルを検索します。例:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
Oracle WebLogic Serverの正しいホストとポートにリクエストが転送されるように、正しく設定されていることを確認します。
#httpd.conf
<IfModule mod_weblogic.c>
WebLogicHost <host>
WebLogicPort yourWlsPortNumber
</IfModule>
<Location /request-uri-pattern>
SetHandler weblogic-handler
</Location>
Oracle WebLogic Serverの起動に失敗する場合、次の操作を実行できます。
Oracle Access Manager認証プロバイダが、Oracle WebLogic Serverレルムに構成されている唯一のプロバイダであるかどうかを確認します。そうである場合は、ステップ2に進みます。
Oracle Access Manager認証プロバイダが正しく構成されていることを確認し、必要に応じて変更します。
Oracle Access Manager認証プロバイダの制御フラグがREQUIREDに設定されているかどうかを確認します。設定されている場合は、次の手順を実行します。
管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ(または、起動権限を付与する必要があるその他のグループ)を作成します。
|
注意: その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。 |
Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。
WebLogic管理コンソールで、「セキュリティ・レルム」→「Your Realm」→「ロールとポリシー」→「グローバル・ロール」を選択します。
管理者(またはその他の)ロールの「条件の表示」を選択します。
グループを追加して「保存」をクリックします。
問題
Microsoft Officeドキュメント(.xls、.docなど)をダウンロードできる特定のURLにアクセスしたときに、Webゲートのキャッシュ・ディレクティブの構成が特定のブラウザのバージョン(特にInternet Explorer v7)に対応していない可能性があります。
たとえば、Oracle Access Managerの証明書ベースの環境に、Oracle ADFアプリケーションと一緒にExcelワークブックがデプロイされているとします。
ADFDiコンポーネントが2つのURLにアクセスする際に、2番目のURLへのアクセスを先に試行すると、ADFDiのクライアント側のコードに関係なく失敗します。Oracle Access Manager WebゲートからSSL対応エンドポイントへのリダイレクトを処理できずに失敗し、次のスタック・トレースが生成されます。
WebException: The request was aborted: Could not create SSL/TLS secure channel
ワークブックにアクセスしようとすると、次のメッセージが表示されます。
Microsoft Office Excel cannot access the file
次の原因が考えられます。
ファイル名またはパスが存在しません。
ファイルが別のプログラムによって使用されています。
保存しようとしているワークブックと現在開いてるワークブックの名前が同じです。
ただし、ワークブックのURLをInternet Explorer v7のアドレス・バーに明示的に貼り付けたときにこのメッセージが表示された場合は、Webゲートのデフォルト・キャッシュ・ディレクティブが原因である可能性があります。
Webゲートには、デフォルト・キャッシュ・ディレクティブ(Pragma=no-cacheおよびCacheControl=no-cache)があります。これらは、Internet Explorer v7で.xlsワークブックのURLをブラウザのアドレス・バーに直接貼り付けた場合に問題を引き起こします。
解決策
ワークブックのURLをInternet Explorer v7のアドレス・バーに明示的に貼り付けたときにこのメッセージが表示された場合は、アクセス・システム・コンソールのWebゲート構成の各ページからキャッシュ・ディレクティブを削除することをお薦めします。
各Webゲート構成からキャッシュ・ディレクティブを削除するには
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
「アクセス・ゲート構成」をクリックし、検索ページの「実行」をクリックした後、該当するアクセス・ゲート構成ページへのリンクをクリックします。
「アクセス・ゲートの詳細」ページで、「変更」をクリックします。
「アクセス・ゲートの変更」ページで「Webサーバー・クライアント」ラベルを検索し、次のフィールドをクリアします。
CachePragmaHeader
CacheControlHeader
「保存」をクリックします。
OAMポリシーは、渡されたURIに基づいて評価されます。以前のリリースでは*;jsessionid*を保護するポリシーがありませんでした。アプリケーション・リソースURLへのアクセス時にJSESSIONID Cookieが見つからない場合、WebLogic Serverは、JSESSIONIDをURLの一部として含めてURLの書込みを行います。対象のURLが保護されているときは、Oracle Access ManagerとOSSO Webエージェントでは書き込みなおされたURLのマッチングが困難になる場合があります。
このリリースでは、コンテキスト・ルートの下位のすべてのURIに対してパターン「*;jessionid=*」を使用するポリシーが新たに提供されています。このため、コンテキスト・ルートにあり、「;jsessionid=string」が追加されたすべてのURIが保護されていると見なされます。
/context-root自体をリソースとしてリストする必要があります。URLパターンは、*;jsessionid=*です。デフォルトの認証ルールは、保護された認証スキームです。また、デフォルトの認可条件式も使用されます。ポリシーの順序付けでは、このポリシーを第1にする必要があります。
/test/protectedUriという名前の保護されたリソースと/testという名前の公開リソースがあるとします。パターン*jessionid;*で公開ポリシーを作成し、このポリシーをこの両リソースに適用すると、公開ポリシーが公開リソースより優先されます。
/test;jessionid=blahがリクエストされた場合、OAMではまず「/test;jessionid=blah」のデフォルト・ルールの有無がチェックされます。このルールがない場合は次に「/」のルールの有無がチェックされます。このルールもない場合、「/test;jessionid=blah」は保護されていないと見なされます。
「/test/protectedUri;jessionid=blah」がリクエストされると、OAMはこれを保護するデフォルトのルールの有無をチェックします。このルールがない場合は、「/test」のルールの有無をチェックします。リソース・リストに「/test」が存在する場合は、さらに適用されるポリシーが判定されます。この例の場合は、jessionidポリシーが適用され、リクエストが保護されていると見なされます。
