| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11g リリース1(11.1.1) B56235-06 |
|
 前 |
 次 |
ここでは、Oracle Access Manager 11gを使用したシングル・サインオンの構成について説明します。内容は次のとおりです。
Oracle Access Manager 11gは、Oracleのエンタープライズ・クラス・スイートのセキュリティ製品に属しています。新規のSSOデプロイメントと既存のSSOデプロイメントでの使用を目的としたOracle Access Manager 11gは、Webシングル・サインオン、認証と認可、ポリシー管理などの広範なWeb境界セキュリティ機能を提供します。
Oracle Access Manager 11gシングル・サインオン(SSO)およびシングル・ログアウト(SLO)は、次のような様々なアプリケーション・プラットフォームをサポートします。
SOA
WebCenter
Oracle Fusion Middleware Oracle Access Manager統合ガイドの説明にあるように、Oracle Access Manager 11gは次のような様々なアプリケーションとの統合をサポートしています。
Oracle Identity Navigator
Oracle Identity Federation
Oracle Identity Manager
Oracle Adaptive Access Manager
Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドに説明されているように、Oracle Access Manager 11gがOracle Access Manager 10gと異なる点は、アイデンティティ管理機能がOracle Identity Manager 11gに移行されていることです。ユーザー・セルフサービスおよび自己登録、ワークフロー機能、動的グループ管理、アイデンティティ管理の委任などの機能があります。
Oracle Identity Managementアプリケーションのコンソール保護
Oracle Access Manager 11gおよびその他のOracle Identity Managementアプリケーションは、WebLogicコンテナにデプロイされています。個々の管理コンソールには、Oracle Access Manager、Oracle Adaptive Access Manager、Oracle Identity Navigator、Oracle Identity Manager、Oracle WebLogic Server、Oracle Entitlements Serverなどがあります。
これらは、デフォルトで、WebLogic管理コンソールの事前構成済の認証プロバイダおよび事前登録済のOracle Access Manager 11gのIAMSuiteAgentで保護されています。OAM 11g SSOポリシーは事前シード済です。コンソールをこれ以上構成する必要はありません。
|
関連項目: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド |
OAM 11gデプロイメントのプレビュー
新規WebLogic管理ドメインまたは既存のWebLogic管理ドメインで、Oracle Fusion Middleware構成ウィザードを使用してOracle Access Managerを構成できます。
「Oracle Access Managerで使用されるプロバイダの要件」を参照してください。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』 |
Oracle Access Manager 11gには、新規または既存のポリシー適用エージェントとの下位互換性を保持する新しいサーバー側のコンポーネントが用意されています。サーバー側で開始する動的な更新が、ポリシーや構成に対するあらゆる変更で実行されます。
OAM 10gポリシー・マネージャにかわって、Oracle Access Managerコンソール(WebLogic管理サーバーにインストール)が稼働します。
OAM 10gアクセス・サーバーにかわって、OAMサーバー(WebLogic管理対象サーバーにインストール)が稼働します。
Oracle Access Manager 11gは、リソースを保護する次のような登録済エージェントの任意の組合せに対し、シングル・サインオン(SSO)、認証、その他の認可などのサービスを提供します。
11g Webゲート
10g Webゲート
JavaベースのIAMSuiteAgent
OSSOエージェント(10g mod_osso)
Oracle Access Manager 11gは、現在Oracle ADFのセキュリティとOPSS SSOフレームワークを使用しているどのWebアプリケーションとも統合できます。
Oracle Access Manager管理コンソールへのログインやOAM管理コマンドライン・ツールの使用は、適切な権限を持ったユーザーにのみ許可されています。企業によっては、OAM管理を担当するユーザーとWebLogic管理を担当するユーザーに別の管理者グループが必要になることがあります。詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの新しいOAM管理ロールの定義に関する項を参照してください。
OAM 11gの概要
Oracle Access Manager 11gの基本機能の概要は、次のとおりです。
プロビジョニング/リモート登録: 新しいリモート登録ツールにより、ネットワーク内外の管理者はエージェントとポリシーを登録できます。OAM 11gのプライマリ・ユーザー・アイデンティティ・ストアにユーザー名とパスワードを設定する必要があります。
認証: Oracle Access Manager 11gアプリケーション・ドメインは、リソースとセキュリティ・ポリシー(リソースごとに1つのポリシー)を集約します。Oracle Access Manager 11gの認証ポリシーには、固有のスキームがあります。サポートされる認証モジュールには、LDAP、X.509、Kerberosなどがあります。認証ユーザーは、集中管理された資格証明コレクタによってプライマリ・ユーザー・アイデンティティ・プロバイダにマッピングされます。
認可: アプリケーション・ドメインで定義して、データベースで永続化したセキュリティ・ポリシーに基づいて、Oracle Access Manager 11gで認可が実行されます。認可ポリシーはリソースと制約の評価を定義します。
レスポンス: 管理者は、認証レスポンスと認可レスポンスを使用してセッション属性を設定できます。セッションの属性以外に、ユーザー関連のデータおよびリクエスト関連のデータもレスポンスで取得できます。設定したレスポンスは、その立証に効果的なエージェントにHTTPヘッダーまたはCookieとして送信されます。Cookieの値およびヘッダーの変数に対し、レスポンスは別のレスポンスで事前に設定されたセッション属性を取得できます。たとえば、レスポンスによって認証時に設定されたセッション属性を、認可の際にヘッダー値として取得できます。
セッション管理: Oracle Access Manager 11gセッション管理サービスでは、Oracle Coherenceのテクノロジに基づく高パフォーマンス分散キャッシュ・システムを介してアクティブ・ユーザー・セッションを追跡します。各Oracle Access Managerの実行時インスタンスは、この分散キャッシュ・システムにあるノードとなります。これらのノード間のセキュアな通信は、対称鍵を使用すると容易に実行できます。Oracle Access Managerの実行時インスタンスは、ローカルのキャッシュにあるユーザー・セッション・データを分散キャッシュに移動して、他のノードから選択できるようにします。また、Oracle Access Managerの実行時インスタンスごとにレプリケーション・ファクタを構成して、セッション・データをどのように分散するかを指定することもできます。管理者は、セッションのライフサイクルの構成、固有のアクティブ・セッションの検索と削除、任意の時点でユーザーが同時に実行できるセッション数の制限などが可能です。バンド外のセッションを終了すると、ユーザーがセッションを終了した後でシステムへの認可されないアクセスを防止します。
キー: Oracle Access Manager 11gのランタイムは、アプリケーションとしてWebLogic管理対象サーバーまたはクラスタにデプロイされます。新しいOracle Access Manager 11g WebGatesは、エージェントの信頼モデルごとに機密情報の共有をサポートします。11g Webゲートでは、エージェントとホストに固有のCookieを使用して優れたセキュリティを実現できます。Oracle Access Manager 11g Webゲートは、すべて同レベルで信頼されます。Webゲートにはそれぞれに固有のCookieが設定されるので、あるWebゲートのCookieを使用しても、他のWebゲートで保護されたアプリケーションにユーザーにかわってアクセスすることはできません。これにより、Cookieリプレイ・タイプの攻撃から防御できます。
SSOおよびSLO: Oracle Access Manager 11gサーバー・セッション・トークンは、Oracle Access ManagerとOSSOエージェント間のSSOの基礎を形成します。ログアウトは、Oracle Access Manager 11gサーバーのグローバル・ログアウトで実行します。これにより、中央のセッションは終了し、ユーザーはアクセスした各エージェントからログアウトします。
Oracle Access Manager 10g Webゲートでは、ログアウトによりObSSOCookieが削除され、「グローバル・ログアウト」ページにリダイレクトされます。
Oracle Access Manager 11gのWebゲートおよびmod_ossoエージェントでは、ログアウトは「グローバル・ログアウト」ページにリダイレクトされ、各エージェントはエージェント固有のCookieを削除するためにコールバックされます。
ロギングと監査: Oracle Access Manager 11gコンポーネントでは、Oracle Fusion Middleware 11gの他のコンポーネントと同じロギング・インフラストラクチャとロギング・ガイドラインを使用します。Oracle Access Manager 11gでは、エージェントとサーバーの監視機能が用意されています。Oracle Access Manager 11gの監査機能は共通監査フレームワークに基づいています。監査レポートの生成は、Oracle Business Intelligence Publisherによりサポートされています。
アクセス・テスター: Oracle Access Manager 11gの新しいアクセス・テスターを使用すると、IT専門家や管理者は登録されたOracle Access Managerエージェントとサーバー間の相互作用をシミュレートできます。これは、セキュリティ・ポリシー定義のテストやエージェントの接続が関係する問題のトラブルシューティングで役立ちます。
テストから本番への移行: Oracle Access Manager 11gを使用して、構成やポリシーのデータを1つのOracle Access Manager 11gデプロイメントから別のデプロイメントに移動できます(小規模なテストデプロイメントから本番デプロイメントへの移動など)。テンプレートに基づく新規トポロジの作成がサポートされています。ポリシーに対する変更のコピーや移動も可能です。
OSSO 10gとの共存およびOSSO 10gのアップグレード: Oracleが提供するUpgrade Assistantは、既存のOracleAS 10g SSOサーバー構成をスキャンし、10g OSSOポリシー・プロパティ・ファイルおよびスキーマ情報を入力として受け入れ、構成済のパートナ・アプリケーションを移行先のOracle Access Manager 11g SSOに転送します。
|
関連項目:
|
この項の操作は、10gカスタム・アクセス・ゲートでのみ必要です。ご使用の環境に当てはまらない場合は、この項は省略してください。
Application Authenticatorアプリケーション・ドメインはOAM 11gで提供されます。これは、OAM認証プロバイダをセキュリティ・プロバイダとしてWebLogic環境にデプロイしたアプリケーションとの統合を実現するポリシー・オブジェクトによって事前シードされています。これは、Webゲートのプロビジョニングに関連付けられていません。このドメイン(または既存のアプリケーション・ドメイン)を使用するためにWebゲートまたはアクセス・ゲートをプロビジョニングする際には、自動的に作成されたポリシーを拒否します。
OAM認証プロバイダ(およびOracle Web Services Manager用IDアサーション・プロバイダ)で使用するカスタムの10gアクセス・ゲートで、Application Authenticatorアプリケーション・ドメインが機能するようになりました。この場合、カスタムのアクセス・ゲート(Webゲートではありません)が、OAM 11gにアクセスする前のユーザーを認証するためのトークンを使用して、WebLogic Serverに直接アクセスします。
Application Authenticatorアプリケーション・ドメインは、タイプwl_authenのリソースのみを保護し、2つの認証ポリシーと1つの認可ポリシーでシードされます。次のwl_authenリソースもこのドメインにシードされます。
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion (LDAPNoPasswordValidationSchemeによって保護)
|
注意: このドメインで許可されているのは、タイプwl_authenのリソースのみです。他のリソース・タイプは追加できません。wl_authenリソースのポリシーとレスポンスは追加可能です。ただし、このドメインの変更が不要であることが理想です。 |
図16-1は、OAM 11g管理コンソールのシードされたApplication Authenticatorアプリケーション・ドメインの詳細を示しています。このページは、/Authen/UsernameAssertionリソースを保護する、事前シード済の認証ポリシーUser ID Assertionを示しています。このポリシーで保護しているリソースのほかに、ポリシーの認証スキームも表示されています。
図16-2は、User ID Assertion認証ポリシーに事前シードされたレスポンスを示しています。レスポンスの詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。
図16-3は、事前シード済の認証ポリシーApplication SSO、このポリシーで保護されたリソースおよび認証スキームを示しています。
図16-4は、アプリケーション・ドメインに事前シードされた認証ポリシーApplication SSOのレスポンスを示しています。
図16-5は、アプリケーション・ドメインで事前シードされた認可ポリシーApplication SSOとリソースを示しています。
認可の制約: このアプリケーション・ドメインには、事前シード済の認可ポリシーApplication SSOの制約がありません。ただし、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドで説明されているように、制約を追加することはできます。
認可のレスポンス: このアプリケーション・ドメインには、事前シード済の認可ポリシーApplication SSOの制約がありません。ただし、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドで説明されているように、レスポンスを追加することはできます。
この項では、WebLogicコンテナにデプロイしたアプリケーションまたはそこにデプロイする予定のアプリケーションがある場合に、認証プロバイダでOAM 11gを実装する方法を説明します。
この項の内容は次のとおりです。これらは、アプリケーションをWebLogicコンテナにデプロイする場合のOAM 11g SSOの実装で役に立ちます。ここで取り上げているOAMソリューションの実装は、OAM 11gに固有なもの以外は、OAM 11gとOAM 10gのどちらでも同じです。
|
関連項目: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのOAMトークンを使用したID伝播のシナリオの詳細に関する項 |
次の概要では、認証プロバイダを使用してOracle Access Manager 11g SSOソリューションに必要なコンポーネントとファイルをインストールする際に完了する必要があるタスクについて説明します。Oracle Access Manager 11gとOracle Access Manager 10gとでは、これらのタスクの多くはほとんど同じですが、いくつかの相違点があります。
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOracle Access Manager 11gのインストールと初期構成の詳細に関する項 |
タスクの概要: 認証プロバイダおよびOAM 11gで使用するコンポーネントのインストール
Oracle Access ManagerのOracle Internet Directoryをインストールおよび設定します。
|
関連項目:
|
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ファイルを入手する必要があります。 |
必要に応じて、Oracle Access Manager Webゲート用にOHS 11gをインストールします。
IDアサーション・プロバイダ: Oracle HTTP Server 11gのWebサーバーが、Oracle WebLogic Serverのフロントエンドにリバース・プロキシとして構成されている必要があります。
Webゲート: OAM IDアサーション・プロバイダでIDアサーションを行うために、OHS Webサーバー上に境界Webゲートがインストールおよび構成されている必要があります。
認証プロバイダまたはOracle Web Services Manager: カスタム・アクセス・ゲートでは、Webサーバーは必要ありません。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。
認証プロバイダ・ファイル: 次のように必要なJARファイルとWARファイルを確認します。
次のFusion Middlewareパスで、必要なJARファイルの場所を確認します。
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.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 11g:
『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』で説明されているように、Oracle Access Managerをインストールして、初期構成を実行します。
トラステッド・ヘッダー・アサーション: My Oracle Support(http://support.oracle.com)にアクセスし、バンドル・パッチ02 (Oracle Access Manager Bundle Patch 11.1.1.5.2)を入手し、付属のreadmeファイルの説明に従って適用します。
認証プロバイダ(またはOracle Web Services Manager)用のアクセス・ゲート:
「セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング」に説明されているように(または、認証プロバイダの構成時に既存のOAMエージェントの登録を参照)、10gアクセス・ゲートをプロビジョニングできます。
oamAuthnProvider.jarで使用できるカスタム10gアクセス・ゲートをデプロイします。
すべてのJavaコンポーネントおよびアプリケーションでキーストア形式としてJKSを使用することをお薦めします。この項では、Oracle Access Manager X.509証明書をJavaキーストア(JKS)形式に変換する手順について説明します。この手順に適切に従うことで、Java NAPクライアントがOAMサーバーと簡易モードまたは証明書モードで通信するときに使用できるJKSストアが生成されます。
|
注意: この手順は、選択するSSOメカニズムにかかわらず必要です。 |
簡易モードまたは証明書モードで通信する際、OAMサーバーは、次のキー・ファイル、サーバー証明書ファイルおよびCAチェーン・ファイルを使用します。
aaa_key.pem: ルートCAにリクエストを送信するときに証明書生成ユーティリティによって生成されるランダム・キー情報。これは秘密鍵です。WebGateの証明書リクエストでは、証明書リクエスト・ファイルaaa_req.pemが生成されます。このWebGate証明書リクエストを、OAMサーバーによって信頼されるルートCAに送信する必要があります。ルートCAは、WebGate証明書を返します。この証明書は、WebGateのインストール中またはインストール後にインストールできます。
aaa_cert.pem: ルートCAによって署名される、OAMサーバーに対する実際の証明書。
aaa_chain.pem: ルートCAのパブリック証明書。これは、簡易モードまたは証明書モードで通信するピア同士が、SSLハンドシェイクを実行して、妥当性確認のための証明書を交換するときに使用されます。簡易モードでは、aaa_chain.pemは、OAMServer_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を除く)。
OAMサーバーのインストール・ディレクトリ・パスでOpenSSLユーティリティを使用して、aaa_key.pemファイルをDER形式に変換します。例:
OAM_Server_HOME\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です。追加のオプションは次のとおりです。
表16-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)で、OAMサーバーに対するパスフレーズを入力します。
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
このタスクは、セッション・トークン・メカニズム(ObSSOCookie)にのみ必要です。トラステッド・ヘッダー・アサーションまたはクリアテキスト・ヘッダー・メカニズムを実装している場合は、この項は省略してください。
プロビジョニングとは、OAM 11gの認証と認可のサービスを使用するために、エージェントを登録してアプリケーション・ドメインを作成するプロセスです。新しい11gインスタンスまたは10gインスタンスをインストールする場合でも、レガシーの10g Webゲートがインストール済の場合でも、OAM 11gでWebゲートをプロビジョニングする必要があります。
用語としてのWebゲートは、複数のWebゲートを表します(Oracle Web Services Managerの認証プロバイダおよびIDアサーション・プロバイダで使用するカスタムの10gアクセス・ゲートも指します)。特に明記されていなければ、この項の内容は両方に同様に当てはまります。
複数のエージェントがある場合、それぞれを別々にプロビジョニングできるほか、複数のエージェントに単一のOAMエージェント登録を使用することもできます。
|
注意:
|
この項の内容は次のとおりです。
このタスクは、セッション・トークン・メカニズム(ObSSOCookie)にのみ必要です。トラステッド・ヘッダー・アサーションまたはクリアテキスト・ヘッダー・メカニズムを実装している場合は、この項は省略してください。
表16-2は、OAM 11gで使用するためにWebゲートをプロビジョニングする際に使用できるメソッドとツールについて説明しています。リモート登録ツールを使用すると、テンプレートを使用して一部またはすべてのWebゲート・パラメータを指定できます。
表16-2 OAM 11g用のメソッドのプロビジョニング
| メソッド | 説明 |
|---|---|
|
Oracle Access Manager管理コンソール |
Oracle Access ManagerでOAMの管理者が手動で情報を入力し、直接パラメータを設定できるようにします。この方法は、認証プロバイダを使用している場合、またはOracle Web Services ManagerポリシーでWebサービスを保護している場合に必要です。 |
|
リモート登録 |
アプリケーションの管理者は、シングル・サインオン用のIDアサーション・プロバイダを実装する際に、コマンドラインを使用してWebゲートを登録できます。また、これによって新しいWeb層または既存のWeb層のセキュリティ・ポリシーを持つ新規アプリケーション・ドメインが作成されます。 必須パラメータは、テンプレートで指定する、環境に適した値を使用してプロビジョニングします。必須ではないパラメータについては、デフォルト値を使用します。登録が終了すると、Oracle Access Managerコンソールで値を変更できるようになります。 |
リモート登録の際には、表16-3に記載された詳細を指定する必要があります。
|
関連項目: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのすべてのWebゲート・パラメータのリストに関する項 |
表16-3 OAMエージェントに必須の登録の詳細
| OAMエージェントの要素 | 説明 |
|---|---|
|
<serverAddress> |
ホストとポートを含む、Oracle Access Manager管理コンソールの実行中のインスタンスを指します。 |
|
<webDomain> OSSOリクエスト専用 |
エージェント・ベースのURLが内部的に保存されているWebサーバー・ドメインを定義します。 |
|
<agentName> |
OAM(管理)サーバーでのエージェントの一意な識別子を定義します。 同じサーバー・インスタンス上のエージェントごとにこのタグは一意にして、同一エージェントの再登録を回避する必要があります。 同一のサーバー・インスタンス上で1つのエージェントを再登録することはできません。 |
|
<hostIdentifier> |
この識別子は、Webサーバーのホストを表しています。このフィールドは、OAMエージェント名の値を指定すると自動的に入力されます。同じ名前のエージェント名またはホスト識別子がすでに存在する場合には、登録時にエラーが発生します。 |
|
<protectedResourcesList> |
一部の認証スキームでOAMエージェントを保護するリソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。 |
|
<publicResourcesList> |
公開する(OAMエージェントで保護しない)リソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。たとえば、アプリケーションのホームページやようこそページを指定します。 |
このタスクは、セッション・トークン・メカニズム(ObSSOCookie)にのみ必要です。トラステッド・ヘッダー・アサーションまたはクリアテキスト・ヘッダー・メカニズムを実装している場合は、この項は省略してください。
Webゲートやアクセス・ゲートのプロビジョニングには、前述と同じ手順を実行します。認証プロバイダで使用する新規インスタンスのプロビジョニングや、プロバイダを構成する際に既存の登録の参照などができます。
この例では、OAMRequest_short.xmlテンプレートを使用してOAM 10g Webゲートをプロビジョニングします。登録されたエージェントは、my-wl-agent1と名付けられ、/.../*を保護し、パブリック・リソースの/public/index.htmlを宣言します。実際の値はこれとは異なります。
|
注意: OAM 11g Webゲートのプロビジョニングでは、OAM11gRequest_short.xmlテンプレートを使用します。 |
|
関連項目: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド |
ツールの入手: Webゲートをホストするコンピュータ上でリモート登録ツールを入手し、使用する環境に合せてスクリプトを設定します。例:
次のパスでRREG.tar.gzファイルを見つけます。
WLS_home/Middleware/domain_home/oam/server/rreg/client/RREG.tar.gz
RREG.tar.gzファイルを任意の適切な場所に展開します。例: rreg/bin/oamreg。
oamregスクリプトで、実際の状況がクライアント側であるかサーバー側であるかに応じて次の環境変数を設定し、さらにOracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの表6と表7にある情報を設定します。
登録リクエストの作成:
*Request_short.xmlファイルを探し、新しい場所にコピーして名前を付けます。例:
WLS_home/Middleware/domain_home/oam/server/rreg/bin/oamreg/
コピー元ファイル: OAMRequest_short.xml(またはOAM 11gRequest.xml)
コピー先ファイル: my-wl-agent1.xml
my-wl-agent1.xmlを編集して、環境の詳細を指定し、自動ポリシーの作成をfalseに設定します。例:
<OAMRegRequest>
<serverAddress>http://sample.us.oracle.com:7001</serverAddress>
<hostIdentifier>my-wl</hostIdentifier>
<agentName>my-wl-agent1</agentName>
<primaryCookieDomain>.us.example.com</primaryCookieDomain>
<autoCreatePolicy>false</autoCreatePolicy>
<logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
</OAMRegRequest>
|
関連項目: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの登録リクエストの作成に関する項 |
エージェントをプロビジョニングします。例:
リモート登録スクリプトを見つけます。
chmod +x oamreg.shWindowsの場合: rreg\bin\oamreg.bat
スクリプトが存在するディレクトリから、inbandモードを使用してこのスクリプトを実行します。例:
$ ./bin/oamreg.sh inband input/my-wl-agent1.xml
Welcome to OAM Remote Registration Tool! Parameters passed to the registration tool are: Mode: inband Filename: ...
プロンプトが表示されたら、環境に応じた値を使用して次の情報を入力します。
Enter your agent username: userame Username: userame Enter agent password: ******** Do you want to enter a Webgate password?(y/n) n iv.Do you want to import an URIs file?(y/n) n
最後のメッセージを参照して、正常な登録が行われたことを確認します。
Inband registration process completed successfully! Output artifacts are created in the output folder"
コンソールの確認: Oracle Access Managerコンソールにログインして、新規登録を確認します。
OAM 11gコンソールの「システム構成」タブから、「Access Managerの設定」セクションに移動し、「SSOエージェント」ノードを開いて、プロビジョニングしたエージェントを検索します。
「検索結果」表で、エージェント名をクリックして登録のページを表示し、詳細を確認します。これは後で使用します。例:
エージェント名: Webゲートのインストール時に、WebゲートIDとして入力します。カスタム10gアクセス・ゲートをデプロイする場合は、WebLogic管理コンソールでOAM認証プロバイダを構成する際に、これをアクセス・ゲート名として入力します。
アクセス・クライアント・パスワード: Webゲートのインストールの際に、Webゲートのパスワードとして入力します。パスワードを入力しなかった場合、このフィールドは空白のままでかまいません。
アクセス・サーバー・ホスト名: このWebゲートの登録先とするプライマリOAM 11gサーバーのDNSホスト名を入力します。
OAMプロキシ・ポート: Oracle Access Managerコンソールの「システム構成」タブで、「共通構成」セクションに移動し、「サーバー・インスタンス」を開いて、OAMプロキシが実行中のポートを検索します。
プロビジョニングの際に作成されたObaccessclient.xmlファイルは、この段階では無視します。
それぞれの環境に応じて次の手順を実行します。
エージェントをインストール済の環境: 実装に応じて、次の適切な項に移動します。
エージェントをインストールしていない環境:
11g WebGateの場合: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。
10g WebGateの場合: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。
この項では、アプリケーションでのシングル・サインオン用のOracle Access Manager 11g IDアサーションの構成に必要な固有の手順について説明します。
タスクの概要: OAM 11gでのSSO用IDアサーション・プロバイダのデプロイ
実装しているメカニズムに対するすべての前提条件タスクの完了
次の各項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンをアプリケーションで設定するための手順について説明します。
タスクの概要: Oracle WebLogic Serverとの間の信頼の確立
この項では、Oracle Access Manager IDアサーションのアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle Access Manager IDアサーション・プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をCLIENT-CERTに指定する必要があります。
WebLogic Serverのhost:portを介して直接アプリケーションにアクセスし、コンテナで認証されるようにする場合は、ここにカンマで区切った複数の値を指定できます。たとえば、<auth-method>CLIENT-CERT,FORM</auth-method>とします。
auth-methodには、BASIC、FORMまたはCLIENT-CERTの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。
IDアサーション・プロバイダのweb.xmlで認証を指定するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。
my_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を編集する必要があります。
Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicを構成するには
httpd.confを見つけます。例:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
ファイル内に次の文があり、デプロイメントに適した値が指定されていることを確認します(必要に応じてコメントを追加または削除します)。
<IfModule mod_weblogic.c> WebLogicHost myHost.myDomain.com WebLogicPort myWlsPortNumber </IfModule> <Location http://request-uri-pattern> SetHandler weblogic-handler </Location>
ファイルを保存します。
実装に応じて次の手順を実行します。
Oracle WebLogicの接続フィルタ・メカニズムを構成すると、アクセス制御リストを作成したり、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストのみからリクエストを受け入れることができます。
|
注意: このフィルタは、IDアサーションをクリア・テキスト・ヘッダー・メカニズムとともに使用する場合に、セキュリティ上必要になります。他のメカニズムを使用する場合は、このタスクはオプションです。 |
ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。これは、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非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
表16-4は、接続フィルタの各パラメータを説明しています。
表16-4 接続フィルタ・ルール
| パラメータ | 説明 |
|---|---|
|
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ドメインのセキュリティの構成に関する項 |
Oracle HTTP Serverホストからのリクエストを許可するための接続フィルタを構成する手順は次のとおりです。
Oracle WebLogic管理コンソールにログインします。
「ドメイン構成」の下の「ドメイン」をクリックします。
「セキュリティ」タブ→「フィルタ」タブをクリックします。
「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。
ドメインで使用する次の接続フィルタを指定します。
デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。
カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHでも指定する必要があります。
適切な接続フィルタ・ルールの構文を入力します。
「保存」をクリックします。
Oracle WebLogic Serverを再起動します。
「WebLogicドメインでのプロバイダの構成」に進みます。
ここでの情報は、OAM 11gおよびOAM 10gに同じように当てはまります。この項の内容は次のとおりです。
この項では、WebLogicセキュリティ・レルムの認証プロバイダを初めて使用するユーザーのために、いくつかのタイプの認証プロバイダのみを説明します。
WebLogicセキュリティ・レルムごとに、少なくとも1つの認証プロバイダを構成する必要があります。WebLogicセキュリティ・フレームワークは、マルチパート認証用に複数の認証プロバイダ(および複数のLoginModule)をサポートするように設計されています。このため、1つのセキュリティ・レルムで複数の認証プロバイダと複数のタイプの認証プロバイダを使用できます。制御フラグ属性により、認証プロセスにおいて各認証プロバイダのLoginModuleがどのように使用されるかが決定されます。
Oracle WebLogic Serverは、次のものを含め、複数のタイプの認証プロバイダとIDアサーション・プロバイダを提供します。
デフォルトのWebLogic認証プロバイダ(デフォルトの認証プロバイダ)では、ユーザーとグループを1箇所で、つまり、WebLogic Serverの組込みLDAPサーバーで管理できます。この認証プロバイダは、Oracle WebLogic Serverでの管理ユーザー・ログインに使用されます。
IDアサーションは、トークンベース認証を使用します。Oracle Access Manager IDアサーション・プロバイダはその一例です。これは、インストール済Webゲート(10gまたは11g)の適切なアクションを使用するように構成する必要があります。
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)
表16-5では、addOAMSSOProviderコマンドラインにおける各引数の期待値を定義しています。
表16-5 addOAMSSOProviderコマンドライン引数
| 引数 | 定義 |
|---|---|
|
loginuri |
ログイン・ページのURIを指定します。 |
|
autologinuri |
自動ログイン・ページのURIを指定します。 |
|
logouturi |
ログアウト・ページの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セキュリティ・ドメインのプロバイダを構成する方法について説明します。次の認証プロバイダ・タイプを構成して並べ替える必要があります。
OAM IDアサーション・プロバイダ: REQUIRED(使用しているメカニズムに対する選択済アクティブ・タイプも指定します(表15-1))。
次の手順では、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に設定します。
「共通」タブで、使用しているSSOメカニズムに対する選択済アクティブ・タイプを1つ指定します(表15-1)。例:
OAM_IDENTITY_ASSERTION構成を保存します。
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を再起動します。
次のようにします。
成功: 実装に応じて次の手順を実行します。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
前述のとおり、10g Webゲートに付属のログイン・フォームは、OAM 10gアクセス・サーバーでのみ使用します。OAM 11gの場合、10g Webゲートでも11g Webゲートでもログイン・ページは提供されません。
|
注意: OAM 11g Serverでは、ログイン・ページが表示されます。設定は必要ありません。 |
これは手動で行うタスクです。デジタル署名検証には、Oracle Access Manager証明書の公開鍵が必要です。IDアサーション・プロバイダによって使用される証明書は、.oamkeystoreに格納されている必要があります。
SSO同期フィルタが証明書を使用するには、フィルタに対してトラスト・ストアを指定する必要があります。SSO同期フィルタの動作は、WebLogicに各種の優先システム・プロパティを渡すことにより、アプリケーションの要件に応じて変更できます。これには、Oracle WebLogicの起動スクリプト(setDomainEnv.sh)で、EXTRA_JAVA_PROPERTIESの下にプロパティを追加します。トラスト・ストアの場所はシステム・プロパティとして指定できます。デフォルトでは、フィルタはssofilter.jarの場所でキーストアを探します。見つからない場合は、次にシステム・プロパティ内を探します。
次の手順は、エクスポートおよびインポート操作を実行するために必要な.oamkeystoreパスワードの取得方法を示します。必要なOAM証明書をエクスポートおよびインポートしたら、IDアサーション・プロバイダが証明書を使用できるように、キーストアをプロビジョニングします。最後に、OAM_IDENTITY_ASSERTIONトークン・タイプを選択し、SSO同期フィルタ内で証明書をプロビジョニングして、認可ポリシーでIDアサーションが有効になっていることを確認します。
トラステッド・ヘッダー・アサーション用にデジタル署名検証を構成する手順は次のとおりです。
WLSTスクリプト・ツールを使用して、次のように.oamkeystoreパスワードを取得します。
$MW_HOME/Oracle_IDM1/common/binでWLSTツールを探します。
wlst.sh($ ./wlst.sh)を実行します。
画面に表示される次のメッセージで実行を確認します。
Initializing WebLogic Scripting Tool (WLST) ... Jython scans all the jar files it can find at first startup. Depending on the system, this process may take a few minutes to complete, and WLST may not return a prompt right away Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands
wls:/offline> connect()を実行し、環境に対する情報(WebLogic管理者のユーザー名とパスワードおよびAdminServerのURL)を指定します。例:
Please enter your username: weblogic Please enter your password: password Please enter your server URL //localhost:7001 not return a prompt right away Connecting to ... Successfully connected to Admin Server 'AdminServer' ... domain 'base_domain'. Warning: An insecure protocol was used to connect to the server. To ensure on-the-wire security, the SSL port or Admin port should be used instead. wls:/base_domain/serverConfig
wls:/base_domain/serverConfig> domainRuntime()を実行し、画面に表示される次のメッセージを確認します。例:
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root For more help, use help(domainRuntime) wls:/base_domain/domainRuntime>
wls:/base_domain/domainRuntime> listCred(map="OAM_STORE",key="jks")を実行します。例:
Already in Domain Runtime Tree
PASSWORD: lleoi4sbkpo3bj8fg55k7jgbgh
wls:/base_domain/domainRuntime>
JDK6 keytoolを使用して、次のように別名を証明書ファイルにエクスポートします。
jdk/bin]$ keytool -exportcert -alias "assertion-cert" -keystore .oamkeystore
-storepass gtml6es9qderjc66f76hvtqm5a -storetype JCEKS -file assertion.cer
JDK6 keytoolを使用して、次のように証明書ファイルをインポートします。
|
注意: キーストア別名 |
jdk/bin $ keytool -importcert -trustcacerts -alias "oam.assertion.cert" -file
assertion.cer -keystore /scratch/oamiap-keystore.jks -storepass password
-storetype JKS
oamiap-keystore.jks内の公開鍵を使用して、OAM証明書を使用できるように、IDアサーション・プロバイダのキーストアをプロビジョニングします。
WebLogicコンソールのセキュリティ・レルムの下のIDアサーション・プロバイダ・エントリで、プロバイダ固有の構成にoamiap-keystore.jksの絶対パスを追加します。
プロバイダ固有の構成で、トークン・タイプOAM_IDENTITY_ASSERTIONを選択します。
この構成を保存します。
次のように、SSO同期ファイル内で.oamkeystoreをプロビジョニングします。
デフォルトでは、フィルタはssofilter.jarの場所でキーストアを探します。そこで見つからない場合は、システム・プロパティを調べます。
デフォルト構成: キーストア・ファイルoamiap-keystore.jksをssofilter.jarと同じ場所に置きます。例: $MW_HOME/oracle_common/modules/oracle.ssofilter_11.1.1
フォールバック・メカニズム: キーストア・ファイルoamiap-keystore.jksを、setDomainEnv.sh($MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh)でシステム・プロパティとして設定します。
-Dsso.filter.oam.keystore=/scratch/keystore/oamiap-keystore.jks
次のように、OAM_IDENTITY_ASSERTIONのシステム・プロパティを設定します。
WebLogic Serverを停止します。
$MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.shにある、setDomainEnv.shファイルを開きます。
次のプロパティをEXTRA_JAVA_PROPERTIESの下に追加し、ファイルを保存します。
-Dsso.filter.ssotoken=OAM_IDENTITY_ASSERTION
WebLogic Serverを起動します。
アサーションのトークン・タイプとしてOAM_IDENTITY_ASSERTIONを使用するには、リソースを保護する認可ポリシーで「IDアサーション」オプションを有効にする必要があります。デフォルト・ポリシーはエージェントの登録時に生成されます。Oracle Access Managerコンソールを使用して手動でポリシーを作成することもできます。
図16-6に、トラステッド・ヘッダー・アサーション・メカニズムに対する認可ポリシーの例を示します。
次の手順では、リソースを保護するOracle Access Manager 11gの認可ポリシー内でIDアサーションを有効にする方法を示します。
|
関連項目: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド |
トラステッド・ヘッダー・アサーションに対してIDアサーションを有効にする手順は次のとおりです。
「ポリシー構成」タブのナビゲーション・ツリーから次のノードを開きます。
「IDアサーション」を有効にします(ボックスを選択します)。
リソース:
「リソース」タブで、適切なリソースがこのポリシーによって保護されていることを確認します。
必要に応じてリソースを追加または削除します。
「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。
終了する場合はページを閉じます。
次の手順では、使用しているメカニズムにかかわらず、Oracle Access Manager IDアサーションの設定をテストする方法を示します。
また、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの説明にあるように、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。
シングル・サインオン用のOracle Access Manager IDアサーションを検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。例:
http://ohs_server:port/<protected url>
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「トラブルシューティングのヒント」を参照してください。
認証プロバイダ機能を使用する場合、ユーザーには、アプリケーションのweb.xml内で構成されている認証方式に基づいて資格証明の入力が要求されます。ただし、Oracle Access Manager認証スキームが必要です。これは、Oracle Access Manager 11gで提供されている事前シード済アプリケーション・ドメインにあります。これは、次のリソース(resource type wl_authen)を保護します。
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion
ポリシーにはレスポンスと制約を追加できます。ただし、それ以外の構成は必要ありません。
事前シード済アプリケーション・ドメインの詳細は、「10gアクセス・ゲートで使用される事前シード済OAM 11gポリシーのプレビュー」を参照してください。
前提条件
セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング
|
注意: 認証プロバイダで使用するカスタムの10gアクセス・ゲートをプロビジョニングすることも、認証プロバイダのプロバイダの構成時に既存のOAMエージェント登録を参照することもできます。 |
Oracle Access Manager認証プロバイダを構成するためのタスクについては、次の概要で説明します。
タスクの概要: OAM用の認証プロバイダ機能の構成には次の手順が含まれます。
前提条件のすべてのタスクが実行されていることの確認
この項では、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
作成した認証プロバイダの名前をクリックして、「プロバイダ構成」ページを表示します。
「プロバイダ構成」ページで、次のように必要な値を設定します。
アクセス・ゲート名: プロバイダによって使用されるアクセス・ゲートの名前。これは、Oracle Access ManagerコンソールのOAMエージェント登録の名前と完全に一致している必要があります。
|
注意: OAM 11gでは1つ以上の10g OAMエージェントを登録できます。正しいエージェント登録名を選択してください。 |
アクセス・ゲートのパスワード: エージェント登録に対してパスワードが定義されている場合は、それと同じパスワード(Oracle Access Managerコンソールを参照)。
プライマリ・アクセス・サーバー: Oracle Access Managerコンソールでこのアクセス・ゲートに関連付けられているプライマリOAMサーバーのhost:port。
詳細構成: 次に、いくつかの詳細構成の値を示します。
トランスポート・セキュリティ: OAMサーバーとアクセス・ゲート間の通信モード(オープン、簡易、証明書)。
トランスポート・セキュリティが簡易または証明書である場合、次のパラメータと値を含めてください。
トラスト・ストア: プロバイダとOAM Server間のSSL通信で使用するJKSトラスト・ストアの絶対パス。
キー・ストア: プロバイダとOAM Server間のSSL通信で使用するJKSキー・ストアの絶対パス。
キー・ストアのパスフレーズ: キー・ストアにアクセスするためのパスワード。
簡易モード・パスフレーズ: アクセス・ゲートとOAM Serverで共有する簡易通信モード用パスワード。
セカンダリOAMサーバー: Oracle Access Managerコンソールでこのアクセス・ゲートに関連付けられているセカンダリOAMサーバーのhost:port。
プール内の最大OAMサーバー接続数: アクセス・ゲートがOAMサーバーに対してオープンする最大接続数。デフォルト値は10です。
|
注意: WebLogic管理コンソールで指定するプール内の最大OAMサーバー接続数(またはプール内の最小OAMサーバー接続数)の設定は、Oracle Access Managerコンソールで指定する「最大接続数」や「最小接続数」とは異なります。 |
プール内の最小アクセス・サーバー接続数: 認証プロバイダからOAMサーバーへの認証リクエストの送信に使用する最小接続数。デフォルト値は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 11g用の集中管理ログアウトの構成」に説明されているように集中管理ログアウトを構成し、ここに戻ってOracle Access Manager認証プロバイダの実装のテストを実行します。
認証プロバイダの実装タスクをすべて実行した後、有効な資格証明を使用してアプリケーションへのログインを試行して実装をテストできます。構成が正しくない場合、有効なユーザーがアクセスを拒否されます。
次の手順では、認証プロバイダの設定をテストする方法について説明します。また、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの説明にあるように、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。
Oracle Access Manager認証プロバイダの実装を検証するには
ご使用の環境の保護されているリソースをアクセスするURLを入力します。例:
http://yourdomain.com:port
ログイン・フォームが表示されたら、適切な資格証明を入力します。
成功: 正常に実装されます。
失敗: 「トラブルシューティングのヒント」を参照してください。
この項では、Oracle Web Services ManagerでWebサービスを保護している場合に、トークンの検証を有効にするようにOracle Access Manager IDアサーション・プロバイダを設定する方法について説明します。
前述のとおり、Oracle Access Manager IDアサーション・プロバイダは2つのモードで機能します。デフォルト・モードの操作では、Webゲートが境界で設定したヘッダーがアサートされます。これで、ほとんどのSSOの処理を扱うことができます。もう1つのモードでは、oamAuthnProvider.jarにあるカスタム・アクセス・ゲートを使用します。この場合、ヘッダーが存在しないと、IDアサーション・プロバイダはOAMサーバーにアクセスしてトークンを検証します。トークンの詳細は、「Oracle Access Manager 11gでの認証プロバイダのインストール」を参照してください。
|
注意: Oracle Web Services ManagerのIDアサーション・プロバイダには、認証プロバイダが提供する10gカスタム・アクセス・ゲートが必要です。 |
OAM 10gでは、ポリシー・ドメインおよびこの構成に対応するポリシーの手動での作成が必要になることがあります。一方、OAM 11gでは、次のリソース(resource type wl_authen)を保護するポリシーを設定した事前シード済アプリケーション・ドメインが提供されます。
/Authen/Basic
/Authen/SSOToken
/Authen/UsernameAssertion
タイプwl_authenのリソースのポリシー、レスポンスおよび制約のみを追加できます。ただし理論上はこのアプリケーション・ドメインは構成を追加することなく使用することができます。詳細は、「10gアクセス・ゲートで使用される事前シード済OAM 11gポリシーのプレビュー」を参照してください。
Oracle Access Manager IDアサーション・プロバイダがヘッダーとトークンの両方の検証モードで構成されている場合、ヘッダー検証モードが優先します。ヘッダーが存在しない場合、IDアサーション・プロバイダはOAMサーバーにアクセスしてトークンを検証します。トークンの詳細は、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。
前提条件
Oracle Access Manager 11gでの認証プロバイダのインストール
セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング
タスクの概要: Oracle Web Services Manager用のIDアサーション・プロバイダのデプロイ
Oracle Web Services ManagerがWebサービスを保護している場合に、Oracle Access Manager IDアサーション・プロバイダを使用するには、WebLogicドメインでいくつかの認証プロバイダを構成し、並べ替える必要があります。
この手順は、OAM 11gでのOracle Access Manager IDアサーション・プロバイダの場合とほとんど同じです。この場合の相違点は、Oracle Web Services Managerはカスタム・アクセス・ゲートを必要とし、追加のプロバイダ固有の値が必要になることです。
プライマリ・アクセス・サーバー: プライマリOAMサーバーのホストとポートを指定します。例: mnop:8888。
アクセス・ゲート名: アプリケーションを保護するアクセス・ゲート登録の名前。例: AG1。
アクセス・ゲートのパスワード: Oracle Access Managerコンソールで指定したアクセス・ゲート・パスワード。
これらは、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に設定して「保存」をクリックします。
「共通」タブをクリックして、10gカスタム・アクセス・ゲートの選択済アクティブ・タイプとしてObSSOCookieを指定し、「保存」をクリックします。
「プロバイダ固有」タブをクリックし、次のパラメータを構成します。
プライマリ・アクセス・サーバー: プライマリOAMサーバーのホストとポートを指定します。例: abcd:7777。
アクセス・ゲート名: アプリケーションを保護するOAMエージェントの登録名。例: AG1。
アクセス・ゲートのパスワード: プロビジョニングの際に指定したアクセス・ゲート・パスワードがあれば、そのパスワード。
保存します。
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を再起動します。
次のようにします。
成功: 「Oracle Access Manager 11g用の集中管理ログアウトの構成」に進み、ここに戻って「Oracle Web Services Manager用IDアサーション・プロバイダのテスト」を実行します。
失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「Oracle Access Manager 11gでの認証プロバイダのインストール」の説明にあるように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。
Oracle Web Services ManagerとOracle Access Manager IDアサーション・プロバイダとの併用を検証するには、IDアサーション・プロバイダとOracle Web Services Managerのポリシーによって保護されているWebサービスにアクセスします。アクセスが許可されれば、実装は機能しています。失敗した場合は、「トラブルシューティングのヒント」を参照してください。
この項では、Oracle Access Manager 11g用の集中管理ログアウトについて説明します。
OAM 11gでは、集中管理ログアウトとはアクティブなユーザー・セッションを終了するプロセスを意味します。ガイドラインの内容は次のとおりです。
SSO環境で使用するアプリケーションは、自身のログアウト・ページを表示しないようにする必要があります。
アプリケーションは、OAM Webゲート管理者が指定したログアウトURLを指す値でログアウト・リンクを構成できるようにする必要があります。
|
注意: アプリケーションでADF認証サーブレットを使用することを強くお薦めします。これにより、このサーブレットはOPSSとインタフェース接続し、OPSSでドメイン全体の構成パラメータを使用してログアウトURLを指定できます。この方法であれば、ログアウトの構成を変更するためにアプリケーションの変更や再デプロイが必要になることがありません。 |
詳細は、次を参照してください:
OAM 11gエージェントの登録ページのいくつかの要素によって、OAM 11g Webゲートの中央管理されたログアウトが有効になります。エージェントの登録後、その情報がObAccessClient.xmlファイルに移入されます。
エージェントの登録の際に指定する必要のある11g Webゲートのログアウトオプションには、次のものがあります。
ログアウトURL: ログアウト・ハンドラをトリガーします。これにより、Cookie(10g Webゲート用ObSSOCookie、11g Webゲート用OAMAuthnCookie)が削除されるので、Oracle Access Managerで保護されたリソースにこのユーザーが次回アクセスする際には再認証が必要になります。
ログアウト・コールバックURL: oam_logout_successへのURLです。コールバックの際にCookieを消去します。これには、host:portのないURI形式を指定できます(推奨)。これにより、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。
ログアウト・リダイレクトURL: このパラメータには、エージェントの登録が完了すると自動的に情報が移入されます。デフォルトでは、ポートをデフォルトの14200としたOAMサーバーのホスト名に基づきます。
ログアウト・ターゲットURL: この値は、ログアウトの際にOPSSアプリケーションがWebゲートに渡す問合せパラメータの名前です。この問合せパラメータは、ログアウト後のランディング・ページのターゲットURLを指定します。
詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのOAM 11gサーバーによる11g WebGateの一元化されたログアウトの構成に関する項を参照してください。
OAMエージェント(この場合は10g Webゲート)向けに構成されたlogout.htmlファイルをアプリケーションで呼び出すと、ログアウトが始まります。アプリケーションはend_urlも問合せ文字列としてlogout.htmlに渡します。end_urlパラメータはURIまたはURLとすることができます。
|
関連項目: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド
|
タスクの概要: 10g Webゲート向けの中央管理ログアウトの構成。
デフォルトのログアウト・ページ(logout.html)を作成して、それをWebゲートのインストール・ディレクトリに置きます。例: WebGate_install_dir/oamsso/logout.html。
logout.htmlで、logOutUrlsパラメータが各リソースWebゲートに構成されていること、および<callBackUri>が「logOutUrls」の2番目の値であることを確認します。
logout.htmlで、(ステップ1から)確認し、ユーザーがOAM 11g Server上の中央ログアウトURI「/oam/server/logout」にリダイレクトされていることを確認します。
オプション: ログアウトしたユーザーのリダイレクト先を示すend_urlパラメータをアプリケーションで渡すことができます。
10g Webゲートを構成したOHS Webサーバー構成ファイルhttpd.confを確認し、次の行が存在する場合には削除します。
<LocationMatch "/oamsso/*"> Satisfy any </LocationMatch>
詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのOAM 11gサーバーによる10g WebGateの一元化されたログアウトの構成に関する項を参照してください。
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が検索され、大/小文字を区別しない一致が実行されます。
Oracle Access Manager SSOトークン/ヘッダーに対する構成: OAM_IDENTITY_ASSERTIONが検索され、大/小文字を区別しない一致が実行されます。詳細は、「トラステッド・ヘッダー・アサーション: デジタル署名検証の構成」を参照してください。
グローバル・ログアウト: 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があるか確認します。表16-6に、各プロパティと同期動作を示します。
表16-6 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 Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのトラブルシューティングに関する項を参照してください。
