10 IBM WebSphereとの統合

Oracle Access Manager WebSphere用コネクタでは、IBMのWebSphere Application Server上で稼働するアプリケーションをアクセス・システムの認証サービスおよび認可サービスと統合できます。また、Oracle Access Managerの管理対象のユーザーおよびグループがWebSphere内で認証と認可を利用できるようにします。

この章では、環境を準備した後で、Oracle Access Manager WebSphere用コネクタをインストール、設定、テストし、WebSphere Application Server for Oracle Access Managerを構成する方法を説明します。

この章では、次の内容について説明します。

• WebSphere用コネクタの概要

• 統合アーキテクチャ

• Oracle Access ManagerCMRとの統合のシナリオ

• サポートされているバージョンとプラットフォーム

• コネクタのインストール準備

• WebSphere用コネクタのインストール

• コネクタの設定の完了

• WebSphere Application Server V5の構成

• WebSphere Portal V5との統合

• WebSphere Application Server V6の構成

• 構成ファイル

• TAIの実装の注意事項

• Active Directoryの実装の注意事項

• WebSphere用コネクタのトラブルシューティング

10.1 WebSphere用コネクタの概要

Oracle Access Manager WebSphere用コネクタを使用して、WebSphere Application Server管理者は、WebSphere上で稼働するアプリケーションをアクセス・システムの認証サービスおよび認可サービスと統合できます。

WebSphere用コネクタを使用すると、アクセス・システムが保護するWebSphereリソースへのアクセスを試みるユーザーは、アクセス・システムによってチャレンジ方式で認証されます。また、IDシステム管理対象のユーザーおよびグループが認証と認可を利用できるようになります。

WebSphere用コネクタには次にあげる利点があります。

• IDシステム管理対象のユーザーおよびグループに関する情報を認証と認可のためにWebSphere Security Serverに提供します。

• アクセス・システムを使用して、JSP、EJBおよびサーブレットなどのWebSphereリソースにアクセスするユーザーを認証します。

  アクセス・システムの認証スキームによって、WebおよびWeb以外で有効なアプリケーションへのシングル・サインオンができます。

• WebSphereリソースにアクセスするユーザーに認可を与えます。

  Oracle Access ManagerはWebSphereのセキュリティ・ロール・ベースの認可をサポートします。WebSphereのロール・ベースの認可は、ロール（管理者など）に基づいて保護されたリソースへのアクセスをユーザーまたはグループに対して許可します。Oracle Access ManagerはWebSphere Serverセキュリティ・ロールとアクセス・システムのポリシー・ベースの認可を統合します。

• WebSphere Serverのリソース（管理ツール、イベント、サーブレット、パスワード、JDBC接続プール、JMS宛先およびJNDIコンテキストなど）を保護します。

  WebSphereのロール・ベースのアクセス・ポリシーでWebSphereリソースへのアクセスを制御できます。

• アクセス・システムに保護されているリソースと、WebSphereのセキュリティ制約で保護されているWebSphere Serverリソースの間のシングル・サインオンを有効にします。

次に統合の概要を示します。

タスクの概要: WebSphere Application Serverとの統合

1. 「環境の準備」の説明に従って、環境を準備します。

2. 「WebSphere用コネクタのインストール」に示す手順でコネクタをインストールします。

3. 「コネクタの設定の完了」に示す手順でコネクタを設定してテストします。

4. 「WebSphere Application Server V5の構成」に示す手順でWebSphere Application Serverを構成します。

5. WebSphere Portal Serverを使用する場合は、「WebSphere Portal V5との統合」に示す手順でWebSphere Portal Serverと統合します。

この章に示す作業を終了すると、次の形式の名前を持つパスが作成されています。

Identity_install_dir: Identity Serverのインストール先のディレクトリ。実際のインストールでは、たとえば、C:\OracleAccessManagerのようになります。インストール時に、指定した宛先に\identityサブディレクトリが付加され、Identity ServerをインストールしたディレクトリへのフルパスIdentity_install_dir\identityが構成されます。

WebGate_install_dir: アクセス・システムWebGateのインストール先のディレクトリ。実際のインストールでは、たとえば、C:\OracleAccessManager\Webcomponentのようになります。インストール時に、指定した宛先に\accessサブディレクトリが付加され、WebGateをインストールしたディレクトリへのフルパスWebGate_install_dir\accessが構成されます。

CWS_install_dir: WebSphere用コネクタのインストール先ディレクトリ。実際のインストールでは、たとえば、C:\OracleAccessManager\NetPointWASRegistryのようになります。

WAS_install_dir: WebSphere Application Serverのインストール先ディレクトリ。実際のインストールでは、たとえば、C:\IBM\WebSphere\AppServerのようになります。

WPS_install_dir: WebSphere Portal Serverのインストール先ディレクトリ。実際のインストールでは、たとえば、C:\IBM\WebSphere\PortalServerのようになります。このディレクトリは、WPS_install_dir/log/appserver-out.logのような形式でPortalのログに使用されます。

手順を実施する際に、前述の段落に示した表記のいずれかを見つけた場合は、環境に合せた適切なパス名に置き換えてください。

この項では、次の内容について後述します。

• WebSphereのコンポーネント

• WebSphere用コネクタのコンポーネント

10.1.1 WebSphereのコンポーネント

サポート情報の詳細は、「サポートされているバージョンとプラットフォーム」を参照してください。WebSphereとOracle Access Managerの統合には、次のWebSphereコンポーネントを使用します。

WebSphere Application Server（WAS）: WebSphere Application Server（WAS）によって、セキュアで大容量のトランザクションおよびWebサービスが利用可能になります。

• WAS 5.0/5.1はJ2EE 1.3に準拠しています。

• WAS 6はJ2EE 1.4に準拠しています。

注意: いずれもセキュリティ・ロールにEJB1.1仕様による認可を実装しています。セキュリティ・ロールとは、Webリソースおよび特定のEJBメソッドにアクセスする権限のセットです。

WebSphere Portal Server（WPS）: WebSphere Portal Serverでは、Java Authentication and Authorization Service（JAAS）に基づいてポートレットにシングル・サインオンを提供します。シングル・サインオンを実装すると、ポートレット開発者は次の情報を取得できます。

• ユーザーのユーザー名とパスワードおよび識別名（DN）

• ユーザーが属するグループのDN

• WebSphere Application ServerのCORBA資格証明

• LTPAトークン

ポートレットのバックエンドへのシングル・サインオンに前述のオブジェクトの任意の組合せを使用できます。たとえば、ユーザー名とパスワードを使用して、Basic認証HTTPヘッダーを作成できます。あるいは、LTPAトークンを使用して、同一のセキュリティ・ドメイン内の別のWebSphere Application Serverにシングル・サインオンすることができます。

Web Trust Association Interceptor（TAI）: TAIはサード・パーティのプロキシ認証に使用します。WebSphere Application Serverは、TAIによってWebSphereのセキュリティ・プロバイダとサード・パーティのセキュリティ・プロバイダ間の信頼ポリシーを強化します。TAIは、アクセス・システムがWebSphere Application Server上のリソースへのアクセスを試みるユーザーを認証できるようにします。

Application Assembly Tool（AAT）: AATは、セキュリティを意識したアプリケーションを構築するために使用します。AATでWebSphereのロールを定義し、IDシステムのユーザーおよびグループにバインドします。

10.1.2 WebSphere用コネクタのコンポーネント

WebSphere用コネクタは、Trust Association Interceptor（TAI）、IDシステム、アクセス・システムおよび次のコンポーネントを使用します。

NetPointWASRegistry: これはWebSphere用コネクタです。NetPointWASRegistryは、Oracle Access ManagerでのWebSphere CustomRegistryのユーザー・データ・ストアの実装です。NetPointWASRegistryは、WebSphere Application Server（WAS）に対するプラグインとして機能します。

WebSphere CustomRegistryは、Custom User Registry（CUR）ともいいます。CustomRegistryは、WASを使用するよう構成されたアプリケーションのセキュリティ操作を実施するためにWASが使用するメソッドを定義します。たとえば、ユーザー名とパスワードなどの属性を識別し、異なるデータ・ソースからのユーザー情報を結合するためにWebSphere CustomRegistryを使用することがあります。

NetPointWASRegistryは、Access Manager SDKおよびIdentity XMLから構成されます。NetPointWASRegistryでは、WASとOracle Access Managerの間にネイティブ接続を確立し、WebSphere管理者がポリシー・ベースのセキュリティ機能でビジネス・アプリケーションへのユーザー・アクセスを制御できるようにします。

IdentityXML: WebSphere用コネクタは、IdentityXML呼出しを使用して、Identity Serverからユーザーとグループの情報を取得します。一般に、IDシステムを外部のソフトウェア・システムと統合し、IDシステムの機能をIDシステムのGUIからでなくプログラムとして実行するためにIdentityXMLを使用します。

Access Manager SDK: Access Manager Software Developer Kit （SDK）では、WebSphereに組み込むことの可能なインタフェースを作成したり、認証のためにAccess Serverと通信するAccessGateを作成したりできます。SDKはWebSphere用コネクタのインストール時に自動的にインストールされます。SDKはTAIによって使用されます。

カスタム・メンバー・リポジトリ（CMR）: CMRはNetPointWASRegistry（カスタム・ユーザー・レジストリ）と呼ばれるOracle Access Managerコンポーネントの拡張機能です。これはWebSphere Portal Server上にあります。WebSphere Portal Serverでは、ポータルへのログイン時にWebSphere Application Serverの認証セキュリティを使用します。WebSphere Portal Serverでは、ユーザーによる操作性のカスタマイズおよびパーソナライズを可能にし、ユーザー、ユーザー・アカウント、ユーザー・プロファイル属性およびグループ・メンバーシップに関する情報を管理するMember Servicesというコンポーネントを使用しています。

CMRはMember Servicesコンポーネントのインスタンスです。CMRはWebSphere Portal ServerをIDシステムのユーザーおよびグループに接続します。CMRはIBM WebSphere MemberRepositoryインタフェースを実装していて、ポートレットへのアクセス制御の割当てと決定に使用されます。CMRは、user.baseattributesおよびgroup.baseattributesを格納します。読取り操作のみをサポートし、作成操作、変更操作、削除操作をサポートしません。

WebSphere Portal ServerはCMRを使用して、ユーザーのパーソナライズのためのgetAttributes、属性でユーザーを検索するgetGroupMembershipsなどの関数に似た、IdentityXML問合せを作成します。

注意: WebSphere用コネクタはgetGroupMembershipsをサポートしていません。この結果、ネストされたグループでは、内部グループ・メンバーシップをチェックする場合に親グループの詳細が表示されません。

サポート情報の詳細は、「サポートされているバージョンとプラットフォーム」を参照してください。

10.2 統合アーキテクチャ

WebSphereおよびOracle Access Managerの間の統合は、NetPointWASRegistryのみを使用するか、アクセス・システムのシングル・サインオンも使用するかによって異なります。詳細は、次を参照してください。

• 「シナリオ1: NetPointWASRegistryの使用」

• 「シナリオ2: シングル・サインオンのアーキテクチャ」

補足情報は、「ユーザーおよびグループのWASのセキュリティ・ロールへのマッピング」を参照してください。「Oracle Access ManagerCMRとの統合のシナリオ」も参照してください。

10.2.1 シナリオ1: NetPointWASRegistryの使用

NetPointWASRegistryは、IDシステム管理のユーザーおよびグループの情報を取得し、この情報に基づいて認証を実行します。

図10-1は、NetPointWASRegistryを使用したWebSphere用コネクタの実装を説明しています。

図10-1 WebSphere Application ServerとNetPointWASRegistryの統合

このシナリオでは、WebGateの使用はオプションです。WebGateは、シングル・サインオンまたはWebPassの保護にのみ必要です。

注意: このシナリオでは、WASと両方のWebサーバーは同じドメインに所属している必要があります。

プロセスの概要: WASとNetPointWASRegistryを使用するログイン

1. ユーザーがブラウザからWebSphereリソースへのアクセスを試みます。

2. WASはユーザーのリクエストをWebSphere用コネクタに転送します。

3. WebSphere用コネクタはAccess Serverをチェックし、ユーザーを認証します。

4. WASでシングル・サインオンが有効の場合、LTPAトークンが生成されます。

5. WebSphere用コネクタは、WebPassを介してIdentity Serverにユーザーの所属先のグループ・リストを問い合せます。

   Identity Serverはディレクトリをチェックし、情報をWebSphere用コネクタに返します。

6. WebSphere用コネクタはこの情報をWASに返します。

7. WASは、デプロイメント・ディスクリプタをチェックして、ユーザー・セキュリティまたはグループ・セキュリティのロール・マッピングを確認します。

   ユーザーまたはグループが該当のリソースへのアクセスを許可されているセキュリティ・ロールに属する場合、WASはユーザーがリソースにアクセスできるようにします。

10.2.2 シナリオ2: シングル・サインオンのアーキテクチャ

アクセス・システムのシングル・サインオン機能は、認証済のユーザーが再度認証しなくても保護されたリソースにアクセスできるようにします。アクセス・システムのシングル・サインオンを使用するには、TAIを有効にし、WASが稼働するWebサーバー上にAccessGateプラグインをインストールする必要があります。

図10-2は、アクセス・システムのシングル・サインオンを使用するWASを説明しています。

図10-2 WebSphere Application Serverでのシングル・サインオン

注意: このシナリオでは、シングル・サインオンのためにWebGateが必要です。

プロセスの概要: WASとアクセス・システムのシングル・サインオンを使用するログイン

1. ユーザーがアクセス・システムによって保護されたWebSphereリソースへのアクセスを試みます。

2. WebGate（AccessGate）は、基本チャレンジ・メソッドを使用して、リクエストを捕捉し、ユーザー名とパスワードを入力するよう求めます。

3. WebGateはユーザーの資格証明をAccess Serverに渡します。

   Access Serverはユーザー・データ・ストア（ディレクトリ）をチェックし、ユーザーを認証します。WebGateはリクエスト内にObSSOCookieを設定します。

4. Webサーバーはユーザー・リクエストをWASに転送します。

   Oracle Access Manager TAIはリクエストを取得し、ユーザーが認証済であることを確認します。

5. WASはアクセス・システムがユーザーを認証済であることを確認すると、LTPAトークンを作成します。

   このプロセスの残りの手順は、シナリオ1の5〜7と同じです。WASと両方のWebサーバーは同じドメインに所属している必要があります。

6. WebSphere用コネクタは、WebPassを介してIdentity Serverにユーザーの所属先のグループ・リストを問い合せます。

   Identity Serverはディレクトリをチェックし、情報をWebSphere用コネクタに返します。

7. WebSphere用コネクタはこの情報をWASに返します。

8. Oracle Access Manager CMRを使用する場合、「Oracle Access ManagerCMRとの統合のシナリオ」に示す手順でPortal Serverが呼び出されます。

   CMRを使用しない場合、WASは、デプロイメント・ディスクリプタをチェックして、ユーザー・セキュリティまたはグループ・セキュリティのロール・マッピングを確認します。ユーザーまたはグループが該当のリソースへのアクセスを許可されているセキュリティ・ロールに属する場合、WASはユーザーがリソースにアクセスできるようにします。

10.2.3 ユーザーおよびグループのWASのセキュリティ・ロールへのマッピング

WebSphereセキュリティは、J2EEロール・ベースのセキュリティ仕様に適合しています。ロールはアプリケーション用のデプロイメント・ディスクリプタで規定されます。アプリケーションのインストール時に、ロールはOracle Access Managerのユーザーまたはグループにバインドされます。アプリケーション内のロールのバインド情報をWebSphere管理コンソールから変更できます。

Oracle Access Managerはユーザーおよびグループを管理します。WebSphereは、AATを利用して、または管理コンソールからロールを管理します。次の図は、IDシステム・ユーザーからIDシステム・グループ、IDシステム・ユーザーおよびグループからWebSphereロールへのOracle Access Managerのマッピングを示しています。また、メソッドからロールへのWebSphereのマッピングも示しています。

WAS 5の管理コンソールでは、Adminのロールは特別です。IDシステム内でAdminのロールに付加された任意のユーザーは、Admin（Administrator）というグループに属する必要があります。そうでないと、このユーザーは管理コンソールにログインできない可能性があります。monitorなど、他のロールには制約はありません。したがって、WAS 5の管理コンソールでこのロールに付加された任意のOracle Access Managerユーザーは、WAS 5の管理コンソールにログインできます。

10.3 Oracle Access ManagerCMRとの統合のシナリオ

ログイン時にユーザーは、「統合アーキテクチャ」に示す手順で認証されます。CMRを使用しない場合、WebSphere Portal ServerはLDAPディレクトリ・サーバーと直接通信し、ユーザー、グループおよびパーソナライズの情報を取得する必要があります。CMRを使用する場合、WebSphere Portal Serverとディレクトリ・サーバーの間の通信をなくすことができます。CMRは、NetPointWASRegistry経由でディレクトリ・サーバーを使用して読取り操作を実行します。

図10-3は、ログイン認可プロセスでのWebSphere Portal Server、CMRおよびLDAPディレクトリ・サーバー間の相互作用を示しています。これは、「統合アーキテクチャ」に示すプロセスに従っています。

図10-3 WebSphere Portal Serverおよびカスタム・メンバー・リポジトリ

プロセスの概要: CMRを使用した認可

1. 認証の後、ユーザーはWebSphere Portal Serverを通してポートレットへのアクセスをリクエストします。

2. Portal Serverは、リクエストをOracle Access Manager CMRに転送します。

3. CMRはリクエストをNetPointWASRegistryに転送します。

4. NetPointWASRegistryは、IdentityXML呼び出しをIdentity Serverに送信するか、Access Manager SDKを使用し要求されるメソッドに応じてWebPassまたはWebGate経由でAccess Serverに接続します。

   たとえば、Access Manager SDKはcheckPasswordメソッドを使用し、IdentityXMLは次に示す他のすべてのメソッドを使用します。

   • findByAttribute（ユーザーを属性で検索するため）

   • get

   • getGroupMemberIdentifiers

   • getMemberAttributes

   • getMemberships

   • IsAttributeSupported

   • searchMembers

5. Identity Server（またはAccess Server）がLDAPディレクトリ・サーバーと通信します。

6. ディレクトリ・サーバーが情報を返します。

10.4 サポートされているバージョンとプラットフォーム

WebSphere用コネクタには、WebSphere Portal Server用のOracle Access Managerのカスタム・メンバー・リポジトリ（CMR）が組み込まれています。WebSphere用コネクタは、WebSphere Application Server V5.0およびV5.1をCMRでサポートしています。

この章でバージョンとプラットフォームに言及するのは、デモのためです。

この統合用にサポートされているバージョンとプラットフォームを確認するには、次に示すMetalinkを参照してください。

Metalinkの情報を表示する手順

1. 次のURLに移動します。

   http://metalink.oracle.com

2. 「Certify」タブをクリックします。

3. 「View Certifications by Product」をクリックします。

4. 「Application Server」オプションを選択して「Submit」をクリックします。

5. 「Oracle Application Server」を選択して「Submit」をクリックします。

10.5 コネクタのインストール準備

WebSphere用コネクタをインストールして構成する前に、次のタスクを実施する必要があります。

タスクの概要: WebSphere用コネクタのインストール準備

1. 「環境の準備」に示す手順でIBMおよびOracleのAccess Managerコンポーネントをインストールします。

2. 「WAS統合のためのIDシステムの構成」に示す手順で、インストール後にIdentity Serverを構成します。

3. 「WAS統合のためのアクセス・システムの構成」に示す手順で、アクセス・システムの構成を完了します。

4. 「アクセス・システム内でのリソース保護の構成」に示す手順で、リソースの保護を設定します。

5. 「WebSphere V6.0の管理コンソールのポリシー・ドメインの定義」に示す手順で、Websphereの管理コンソールのポリシー・ドメインを定義します。

10.5.1 環境の準備

環境の準備には、適切なIBMアプリケーションおよびOracle Access Managerのインストールが含まれます。

統合のための環境の準備手順

1. ご使用の環境が「サポートされているバージョンとプラットフォーム」に示す要件を満たすことを確認します。

2. 次のIBMアプリケーションおよびコンポーネントを該当製品のIBMドキュメントに従ってインストールし、構成します。

   1. IBM WebSphere Application Server

   2. Application Assembly Tool（AAT）

   3. WebSphere Portal Server

      Oracle Access Manager CMRにはWebSphere Portal Serverが必要です。特定のバージョンに言及するのはデモのためです。詳細は、「サポートされているバージョンとプラットフォーム」を参照してください。

3. WebSphere Portal Server V5: 「サポートされているバージョンとプラットフォーム」を参照し、IBMからの指示に従ってください。フィックス・パックPQ93461を含む最新バージョンであることを確認するために、次の手順のいずれかを実施する必要があります。

   
   

   注意: フィックス・パックPQ93461は、Portal 5.1にはすでに組み込まれています。

   
   

   • WebSphere Portal 5.0.2インスタンスを、V5.0.2用に提供されるインストール・プログラムで新規にインストールします。

   • 既存のWebSphere Portal 5.0のインストールをV5.0.2にアップグレードします。

   • WebSphere Portal 5.1の新規のインスタンスをV5.1用に提供されるインストール・プログラムでインストールします。

   • 既存のWebSphere Portal 5.0または5.0.2のインストールをV5.1にアップグレードします。

4. 『Oracle Access Managerインストレーション・ガイド』に示す手順で、次のOracle Access Managerコンポーネントをインストールして設定します。

   1. Identity Server

   2. WebPass

   3. Policy Manager

   4. Access Server

   5. WebGate

   6. AccessGate

5. 次のようにしてWAS統合を構成します。

   1. IDシステム: 詳細は、「WAS統合のためのIDシステムの構成」を参照してください。

   2. アクセス・システム: 詳細は、「WAS統合のためのアクセス・システムの構成」を参照してください。

6. 「アクセス・システム内でのリソース保護の構成」に示す手順で、WAS用にアクセス・システムのリソースの保護を構成します。

10.5.2 WAS統合のためのIDシステムの構成

Identity ServerとWebPassは、IDシステムの主要な2つのコンポーネントです。WebPassは、アクセス・システムのWebサーバー用プラグインです。ユーザーがWebサーバー・リソースへのアクセスをリクエストすると、WebPassはリクエストをIdentity Serverにリダイレクトします。Identity ServerではユーザーのIDをディレクトリ・サーバーによってチェックします。

Identity ServerとWebPassをインストールした後で、『Oracle Access Managerインストレーション・ガイド』に示す手順でIDシステムを設定する必要があります。設定後、次のようにして統合用のIDシステムを構成します。

タスクの概要: WAS統合のためのIDシステムの構成

1. 必要に応じて「WebPassフェイルオーバーの構成」に示す手順でWebPassフェイルオーバーの準備をします。

2. 「Identity Serverの構成」に示す手順でWAS用のIdentity Serverを設定します。

10.5.2.1 WebPassフェイルオーバーの構成

Oracle Access Managerは、フェイルオーバーを使用してパフォーマンスを最大限に向上させ、エンド・ユーザーに対して途絶えることなくサービスを提供します。フェイルオーバーでは、サーバーに障害が発生した場合にリクエストがリダイレクトされます。各Webサーバー上にWebPassプラグインをインストールする必要があります。WebPassのインスタンスを複数インストールすることもあります。後でフェイルオーバーのためにこれらを構成できます。

詳細は、「コネクタに対する複数WebPassインスタンスの構成」を参照してください。

10.5.2.2 Identity Serverの構成

Identity Serverは、ユーザーおよびグループの情報をWASに提供するOracle Access Managerコンポーネントです。WASで使用される検索メソッドと互換性を持つようにIdentity Serverを構成する必要があります。

NetPointWASRegistryのAdminユーザー用のアカウントを構成します。管理者がログインするのは、Identity ServerへのIdentityXML呼び出しを作成するためです。NetPointWASRegistryのAdminユーザーは、マスター管理者である必要はありません。たとえば、NetPointWASRegistry AdminユーザーがマスターID管理者であっても構いません。しかし、権限を制限するのが望ましい場合、割り当てる管理者に少なくとも次の権限が必要です。

• ユーザー・クラスのクラス属性への表示アクセス権

• グループ・クラスのクラス属性への表示アクセス権

• ユーザーおよびグループ・クラスの適切な検索ベース

• ユーザー・クラスのクラス属性への権限付与および読取りの権限

• グループ・クラスのクラス属性への権限付与および読取りの権限

• 呼び出しでリストされるこれらの属性への表示アクセス権。たとえば、ログインID、グループ・メンバー、グループの動的フィルタなど。

インストール後にIdentity Serverを構成する手順

1. oblixappparams.xmlファイルを開き、searchstringMinimumLengthを次のように0（ゼロ）に設定します。

   Identity_install_dir \identity\oblix\apps\common\bin\oblixappparams.xml

   <NameValPair ParamName="searchstringMinimumLength" Value="0"/>

   ここで、Identity_install_dirはIdentity Serverのインストール先のディレクトリです。

2. groupservcenterparams.xmlファイルを開き、groupMemberSearchStringMinimumLengthを次のように0（ゼロ）に設定します。

   Identity_install_dir \identity\oblix\apps\groupservcenter\bin\groupservcenterparams.xml

   <NameValPair ParamName="groupMemberSearchStringMinimumLength" Value="0"/>

3. Identity Serverを再起動します。

   次の手順は、IDシステムの設定の設定後に行ってください。

4. IDシステム・コンソールから「User Manager」タブをクリックし、次に「構成」サブタブをクリックします。

5. 「委任管理」リンクをクリックし、次のようにして、必要な表示と委任管理の権限を管理者に設定します。

   
   

   注意: 「権限の付与: 読取り」の横の「権限の委任」ボックスを選択しないでください。

   
   
   
   

6. 変更内容を反映するために、WASとWAS管理コンソールを再起動します。

   管理者の構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

10.5.3 WAS統合のためのアクセス・システムの構成

アクセス・システムには、Policy Manager、Access ServerおよびWebGateという3つの主要なコンポーネントがあります。WAS統合においてアクセス・システムのコンポーネントをインストールして構成する上での考慮事項をここに示します。

Policy Manager: 最初にインストールするコンポーネントは、Policy Managerです。Policy Managerを使用して、リソースを保護するポリシー・ドメインを作成して管理し、ポリシーの強制をテストします。アクセス・システム・コンソールはPolicy Managerの一部です。アクセス・システム・コンソールは、管理者の構成、ログの管理、AccessGateおよびAccess Serverのインスタンスの構成など、システム構成およびシステム管理タスクに使用します。

Access Server: 少なくとも1つのAccess Serverをインストールする必要があります。ただし、ユーザーへのサービスを中断させないためには、2つ以上のAccess Serverを2つの別個のマシン上にインストールすることをお薦めします。

各Access Serverは、1つ以上のWebGateインスタンスと通信し、1つのディレクトリ・サーバーと通信するように構成できます。サーバーを複数のタイムゾーンで運用する可能性があるため、Access Serverはアクティビティをグリニッジ標準時（GMT）で記録します。

WebGate: WebGateコンポーネントはオプションです。シングル・サインオンをサポートする場合、またはWebPassを保護する場合に必要です。

AccessGate: AccessGateは、ユーザーまたはアプリケーションからのWebおよび非Webリソースのリクエストを処理するアクセス・システム・コンポーネントです。WebSphere用コネクタはAccessGateを使用してAccess Serverと通信します。

注意: 詳細は、「WAS統合のためのAccessGateの構成」および『Oracle Access Managerアクセス管理ガイド』を参照してください。

10.5.3.1 WAS統合のためのAccessGateの構成

WebSphere用コネクタをインストールする前に、AccessGateをインストールして構成する必要があります。WebSphereはユーザー・リクエストを捕捉し、WebSphere用コネクタに渡します。コネクタはAccessGateを使用し、リクエストの認証と認可のためにAccess Serverを呼び出します。

NetPointWASRegistry用にAccessGateを構成する手順

1. 「AccessGate構成」ページに移動します。

   アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、次に「AccessGate構成」をクリックします。

2. 「追加」ボタンをクリックすると、「新規Access Gateの追加」ページが表示されます。

3. 次の情報を入力します。

   • AccessGate名: このAccessGateを表す一意の説明的な名前。名前には英数字の文字列を使用し、空白は使用しないでください。

   • ホスト名: AccessGateをインストールするマシンの名前。

   • ポート: ポートを指定する必要はありません。AccessGateは、WebGateとは異なり、ポート番号を必要としません。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

   • 「Access Gateのパスワード」および「Access Gateのパスワードを再入力」: トランスポート・セキュリティ・モードであっても、コンポーネントを検証して識別する固有のパスワード。これはAccessGateインスタンスごとに異なる必要があります。

   • アクセス管理サービス: このサービスは、このAccessGateに関連付けるAccess Serverでアクセス管理サービスをオンに設定する場合にのみ有効にする必要があります。

   • トランスポート・セキュリティ: Access Serverとの間のトランスポート・セキュリティのレベル。デフォルト値は「オープン」です。AccessGateのトランスポート・セキュリティ・モードは、Access Serverのトランスポート・セキュリティ・モードと一致している必要があります。

   トランスポート・セキュリティの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

4. 「保存」をクリックします。

   「AccessGateの詳細」ページが表示されます。

5. 「Access Serverをリスト」（または「クラスタをリスト」）ボタンをクリックし、このAccessGateを適切なAccess Serverに関連付けます。

6. このAccessGateに関連付けるAccess Serverを新たに追加するには、「追加」ボタンをクリックします。

7. リストからAccess Serverを1つ選択し、このAccess Serverの構成を定義します。

8. 戻されたページを見直します。

AccessGateの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

10.5.4 アクセス・システム内でのリソース保護の構成

WebSphereのリソースを保護するようにアクセス・システムを構成するには、次の手順を実施する必要があります。

タスクの概要: アクセス・システム内でのリソース保護の構成

1. 「WebSphereのリソース・タイプの定義」に示す手順で、リソース・タイプを指定します。

2. 「WebSphereの認証スキームの定義」に示す手順で、認証スキームを作成します。

3. 「WebSphereのポリシー・ドメインの定義」に示す手順で、アクセス・システム内にポリシー・ドメインを作成します。

4. WebSphere Application Server V6.0の場合は、「WebSphere V6.0の管理コンソール用のポリシー・ドメインの定義」に示す手順で、アクセス・システム内にポリシー・ドメインを作成します。

10.5.4.1 WebSphereのリソース・タイプの定義

次に示す手順でWebSphereのリソース・タイプを定義します。リソース・タイプの定義の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

次の手順では、示されたとおりに厳密にリソース・タイプの値を指定する必要があります。異なるリソース名を指定しなければならない場合は、次の場所でリソース名を変更する必要があります。

• CWS_install_dir \oblix\config\NetPointWASRegistry.properties

  ここで、CWS_install_dirはWebSphere用コネクタのインストール先ディレクトリです。

• WAS_install_dir \properties\webgate.properties

  ここで、WAS_install_dirはWebSphere Application Serverのインストール先ディレクトリです。

デフォルトで、構成ファイルは次の手順で指定した値が入力されたものと想定します。

WebSphereのリソース・タイプを定義する手順

1. アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、次に「共通情報の構成」をクリックします。

2. 「リソース・タイプ定義」をクリックします。

   「リソース・タイプの詳細」ページが表示されます。

3. 次のようにしてリソース・タイプを定義して保存します。

   • リソース名: Authen

   • 表示名: WebSphere認証スキーム

   • リソースの一致: 大/小文字を区別しない

   • リソース操作: ログイン

4. この新しいリソースを有効にするために、Access Serverを再起動します。

10.5.4.2 WebSphereの認証スキームの定義

WebSphereの認証スキームを定義する必要があります。認証スキームは、アクセス・システムが保護するWebSphereリソースへのアクセスがユーザーに許可されているかどうかを判別するときに使用する手段を提供します。

注意: 認証スキームの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

WebSphereの認証スキームを定義する手順

1. アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、次に「認証管理」をクリックします。

2. 次のようにして認証スキームを定義して保存します。

   • 名前: WebSphere Basic Over LDAP

   • 説明: WebSphere関連のURLの保護に使用

   • レベル: WebSphereおよびPortal ServerのURLを保護する認証スキームで指定されたレベル以下のセキュリティ・レベルの数値を入力します。詳細は、「WebSphere V5用のTAIの構成」または「WebSphere V6用のTAIの構成」を参照してください。

   • チャレンジ・メソッド: Basic

   • チャレンジ・パラメータ: マップするユーザー資格証明に対するチャレンジ・パラメータを設定します。

   • SSL必須: いいえ

   • チャレンジ・リダイレクト: 認証プロセスのためにエンドユーザーのリクエストを別のサーバーにリダイレクトする場合、このフィールドに情報を入力します。このフィールドの使用方法としては、非SSLサーバーからSSLサーバーにリダイレクトするのが最も一般的です。リダイレクトはエンドユーザーには意識されません。

   • プラグイン(plug-in): カスタマイズされたチャレンジ・スキームを作成するアクセス・システムのプラグインを選択します。たとえば、Oracle Access and Identityチャレンジ・スキームには、validate_passwordプラグインとcredential_mappingプラグインが必要です。

   ここで、次に説明するようにして、WebSphere Application Server用のポリシー・ドメインを作成する必要があります。

   
   

   注意: ポリシー・ドメインの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

   
   

10.5.4.3 WebSphereのポリシー・ドメインの定義

WebSphereのポリシー・ドメインを作成するには、アクセス・システムを使用する必要があります。このポリシー・ドメインは、「WebSphereのリソース・タイプの定義」で構成したリソース・タイプを保護するためにWebSphereが使用する認証スキームを指定します。アクセス・システムでのアクションも定義します。このアクションは、WebSphere Application Serverのユーザー属性を作成します。ユーザーのWebSphereに対する認証時に、アクション上に定義されたユーザーIDがWebSphere Application Serverに送られます。

WebSphereのポリシー・ドメインの作成手順

1. Policy Managerから「ポリシー・ドメインの作成」をクリックします。

2. 「一般」タブをクリックし、組織の情報を保存します。次に例を示します。

   • 名前: WebSphere

   • 説明: WebSphereで使用するポリシー・ドメイン

   • 有効: はい

   • キャッシュの更新

3. 「リソース」タブをクリックし、組織の次のような情報を入力して保存します。次に例を示します。

   • リソース・タイプ: WebSphere認証スキーム

     これは前に定義したリソースです。WebSphereリソース・タイプの名前を変更した場合は、ここで必ずその名前を指定します。

   • URL接頭辞: /Authen/Basic

   • 説明: NetPointWASRegistryはアクセス・システムでのユーザー認証にこのリソースを使用します。このリソースを削除しないでください。

4. 「デフォルト・ルール」タブ、「認証ルール」、「追加」をクリックし、前に定義したWebSphere Basic認証スキームを使用するデフォルトの認証ルールを作成して保存します。

   • 名前: WebSphere

   • 説明: WebSphere Basic認証スキームを使用するデフォルトの認証ルール。

   • 認証スキーム: Basic Over LDAPタイプ

   Basic Over LDAP認証スキームを作成する必要があります。Access Manager SDKはこのタイプの認証スキームのみ使用します。WebSphere用に別の名前で新しい認証スキームを作成することができますが、認証スキーム・タイプはBasic Over LDAPである必要があります。

5. 「認可ルール」タブをクリックし、WebSphereリソースへのアクセスを許可する認可ルールを作成して保存します。次に例を示します。

   1. 「一般」をクリックし、次のように入力して保存します。

      • 名前: Allow Everyone

      • 説明: WebSphereリソースへのアクセスを許可する。

      • 有効: はい

      • 優先を許可: はい

      デフォルトでは、だれにも許可されていません。デフォルトを「全員を許可」に変更すると、Access Serverは認証のためにユーザーのIDをチェックできます。

   2. 「アクション」（認可成功）をクリックし、次のように入力して保存します。

      • 戻り型: WAS_REGISTRY

      • 名前: uid

        これはハードコードされた値です。厳密にこのとおりの文字列を指定します。

      • 戻り属性: ログイン属性

        この属性は、Identity Serverでログイン・セマンティク型に対して構成された属性またはuidなどユーザーのプロファイルで一意の属性と同じである必要があります。

   3. 「アクセスの許可」をクリックし、次のように入力して保存します。

      • ロール: すべてのユーザー

6. 「OK」をクリックして、新しいポリシー・ドメインを作成します。

これでWebSphere用コネクタをインストールできます。

10.5.5 WebSphere V6.0の管理コンソール用のポリシー・ドメインの定義

Websphere 6.0では、アクセス・システムを使用して、WebSphere管理コンソール用のポリシー・ドメインを作成する必要があります。このドメインは、ibm/consoleフォルダおよび/adminフォルダのコンソールURLを保護します。TAIがWebSphere AppServerで有効な場合に必要です。ドメインは、TAIコンポーネントが必要とするTAI cookieの設定を容易にし、アクセスURLをApplication Server管理コンソール（ポート9060）にリダイレクトします。これらの条件を踏まえて、認可成功のURLも設定する必要があります。

WebSphere管理コンソール用のポリシー・ドメインの作成手順

1. 「Policy Manager」、「ポリシー・ドメインの作成」、「一般」と移動します。

2. 組織の次のような情報を入力して保存します。

   例:

   • 名前: WebSphere管理コンソールの保護

   • 説明: WebSphere管理コンソールのURLに使用するポリシー・ドメイン

3. 「リソース」タブをクリックし、組織の次のような情報を入力して保存します。

   例:

   • リソース・タイプ: http

   • ホスト識別子: Webサーバーをホスティングするマシンに対して定義されるホスト識別子。

   • URL接頭辞: /adminおよびibm/console

   • 説明: NetPointWASRegistry TAIコンポーネントで使用される。

4. 「認可ルール」タブをクリックし、WebSphere管理コンソール・リソースへのアクセスを許可する認可ルールを作成して保存します。

   例:

   1. 「一般」をクリックし、次のように入力して保存します。

      • 名前: Allow Administrator

      • 説明: WebSphere管理コンソール・リソースへのアクセスを許可する。

      • 有効: はい

      • 優先を許可: はい

      デフォルトでは、だれにも許可されていません。デフォルトを管理ユーザーのみに変更すると、Access Serverは認証のためにユーザーのIDをチェックできます。

   2. 「アクション」（認可成功）をクリックし、次のように入力して保存します。

      • リダイレクションURL: http://hostname:9060/ibm/console

        クライアント証明書認証スキームを使用する場合、関連する変数を次のように設定します。

      • リダイレクションURL: https://hostname:9043/ibm/console

        ホスト名は、WebSphere AppServerをホスティングするマシンの完全修飾ドメイン名です。

   3. 「アクセスの許可」をクリックします。

      • 管理権限を持つユーザーを選択し、「保存」をクリックします。

5. 希望する認証スキーム（Basic Over LDAP、フォーム・ベース、クライアント証明書）を使用してデフォルトの認証ルールを作成するには、「デフォルト・ルール」に移動し、「認証ルール」をクリックしてから「追加」をクリックします。次の値を入力して保存します。

   • 名前: WebSphere Default Scheme

   • 説明: 管理コンソールのデフォルト認証ルール

   • 認証スキーム:

   このスキームを、Basic Over LDAP、フォーム・ベースまたはクライアント証明書認証スキームとして作成します。

6. 前に作成したAllow Administratorという認可ルールを指定して認可条件式を作成するには、「デフォルト・ルール」、「認可条件式」、「追加」をクリックし、次に「認可ルールの選択 - Allow Administrator」をクリックします。次に「追加」および「保存」をクリックします。

7. WebSphere用コネクタをインストールします。

8. コネクタをインストールして設定し、TAIも有効にした後で、次の手順を実施してポリシーを有効にします。

   1. 「一般」、「変更」に移動します。

   2. 「有効化」を「はい」に設定し、「保存」をクリックします。

   この段階で、次のいずれかのURLからWebSphere管理コンソールにアクセスできます。

   http://WebServerFQDN:port/admin

   http://WebServerFQDN:port/ibm/console

   ここでWebServerFQDNは、Webサーバーをホスティングするマシンの完全修飾ドメイン名、portはWebサーバーが使用するポート番号です。

10.6 WebSphere用コネクタのインストール

前の項で説明した前提条件を満たした後で、次のようにしてWebSphere用コネクタをインストールできます。

注意: 統合にWebSphere Portal Serverを組み込む場合は、WebSphere用コネクタをインストールする前にポータルをインストールして構成する必要があります。「環境の準備」を参照してください。

ヒント: この統合のアップグレードの詳細は、『Oracle Access Managerアップグレード・ガイド』を参照してください。

タスクの概要: コネクタのインストール

1. 「インストールの開始」に示す手順でインストーラを実行します。

2. 「インストール・ディレクトリの定義」に示す手順でインストール・ディレクトリを作成します。

3. 「コネクタの詳細の指定」に示す手順でコネクタを構成します。

4. 「WebGateの詳細の指定」に示す手順でWebGateを構成します。

5. 「AccessGateの詳細の指定」に示す手順でコネクタを構成します。

6. 「証明書のインストール」に示す手順で証明書をインストールします。

7. 「コネクタに対する複数WebPassインスタンスの構成」に示す手順でWebPassを構成します。

10.6.1 インストールの開始

最初のインストールおよび設定の手順は、Oracle Access Managerのインストール先のプラットフォームによって異なります。

インストールの開始手順

1. インストールCDを挿入します。

   DemoShieldが起動されます。

2. プラットフォームに応じて次のプログラムを起動します。

   Windows: 「Oracle Access Managerのインストール」、「アクセス・システム(Access System)」、「Connector for WebSphere」に移動します。

   UNIX: 次の手順を実行します。

   • /Software/Solaris/AccessSystem/Connector for WebSphereに移動します。

   • /COREidx.x_EN_sparc-s2_Connector_for_WebSphereを実行します。

   インストール・ウィザードが起動されます。

10.6.2 インストール・ディレクトリの定義

この手順の中で、使用許諾条項を受け入れ、WebSphere用コネクタのインストール・ディレクトリを指定します。

WASをインストールしたマシン上にWebSphere用コネクタのインストール・ディレクトリを指定する必要があります。

インストール・ディレクトリを定義する手順

1. 「次へ」をクリックして、「ようこそ」の画面を消します。

2. 使用許諾条項を読んで受け入れ、「次へ」をクリックして続行します。

3. プラットフォームに応じた次の質問に応答します。次に例を示します。

   • Windows: 管理者権限を持ってログインしている場合、「次へ」をクリックします（管理者権限がない場合は「取消」をクリックし、管理者権限を持つユーザーとしてログインしてからインストールを再開します）。

   • UNIX: ユーザー名とグループを指定し、「次へ」をクリックします。

     通常、デフォルトはnobodyです。

   Identity Serverのインストール・ディレクトリを指定するよう求められます。ディレクトリを指定して「次へ」をクリックすると、インストールが開始され、戻って名前を指定しなおすことはできなくなります。

4. 「次へ」をクリックしてデフォルトのディレクトリを受け入れます（または、宛先を変更して「次へ」をクリックします）。

   例:

   \Netpoint

   数秒経過後、コネクタがインストールされたことが通知されます。

   「Oracle Access Manager WebSphere用コネクタの構成」画面が表示されます。

10.6.3 コネクタの詳細の指定

WebSphere用コネクタにWebPassを構成する必要があります。フェイルオーバーのために、インストール時またはNetPointWASRegistry.propertiesファイルから、複数のWebPassインスタンスを構成することができます。

インストール時に複数のWebPassインスタンスを構成するには、WebPassのホスト名とポート番号を入力する際にセパレータとしてカンマを使用します。ホスト名はドメイン名で完全修飾する必要があります。次に例を示します。

ホスト名: foo.domain.com, bar.domain.com

ポート番号: 80, 81

ここで、有効なWebPassのhost:portの組合せは次のとおりです。

• foo.domain.com:80

• bar.domain.com:81

propertiesファイルを使用した複数のWebPassインスタンスの構成の詳細は、「NetPointWASRegistry.properties」を参照してください。

WebSphere用コネクタの詳細を指定する手順

1. 必要となる次の情報を入力します。

   • WebPassのホスト名。: WebPassのインストール先のマシンの完全修飾名。

   • WebPassのポート番号。: WebPassのポート番号。

   • WebPassはWebGateによって保護されていますか。: IDシステム（WebPass）がWebGateによって保護されているかどうかを指定します。

2. 「次へ」をクリックします。

   IDシステムのWebPassがWebGateによって保護される場合、WebGateの構成画面が表示されます。

10.6.4 WebGateの詳細の指定

次の手順は、WebGateの構成の詳細を指定する方法を示しています。

注意: WebGateでWebPassを保護するよう選択した場合、IDシステム・アプリケーションをポリシー・ドメインで保護することを前提としています。また、コンポーネント間のシングル・サインオンが正しく構成されていることも前提となります。

WebGateの構成の詳細を指定する手順

1. WebGateのCookieドメインを入力します（.domain.comなど）。

   これにより、ObSSOCookieはこのドメイン内のすべてのサーバーによって認識されます。

2. Cookieパスを入力します（/）。

3. 「次へ」をクリックします。

4. WebPassがHTTPS接続を必要とするかどうかを指定します。

   これは、WebPassがHTTPSで稼働する場合のセキュアな接続のためのSSLです。

5. ユーザー属性を指定します。

   この属性は、Identity Serverでログイン・セマンティク型に対して構成されている属性、またはユーザーのプロファイルの一意属性（uidなど）と同じである必要があります。

6. ユーザー検索属性を指定します。

   ユーザー属性とユーザー検索属性を同じにすることはできません。

   この属性は、Identity ServerのPersonオブジェクト・クラスのDN接頭辞セマンティク型に対して構成された属性と同じである必要があります。Personオブジェクト・クラスは、構造化オブジェクト・クラスである必要があります。この検索属性は、ディレクトリ・サーバーの管理者によって設定されます。

7. グループ検索属性を指定します。

   この属性は、Identity ServerのGroupオブジェクト・クラスのDN接頭辞セマンティク型に対して構成された属性と同じである必要があります。Groupオブジェクト・クラスは、構造化オブジェクト・クラスです。グループ検索属性は、ディレクトリ・サーバーの管理者によって設定されます。

8. 「はい」を選択して、WebSphere用コネクタのjarファイルをWebSphere用コネクタのインストール・ディレクトリから次のディレクトリにコピーするよう指定できます。

   WAS_install_dir /lib

   ここで、WAS_install_dirはWASをインストールしたディレクトリです。

   「いいえ」を選択した場合は、インストール後に手動でjobaccess.jarおよびNetPointWASRegistry.jarファイルをWAS_install_dir/libにコピーできます。あるいは、jarファイルの場所をWebSphereランタイム・クラスパスに追加します。

9. 「次へ」をクリックします。

   「WebSphereクラス・ディレクトリ」画面が表示されます。

10.6.5 AccessGateの詳細の指定

次に示す手順で、AccessGateのトランスポート・セキュリティ・モードおよびその他のAccessGateの詳細を指定します。AccessGatesの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

AccessGateの詳細を指定する手順

1. Access Serverに指定したトランスポート・セキュリティ・モードと同じものを選択します。

   次に表示されるページは、選択したトランスポート・セキュリティ・モードによって異なります。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。

2. 「次へ」をクリックします。

3. AccessGateの次の情報を入力します。

   • Access Gate ID: アクセス・システム・コンソールでAccessGateを追加した際に指定した名前を入力します。

   • Access Server ID: このAccessGateに関連付けたAccess Serverの名前を入力します。

   • AccessGateのパスワード: 適用可能な場合、アクセス・システム・コンソールでAccessGateを追加した際に指定したAccessGateのパスワードを入力します。

     このAccessGateに関連付けられた任意のAccess Serverを指定できます。

   • Access Serverがインストールされているホスト名: このAccessGateに関連付けられたAccess Serverの完全修飾されたホスト名を入力します（例: stontium.oblix.com）。

   • Access Serverがリスニングするポート番号: このAccessGateに関連付けられたAccess Serverのポートを入力します。

   • グローバル・アクセス・プロトコル・パスフレーズ: Access ServerやWebGateなど、すべてのOracle Access Managerコンポーネントのパスフレーズを入力します。

     このフィールドは、簡易モードまたは証明書モードを指定した場合にのみ表示されます。

   • グローバル・アクセス・プロトコル・パスフレーズ確認: 確認のためにパスフレーズを再入力します。

4. 「次へ」をクリックします。

   簡易モードまたは証明書モードを指定した場合にのみ、新しい「AccessGate構成」画面が表示されます。

   • トランスポート・セキュリティに証明書が必要な場合、「証明書のリクエスト」を選択します。

     アクセス・システムは証明書のリクエストを送出します。

   • すでに証明書がある場合は、「証明書のインストール」を選択してインストールします。

5. 「次へ」をクリックします。

   「証明書のインストール」を選択した場合、「AccessGate構成」画面が再表示されます。

10.6.6 証明書のインストール

証明書ファイル、連鎖ファイルおよびキー・ファイルへのパスを指定する必要があります。

注意: インストールが予期せず失敗した場合、またはこれらの設定を後で変更する必要がある場合、CWS_install_dir\oblix\tools\configureAccessGateにあるconfigureAccessGateツールを実行できます。ここで、CWS_install_dirはWebSphere用コネクタのインストール先のディレクトリです。

証明書ファイルのパスを指定する手順

1. 証明書ファイル、連鎖ファイルおよびキー・ファイルへのフルパスを入力します。

   証明書はこれらのファイルから構成されます。必要に応じて、「参照」をクリックしてこのファイルの場所に移動します。

2. 「次へ」をクリックすると概要画面が表示されます。次に「終了」をクリックします。

   インストールは完了しました。

   ここで必要に応じて、WebSphere用コネクタの複数のWebPassインスタンスを構成します。

10.6.7 コネクタに対する複数WebPassインスタンスの構成

Oracle Access Managerは、フェイルオーバーを使用してパフォーマンスを最大限に向上させ、エンド・ユーザーに対して途絶えることなくサービスを提供します。フェイルオーバーにより、サーバー障害の発生時にリクエストがリダイレクトされます。フェイルオーバーのために、複数のWebPassインスタンスの構成する場合があります。

この項では、複数のWebPassインスタンスをすでにインストール済であることを想定しています。フェイルオーバーの詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。

WebSphere用コネクタの複数のWebPassインスタンスを構成する手順

1. 次のNetPointWASRegistry.propertiesファイルを開きます。

   CWS_install_dir/oblix/config/NetPointWASRegistry.properties

   ここで、CWS_install_dirはWebSphere用コネクタのインストール先ディレクトリです。

2. 次のようなカンマ区切りのリスト形式で、WebPassの完全修飾ホスト名、ドメイン名およびポート番号を入力します。

   # IdentitySystem WebPass webserver host name and port number
   OB_WebPassHost=foo.domain.com,bar.doman.com
   OB_WebPassPort=81,80
   
   

   この例で、有効なWebPassのhost:portの組合せは次のとおりです。

   • foo.domain.com:81

   • bar.domain.com:80

3. 次のようにして、コネクタの設定を完了します。

10.7 コネクタの設定の完了

WebSphere用コネクタのインストール後、WebPassやAccess Serverなど、通信先のOracle Access Managerコンポーネントの情報を指定する必要があります。

タスクの概要: コネクタの設定の完了

1. 「WebSphere用コネクタの設定」に示す手順でコネクタの設定を完了します。

2. 「環境設定のテスト」に示す手順でコネクタ環境をテストします。

10.7.1 WebSphere用コネクタの設定

次の手順で、インストール中に追加されたjarファイルが適切な場所にあることを確認するか、その場所をWebSphereクラスパスに追加します。環境変数パスが正しいことも確認します。これが必要なのは、実行時にNetPointWASRegistryがOracle Access Managerインストール・ディレクトリにあるobaccess.dllファイル（Windows）またはlibobaccess.soファイル（UNIX）を探すためです。

WebSphere用コネクタの設定手順

1. インストール時に追加された次のjarファイルがディレクトリWAS_install_dir/lib内に存在することを確認するか、これらのjarファイルの場所をWebSphereクラスパスに追加します。

   • NetPointWASRegistry.jar

   • jobaccess.jar

2. 次のようにして、CWS_install_dir\oblix\libを環境変数パスに追加します。

   Solaris: setupCmdLine.shファイルに次を追加します。

   CWS_install_dir\oblix\lib to $LD_LIBRARY_PATH

   ここで、CWS_install_dirはWebSphere用コネクタのインストール先ディレクトリです。

   
   

   注意: Access Manager SDKが見つからない場合、NetPointWASRegistryはインストールに失敗することがあります。次の環境変数をsetupCmdLine.shに追加する必要があります。OBACCESS_INSTALL_DIR=CWS_install_dir

   
   

   AIX: setupCmdLine.shファイルに次を追加します。

   CWS_install_dir\oblix\lib to $LIBPATH

   WebSphere Administration Serverを再起動します。

   Windows 2000: インストーラが自動的に情報を追加します。ただし、次のことが可能です。

   1. 手動でCWS_install_dir\oblix\libをPATHシステム変数に追加します。

   2. マシンを再起動します。

   3. WebSphere Administration Serverを起動します。

3. WebGateがWebPassを保護する構成になっていることを確認します。

   アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、左側のナビゲーション・ペインの「AccessGate構成」をクリックし、WebPassを保護するWebGateのリンクをクリックして、「IPValidation」フィールドで「オフ」オプションを選択します。

   Oracle Access Manager 10.1.4では、WebGateStatic.lstファイルは存在しなくなりました。このファイルのオプションはアクセス・システム・コンソールに移行されました。詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

4. Webサーバーを再起動します。

5. CWS_install_dir \oblix\configにあるNetPointWASRegistry.propertiesファイルの情報を確認します。

   ここで、CWS_install_dirはWebSphere用コネクタのインストール先ディレクトリです。このファイルにはインストール時に指定された情報が埋め込まれます。詳細は、「NetPointWASRegistry.properties」を参照してください。

6. WebPassをホスティングするマシンでSSLが機能しているどうかを確認し、機能していれば次の手順を実行します。

   1. NetPointWASRegistry.propertiesファイルを開き、OB_WebPassSSLEnabled = Trueと設定します。

   2. SSLモードで稼働するWebPassまたはWebGateをホスティングするWebサーバーのWebサーバー証明書とCA証明書を取得し、それぞれをserver.cerファイルとca.cerファイルに格納します。

   3. JAVA_HOME\binまたはJAVA_HOME\jre\binのkeytoolを使用して、次のCA証明書およびサーバー証明書をjssecacertキーストアに追加します。

      • keytool -import -alias ca -file ca.cer -keystore jssecacert

      • keytool -import -alias server -file server.cer -keystore jssecacert

   4. このファイルは、使用するJavaのバージョンによってJAVA_HOME\lib\securityまたはJAVA_HOME\jre\lib\securityのセキュリティ・ディレクトリにコピーします。

WebSphere用コネクタでは、WebPassを使用してIdentityXML呼び出しを行います。WebSphere用コネクタで指定できるWebPassは一度に1つのみです。一般に、これはPolicy Managerをホスティングするのと同じWebサーバー上で稼働します。WebPassが複数あり、WebPassごとにWebSphere用コネクタを構成する場合、インストール後にNetPointWASRegistry.propertiesファイルでホスト・マシンとポートを変更できます。

NetPointWASRegistry.propertiesファイルを編集する場合、WebSphere Administration Serverを再起動する必要があります。

注意: WebPassがWebGateによって保護されている場合、この認証スキームのセキュリティ・レベルが「WebSphereの認証スキームの定義」に示すWebSphere認証スキームで指定したレベル以下であることを確認します。

10.7.2 環境設定のテスト

NetPointWASRegistryを有効にする前に、registryTesterプログラムを実行し、NetPointWASRegistryが登録されていて、正常にIDシステムに接続できることを確認する必要があります。

次の手順は、WASのすべてのバージョンに適用されます。

注意: Linuxシステムでは、次のようにして、LD_ASSUME_KERNEL環境変数が2.4.1.0に設定されていることを確認します。 LD_ASSUME_KERNEL=2.4.19 export LD_ASSUME_KERNEL

registryTesterプログラムの実行手順

1. CWS_install_dir/unsupportedディレクトリ内のファイルregisterTester.bat（Windows）またはregistryTester.sh（UNIX）を編集します。

   ここで、CWS_install_dirはWebSphere用コネクタのインストール先ディレクトリです。

2. 2つの変数を次のように変更します。

   • INSTALL_DIR: WebSphere用コネクタへのパスを指定します。

   • WAS_INSTALL_DIR: WASへのパスを指定します。

3. 適切なクラスパスを指定し、インストールで使用しないクラスパスをコメント化します。

   • WebSphere 5.0とコネクタ7.0: V5.0のWebSphereクラスパスを保持し、関連付けられていないWebSphereクラスパスをコメント化します。

   • WebSphere 5.0.2: V5.0.2のWebSphereクラスパスを保持し、関連付けられていないWebSphereクラスパスをコメント化します。

   • WebSphere 5.1とコネクタ7.0.2: V5.1のWebSphereクラスパスを保持し、関連付けられていないWebSphereクラスパスをコメント化します。

   • WebSphere 6.0とコネクタ7.0.4: V5.1のWebSphereクラスパスを保持し、関連付けられていないWebSphereクラスパスをコメント化します。

4. JAVA_HOME環境変数を定義しない場合、registryTester.batファイルまたはregistryTester.shファイルでJAVA_HOMEパラメータを次のように設定します。

   Windows: %JAVA_HOME% = WAS_install_dir \java

   UNIX: $JAVA_HOME$ = WAS_install_dir /java

   ここで、WAS_install_dirはWebSphereをインストールしたディレクトリです。

5. WebSphere 5.xのみ: registryTester.sh（WindowsではregistryTester.bat）を次のように更新します。

   set CLASSPATH=.:${CLASSPATH}:${INSTALL_DIR}/oblix/lib/NetPointWASRegistry.jar:${INSTALL_DIR}/oblix/lib/jobaccess.jar:${WAS_INSTALL_DIR}/lib/xerces.jar:${WAS_INSTALL_DIR}/lib/j2ee.jar:${WAS_INSTALL_DIR}/lib/wssec.jar:${WAS_INSTALL_DIR}/java/jre/lib/ext/ibmjsse.jar
   
   

   
   

   注意: registryTester.batの詳細をチェックすることができます。

   
   

6. コマンドラインからregistryTesterを実行します。

   • NT/W2K: registryTester.bat

   • UNIX: registryTester.sh

7. 入力を求められたらOracle Access ManagerのユーザーIDとパスワードを指定します。

8. 結果を確認します。

   • プログラムは正常に完了すると、Identity Serverに接続し、ユーザーが属するグループのリストを返します。

   • registryTesterプログラムがAccess ServerまたはIdentity Serverとの接続に失敗した場合は、NetPointWASRegistry.propertiesファイルのパラメータの値を確認し、必要に応じて訂正してください。

10.8 WebSphere Application Server V5の構成

次の項では、Oracle Access ManagerとWebSphere Application Server V5.0またはV5.1の統合を扱います。

開始する前に、サポートされているバージョンの詳細は、「サポートされているバージョンとプラットフォーム」を参照してください。

タスクの概要: WAS V5との統合

1. 「WAS V5でのNetPointWASRegistryの有効化」に示す手順でレジストリを有効化します。

2. 「WebSphere V5のNetPointWASRegistryのテスト」に示す手順で構成をテストします。

3. 「WebSphere V5のTAIの構成」に示す手順でTAIを構成します。

10.8.1 WAS V5でのNetPointWASRegistryの有効化

製品をインストールし、通信できることをテストで確認したら、NetPointWASRegistryを有効化できます。レジストリを有効化すると、WebSphere Application Serverの認証ソースとしてOracle Access Managerが使用されます。

NetPointWASRegistryはWebSphere 5のユーザー・レジストリで動作します。

注意: 次の手順では、Adminのロールに付加された任意のIDシステム・ユーザーは、Admin（Administrator）というグループに属する必要があります。そうでないと、このユーザーはWebSphere管理コンソールにログインできない可能性があります。monitorなど、他のロールには制約はありません。したがって、WAS 5の管理コンソールでこのロールに付加された任意のIDシステム・ユーザーは、WAS 5の管理コンソールにログインできます。

WAS V5でNetPointWASRegistryを有効化する手順

1. Linuxシステムでは、次の場所のLD_ASSUME_KERNEL環境変数が2.4.19に設定されていることを確認します。

   WAS_install_dir/bin/setupCmdLine.sh
   
   

   次のコマンドで環境変数を設定します。

   LD_ASSUME_KERNEL=2.4.19
   export LD_ASSUME_KERNEL
   
   

2. WebPassを保護するWebGateで「IPValidation」が「オフ」に設定されていることを確認します。

   アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、左側のナビゲーション・ペインの「AccessGate構成」をクリックし、WebPassを保護するWebGateのリンクをクリックして、「IPValidation」フィールドで「オフ」オプションを選択します。

3. security.xmlのバックアップ・コピーを作成します。

   次の手順で構成を変更します。構成を変更する前に、security.xmlのバックアップ・コピーを作成する必要があります。変更後の構成でエラーがあった場合、いつでも前のバージョンのsecurity.xmlファイルをリストアできます。

4. 次のディレクトリにあるsecurity.xmlファイルをコピーします。

   WAS_install_dir/config/cells/serverName

5. WebSphere管理サービスを開始します。

6. ID管理者としてWebSphere管理コンソールにログインします。

7. 「Security」、「User Registries」、「Custom Properties」に移動し、次を入力します。

   • Identity AdministratorのユーザーID

   • サーバー・ユーザーのパスワード

   • カスタム・レジストリ・クラス名

   • IDシステムの管理者ID

   • ユーザーのパスワード

   • Oracle Access Managerクラス名: com.oblix.registry.NetPointWASRegistry

   
   

8. 「Configuration」タブの「Additional Properties」の下で、「Custom Properties」をクリックし、「New」をクリックし、次を入力します。

   • Name: NetPointWASRegistry.properties

   • Value: C:\CWS_install_dir\oblix\config\NetPointWASRegistry.properties.

   • Description: Oracle Access Managerユーザー・レジストリのプロパティ・ファイル

   • 「Required」チェック・ボックスを選択し、「OK」をクリックして変更を保存します。

   
   

9. 左側のナビゲーション・ペインで「Authentication Mechanisms」、「LTPA」をクリックします。

10. 「Configuration」タブでパスワードを指定します。

11. 「OK」をクリックします。

12. 「LTPA」に戻り（左側のナビゲーション・ペインで「Authentication Mechanisms」、「LTPA」をクリックする）、次を行います。

    • 「Single Signon (SSO)」をクリックします。

    • 「Enabled」ボックスをクリックします。

    • ドメイン名を入力します。たとえば、.oracle.comです。

    • 「OK」をクリックします。

      
      

13. 左側のナビゲーション・ペインで、「Security」、「Global Security」をクリックし、次を変更します。

    1. 「Active Authentication Mechanism」を「LTPA」に設定します。

    2. 「Active User Registry」を「Custom」に設定します。

    3. 「OK」をクリックします。

    4. 「Enabled」ボックスをクリックします。

    5. 構成をテストするには「Apply」をクリックします。

       情報が正しい場合、変更を確認するメッセージが上部に表示されます。エラーが表示された場合は訂正します。

    6. 「Save」をクリックします。

    7. 「Logout」をクリックし、ブラウザ・ウィンドウを閉じます。

    8. WebSphere Application Serviceを停止します。

       サービスを停止できなかったというメッセージを受け取ったら、タスク・マネージャに切り替え、javaプロセスが実行されていないかどうかを確認します。

14. WebSphere管理サービスを開始します。

10.8.2 WebSphere V5のNetPointWASRegistryのテスト

次に、NetPointWASRegistryが正しく構成されていることを検証します。

NetPointWASRegistry構成をテストする手順

1. 次のデフォルト・サーバー上で稼働するSnoopサーブレットのサンプルにアクセスします。

   http://hostname:port/snoop

   または

   http://hostname:web_server_plug-in_port/snoop

2. WebSphereによってチャレンジ方式の認証を求められたら、Oracle Access Managerで有効なユーザー名とパスワードを入力します。

   デフォルトで、任意の認証ユーザーにアクセスが許可されます。

3. WebSphere管理コンソールを起動し、「Security」、「User Registries」、「Custom Properties」で指定されたユーザーとしてログインします。

   構成が正しい場合、正常にログインできます。

4. ユーザーおよびグループと所属するロールを指定して、WebSphere管理コンソールのアクセス制御を設定します。

   詳細はWebSphere 5のドキュメントを参照してください。

5. 管理コンソールのアクセスをサポートするよう変更された.xmlファイルを確認し、「保存」をクリックします。

WebSphere用コネクタをインストールした後、NetPointWASRegistryおよびTAIを構成する必要があります。NetPointWASRegistryは認証に使用され、TAIはOracle Access Managerによるシングル・サインオンを有効にします。

10.8.3 WebSphere V5のTAIの構成

TAIを構成し、Oracle Access ManagerとWASの間およびOracle Access ManagerとWebSphere Portal Serverの間のシングル・サインオンを有効にします。WebSphere 5.0または5.1では、webgate.propertiesをインストールし、TAIを追加してからカスタム・プロパティを追加する必要があります。

注意: Linuxシステムでは、次のように、対応するWebServer起動スクリプトでLD_ASSUME_KERNEL環境変数が2.4.19に設定されていることを確認します。 LD_ASSUME_KERNEL=2.4.19 export LD_ASSUME_KERNEL

ヒント: オプションの詳細は、「TAIの実装の注意事項」を参照してください。

WAS 5のTAIをインストールして構成する手順

1. webgate.propertiesという名前の構成ファイルをコピーします（パラメータは表10-2を参照）。

   コピー元: CWS_install_dir /oblix/config

   コピー先: WebSphereインストール・プロパティ・ディレクトリ内のWAS_install_dir /propertiesフォルダ

   ここで、CWS_install_dirはWebSphere用コネクタがインストールされているディレクトリで、WAS_install_dirはWebSphere Application Serverがインストールされているディレクトリです。

   このファイルには、WebSphereがAccessGateへの接続に使用する構成情報が含まれています。

2. WebSphereインストール・プロパティ・ディレクトリで、webgate.propertiesファイルのパラメータ値を次のように変更します（表10-2を参照）。

   OB_InstallDir = CWS_install_dir

   ここで、CWS_install_dirはWebSphere用コネクタのインストール先ディレクトリです。次に例を示します。

   C:\COREid\NetPointWASRegistry
   
   

   フロント・エンド・サーバーとして使用されるプロキシ・サーバー上にWebGateがインストールされていて、WebSphere Application ServerとのインタフェースとなるWebサーバーにすべてのユーザー・リクエストを振り向けている場合、次のパラメータ値を指定します。

   • OB_IsProxyEnabled=true

   • OB_hostnames = serverName

     ここで、serverNameはプロキシ・サーバーの名前です。

   • OB_ports = portNumber

     ここで、portNumberはプロキシ・サーバーのポート番号です。

     
     

     注意: Authen以外のリソースを使用する場合、webgate.propertiesファイルにリソース名を指定する必要があります。

     
     

3. WebSphere管理コンソールを起動します。

4. 左側のナビゲーション・ペインで「Authentication Mechanisms」、「LTPA」をクリックします。

5. 「Additional Properties」の下で「Trust Association」、「Interceptors」、「New」をクリックします。

6. 「Name」フィールドに「Oracle TAI Interceptor」と入力します。

7. 「Interceptor classname」フィールドに「com.oblix.tai.was5.WebGateTrustAssociationInterceptor」と入力します。

   
   

8. 「OK」をクリックします。

9. 次の3つのプロパティを追加します。

   1. Name: com.ibm.websphere.security.trustassociation.types

      • Value: webgate

      • Description: TAIプロパティ

      • 「Required」チェック・ボックスを選択します。

      • 「OK」をクリックします。

   2. Name: com.ibm.websphere.security.trustassociation.webgate.config

      • Value: webgate

      • Description: WAS_install_dir/propertiesディレクトリ内にあるTAIプロパティ・ファイルの名前。

      • 「Required」チェック・ボックスを選択します。

      • 「OK」をクリックします。

   3. Name: com.ibm.websphere.security.trustassociation.webgate.interceptor

      • Value: com.oblix.tai.was5.WebGateTrustAssociationInterceptor

      • Description: WebSphere 5のTAIクラス

      • 「Required」チェック・ボックスを選択します。

      • 「OK」をクリックします。

        
        

10. ページの上部にある「Interceptors」をクリックし、「Save」をクリックします。

11. 次の場所に移動します。

    WAS_install_dir /config/cells/serverName_dir

    ここで、serverName_dirはサーバーのインストール先ディレクトリです。

12. security.xmlファイルのバックアップ・コピーを作成します。

13. WebSphere管理コンソールで、「LTPA」、「Trust Association」、「Interceptors」に移動します。

14. 「WebSeal Interceptor」を選択し、「Delete」をクリックします。

15. 「Trust Association」をクリックし、「Enabled」チェック・ボックスをクリックします。

16. 「Apply」をクリックし、「Save」をクリックします。

17. WebSphere管理コンソールからログアウトし、ブラウザを閉じます。

18. Websphere Admin Serverを停止します。

    エラー・メッセージが表示される場合は、タスク・マネージャを参照し、Javaプロセスが稼働していないことを確認します。

19. WebSphere管理サービスを再度開始します。

    サービスが開始されない場合は、security.xmlファイルでプロパティが正しく設定されていることと、webgate.propertiesファイルが正しい場所にあることを確認します。

20. WebSphereリソースを保護するアクセス・システム・ポリシーを作成します。

    Policy Managerで、保護するリソースのポリシーを定義します。

    この段階で他の認可ルールを追加することもできます。URLを保護するためのポリシーには、アクセス・システムをサポートする、Basic認証スキーム、フォーム認証スキーム、Cert認証スキーム、その他の認証スキームを使用できます。

    この認証スキームのセキュリティ・レベルが、「環境の準備」に示すWebSphere認証スキームで指定したレベルと同等またはそれ以上であることを確認します。

    ポリシーの定義の詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

21. 次の項で、TAIが動作していることを確認します。

10.8.3.1 WAS V5のTAIのテスト

TAIを構成した後、WASを再起動し、WebSphereとOracle Access Managerの間の認証とシングル・サインオンが正常にできるかどうかをテストします。

これらのテストを実施するには、WebSphereが提供するSnoopサーブレットを使用します。Snoopサーブレットには、認証されたユーザーのみにアクセスを許可するセキュリティの制約があります。WebSphereセキュリティが有効になっていない場合、Snoopへのアクセスは制限されません。WebSphereセキュリティとTAIが有効になっている場合、Snoopへのアクセスを試みるユーザーはアクセス・システムによってチャレンジ方式の認証を求められます。TAIが有効になっていない場合、Snoopへのアクセスを試みるユーザーはWebSphereによってチャレンジ方式の認証を求められます。

アクセス・システムのWASへのシングル・サインオンをテストするには、新たにセキュアなWebSphereアプリケーションを構築して構成する必要があります。次に、セキュアなアプリケーションに対するアクセス・システムの認証とシングル・サインオンをテストします。

インストール時に、テストに使用できるセキュアなアプリケーションが構築され、次の場所に格納されます。

CWS_install_dir/examples/securityapp/SimpleSessionSecure.ear

ここで、CWSはコネクタをインストールしたディレクトリです。

注意: 必要に応じて、独自のセキュアなアプリケーションを構築できます。次の手順では、WAS 5.xのアプリケーションを構築する方法を説明しています。

WebSphereのセキュア・アプリケーションを構築する手順

1. 次のURLから入手できる手順に従って、SimpleSessionSecureという名前のセキュアなアプリケーションを構築します。

   http://www-3.ibm.com/software/webservers/appserv/doc/v40/ae/ infocenter/was/060704_security.html

2. SimpleSessionSecure.earファイルを適切な場所（たとえば、c:\temp）に保存します。

3. WAS Administration Serverが稼働していることを確認します。

SimpleSessionSecureアプリケーションをインストールする手順

1. WAS_install_dir \bin\adminclientにあるWebSphere管理コンソールを起動します。

   ここで、WAS_install_dirはWebSphere Application Serverのインストール先ディレクトリです。

2. WebSphere Consoleツリー・ビューで、「WebSphere Administrative Domain」、「Enterprise Applications」を右クリックします。

3. 表示されたメニューで、「Install Enterprise Application」をクリックして、Install Enterprise Applicationウィザードを起動します。

   「Specifying the Application or Module」パネルが表示されます。

4. 次の設定を確認します。

   • 「Browse for file on node」フィールドを現在使用しているノードに設定します。

   • 「Install Application」オプションを選択します。

5. 「Browse」をクリックし、SimpleSessionSecure.earファイルを見つけて選択します。

6. 「Path」フィールドに名前が表示されていることを確認し、アプリケーション名としてSimpleSessionSecureを指定します。

7. 「Next」をクリックし、保護されていないメソッドへのアクセスを拒否するかどうかを尋ねられたら「Yes」をクリックします。

8. 「Mapping Users to Roles」パネルでGoodguysロールが有効なIDシステム・ユーザーにマッピングされていることを確認します。

9. 「Select」をクリックし、表示された「Select Users/Groups」ダイアログの「Selected Users/Groups」領域にIDシステム・ユーザーがリストされていることを確認した後で、「OK」をクリックしてダイアログを閉じます。

10. 「Next」をクリックします。

11. 「Mapping EJB RunAs Roles to Users」パネルで「Next」をクリックします。

12. 「Binding Enterprise Beans to JNDI Names」パネルで、「JNDI Name」が「gs/hello」に設定されていることを確認し、「Next」をクリックします。

13. 「Mapping EJB References to Enterprise Beans」パネルで、「JNDI Name」が「gs/hello」に設定されていることを確認し、「Next」をクリックします。

14. 次の3つのパネルで「Next」をクリックすると、「Selecting Virtual Hosts for Web Modules」パネルが表示されます。

15. 「Selecting Virtual Hosts for Web Modules」パネルで「Virtual Host」が「default_host」に設定されていることを確認し、「Next」をクリックします。

16. 「Selecting Application Server」パネルでEJB11モジュールとSimpleSessionWarモジュールがDefault Serverという名前のApplication Server上にあることを確認し、「Next」をクリックします。

17. 「Completing the Application Installation Wizard」パネルで「Finish」をクリックします。

18. コードの再生成を求められたら「No」をクリックします。

19. アプリケーションが正常にインストールされたことを確認するメッセージを探します。

    表示される時点より少し前である可能性があります。これで、WebSphere管理コンソールのツリー・ビューでSimpleSessionSecureアプリケーションを確認できます。

20. SimpleSessionSecureアプリケーションを構築した後、プラグイン構成を再生成し、WebサーバーがWebSphereアプリケーションを検出できるようにします。

プラグイン構成を再生成する手順

1. コンソール・ツリー・ビューで、「WebSphere Administrative Domain」、「Nodes」、「hostname」を右クリックします。

   ここで、hostnameはWebSphereがインストールされているマシンの名前です。

2. 表示されるメニューから、「Regen Webserver Plugin」を選択します。

3. 「Event Message」パネルに、プラグイン再生成が完了したことを通知するメッセージが表示されます。

4. WebSphere Administrative Serverを停止して再度起動します。

   WebSphere管理コンソールの「Nodes」の下の管理サーバーを停止するには、hostnameを右クリックし、表示されるメニューから「Restart」を選択します。コンソールが閉じます。

5. 管理サーバーが開始した後で、WebSphere管理コンソールを再度開きます。

   今回は、セキュリティが有効になるのでログインを求められます。

6. WebSphere管理コンソールのツリー・ビューで、「WebSphere Administrative Domain」、「Nodes」、「hostname」、「Application Servers」、「Default Server」をクリックします。

   ここで、hostnameはWebSphereがインストールされているマシンの完全修飾名です（たとえば、xyz.domain.com）。

7. 「Default Server」の「Module Visibility」設定が「Compatibility」に設定されていることを確認します。

8. 可視性の設定を変更する場合は、「Apply」をクリックします。

アクセス・システムの認証とシングル・サインオンをテストする手順

1. 次のURLでSimpleSessionSecureアプリケーションにアクセスします。

   http://hostname/gettingstarted3/SimpleSession?msg=Hi

   ここで、hostnameはWebSphereがインストールされているマシンの完全修飾名です（たとえば、xyz.domain.com）。

2. Oracle Access Managerユーザーとしてログインします。

   • TAIが有効でない場合: TAIを有効にしていない場合、WebSphereからチャレンジ方式の認証を求められ、資格証明がアクセス・システムに渡されます。アクセス・システムの認証が済んだ後、SimpleSessionSecureへのアクセスが許可されます。

   • TAIが有効な場合: TAIを有効にしている場合、アクセス・システムからチャレンジ方式の認証を求められて認証されます。アクセス・システムとWASの間のシングル・サインオンが有効なので、WebSphereからチャレンジ方式の認証を受けずに、SimpleSessionSecureおよびアクセス・システムが保護する他のリソース（URL）へのアクセスが許可されます。

アクセス・システムが保護するWebSphereリソースのシングル・サインオンをテストする手順

1. WASのアクセスに使用するWebサーバー上で、ドキュメント・ルートに移動し、testという名前のディレクトリを作成します。

2. testディレクトリで、index.htmlという名前のファイルを作成します。

3. アクセス・システムで、/servletディレクトリおよび/testディレクトリを保護するポリシーを作成して有効にします。

4. 次のURLでSnoopサーブレットにアクセスします。

   http://hostname.domain.com:9080/servlet/snoop

   ここで、hostnameはWebSphereがインストールされているマシンの完全修飾名です（たとえば、xyz.domain.com）。

   チャレンジ方式の認証を受けます。認証されると、Snoopサーブレットにアクセスできます。

5. /test URLにアクセスします。

   チャレンジ方式の認証を受けずに、URLへのアクセスとindex.htmlファイルの表示が許可される必要があります。

10.8.3.2 WAS V5のTAIのログの有効化

WebSphere管理コンソールからTAIのログを有効化できます。ログを有効化する手順は、使用するWASのバージョンによって異なります。

WAS V5のTAIのログを有効化する手順

1. WebSphere管理コンソールを起動します。

2. 「Troubleshooting」、「Logs and Trace」に移動します。

3. サーバーを選択します。

4. 「Diagnostic Trace」を選択します。

5. トレース指定を変更します。

6. 「Components」タブを選択します。

7. com.oblix.tai.was5.WebGateTrustAssociationInterceptorのデバッグ・ログを有効化します。

8. 必要に応じて、Oracle Access ManagerをWAS Portal v5と統合します。

10.9 WebSphere Portal V5との統合

ポータルは、エンタープライズ・データおよびアプリケーションへの単一のアクセス・ポイントを提供し、従業員、顧客およびビジネス・パートナーに対して、統一されていると同時にパーソナライズされた情報表示を実現します。

WebSphere Portal ServerはWAS上で実行され、WASセキュリティ・インフラストラクチャを使用してアクセス制御を強制します。Oracle Access ManagerをWebSphere Portalと統合すると、次のOracle Access Manager機能がポータルで使用できます。

• ユーザーおよびグループの管理

• パスワード管理

• ポータルへのSSO

• Oracle Access Manager、WAS、WebSphere Portalの間の統一されたログアウト

WebSphere Portal V5では、次のコンポーネントを使用してユーザーとグループの情報を管理します。

Member Manager: Member Managerは、WebSphere Portalにインストールされているすべてのポートレットを含む、ユーザーとグループのJavaオブジェクト・ビューをWebSphere Portalに表示します。Member Manager（PUMAを介してアクセスされます）は、WebSphere Portal V5.0がユーザーとグループの情報へのアクセスに使用する抽象化インタフェースです。これには、ユーザーが存在することをポータルに通知するユーザー・アカウント、そのユーザーがメンバーとなるユーザー・グループ、およびユーザーに関する属性が含まれます。

次の図は、Member Managerのアーキテクチャを示しています。

ポータルおよび関連するコンポーネントの詳細は、WebSphere Portal V5のドキュメントを参照してください。

Oracle Access Managerカスタム・メンバー・リポジトリ: 「サポートされているバージョンとプラットフォーム」で説明されているように、カスタム・メンバー・リポジトリ（CMR）がWebSphere用コネクタで使用できます。CMRは、WebSphere Portal ServerをIDシステムのユーザーおよびグループに接続するMember Managerコンポーネントのインスタンスです。

CMRは、IBM WebSphere MemberRepositoryインタフェースを実装するカスタム・ユーザー・データ・ストアです。図10-4に示すように、CMRはユーザー・ベースの属性とグループ・ベースの属性をユーザー・データ・ストアに格納します。WebSphere Portal ServerはCMRを使用して、ユーザーのパーソナライズのためのgetAttributes、属性でユーザーを検索するgetGroupMembershipsなどの関数に似た問合せを作成します。ユーザー・プロファイル情報はPortalデータベース内にあり、認証情報は管理コンソールおよびLDAPを通じて入手できます。

図10-4 Member Manager、WebSphere Portalデータベース、およびCMR

注意: グループ・メンバーシップ機能は現在サポートされていません。そのため、内部グループ・メンバーシップをチェックする場合、親グループの詳細は表示されません。

CMRは読取り操作のみサポートします。作成操作、変更操作、削除操作はサポートしません。CMRはCustom User Registry（CUR）が拡張されたもので、Portal Serverを必要とします。

CMRに関連するWebSphere Portal Member Managerの制御に使用する構成ファイルは、後続の段落で説明します。通常これらのファイルはポータルのインストール時に作成されます。

wmm.xml: 最上位レベルのMember Manager構成。Member Managerが使用する様々なMemberRepository実装をリストして構成します。他のMember Manager構成ファイルの大部分はこのファイルから指定されます。CMRの詳細は、このファイルで構成する必要があります。

PumaService.properties: これは、WebSphere Portal V5.0.xでWebSphere PortalとMember Managerの間をマッピングするレイヤーである、PUMA APIの構成ファイルです。これはMember Manager構成ファイルではありません。しかし、PUMAはポータルのユーザー・スタックの一部であるため、この構成ファイルは重要です。

このファイルには、Member Managerリクエストおよび複数の値を持つプロパティに渡される属性名のカンマ区切りのリストが含まれています。このファイルは、ユーザー属性のパーソナライズのために構成する必要があります。すべてのuser.base.attributes値およびgroup.base.attributes値はCMRで検索できます。次に例を示します。

user.base.attributes=cn,uid,cn,logonId,logonPasswordVerify,logonPassword ...
 group.base.attributes=cn,uniqueOwnerIdentifier,membergroups,
 groupmembers,memberGroupName,memberGroupType,distinguishedName

他のすべての属性はPortalデータベースに移行されます。

起動時には、user.minimum.attributesパラメータに指定された属性のみが取り出されます。次に例を示します。

user.minimum.attributes=cn,genUserid,cn,givenName,sn,mail

注意: user.minimum.attributesリスト内のすべての属性は、「管理者」の「User Manager」および「Group Manager」に正しい属性アクセス制御が設定されていて、「User Manager構成」パネルのいずれかに存在する必要があります。たとえば、Portal ServerがgivenName属性を必要とする場合、IDシステムのパネルの1つに「名」が必要です。IDシステムでは、givenName属性が「表示名」、「名」にマッピングされます。

LDAPからOracle Access Managerへのマッピングを参照するには、「IDシステム・コンソール」、「User Manager構成」、「タブの構成」、「リンク」、「属性の変更」ページで、目的の属性を選択し、該当の表示名を表示します。

詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

wpconfig.properties: これはWebSphere Portal構成ファイルです。ポータルのユーザーおよびグループ管理者の詳細情報は、このファイルに設定する必要があります。このファイルはWPS_install_dir/configフォルダにあります。ここで、WPS_install_dirはPortal Serverのホーム・ディレクトリです。

VaultService.properties: このファイルは、WPS_install_dir /shared/app/config/servicesフォルダにあります。この構成ファイルは、ボールト・アダプタ実装の指定に使用されます。このファイルに正しいシステム管理者の資格証明DNを設定する必要があります。

10.9.1 CMRとの統合の概要

ログイン時にユーザーは、「シナリオ1: NetPointWASRegistryの使用」に示す手順で認証されます。

Oracle Access Manager CMRを使用しない場合、WebSphere Portal ServerはLDAPディレクトリ・サーバーと直接通信し、ユーザー、グループおよびパーソナライズの情報を取得する必要があります。CMRを使用する場合、WebSphere Portal Serverとディレクトリ・サーバーの間の通信をなくすことができます。CMRは、NetPointWASRegistry経由でディレクトリ・サーバーを使用して読取り操作を実行します。

図10-5は、ログイン認可プロセスでのWebSphere Portal Server、CMRおよびLDAPディレクトリ・サーバー間の相互作用を示しています。これは、「シナリオ1: NetPointWASRegistryの使用」に示すプロセスに従っています。

図10-5 WebSphere Portal Serverおよびカスタム・メンバー・リポジトリ

プロセスの概要: CMRを使用した認可

たとえば、Access Manager SDKはcheckPasswordメソッドを使用し、IdentityXMLは次に示す他のすべてのメソッドを使用します。

1. 認証の後、ユーザーはWebSphere Portal Serverを通してポートレットへのアクセスをリクエストします。

2. Portal Serverは、リクエストをCMRに転送します。

3. CMRはリクエストをNetPointWASRegistryに転送します。

4. NetPointWASRegistryは、IdentityXML呼び出しをIdentity Serverに送信するか、Access Manager SDKを使用し要求されるメソッドに応じてWebPassまたはWebGate経由でAccess Serverに接続します。

   • findByAttribute（ユーザーを属性で検索するため）

   • getMember

   • getGroupMemberIdentifiers

   • getMembers

   • searchなど

5. Identity Server（またはAccess Server）がLDAPディレクトリ・サーバーと通信します。

6. ディレクトリ・サーバーが情報を返します。

10.9.2 Oracle Access ManagerのWebSphere Portal V5.0.2の設定

WebSphere Portal V5とOracle Access Managerの統合は、インストールと構成の一連のタスクの中で行います。

WebSphere PortalとOracle Access Managerを統合する手順

1. 「コネクタのインストール準備」に示すタスクを実行します。

   1. 次の問題を訂正するために、WebSphereドキュメントに記載された適切なフィックス・パックを使用してWebSphere Application Serverをインストールします。

      例:

      問題: ユーザーDNで、次のようにカンマの後に中間の空白を含む場合、ポートレットへのアクセス許可が動作しません。

      Cn=PortalUser, o=company, c=us

      IBM社はこのポータル・ユーザーのアクセス許可の問題に対してFix PQ93461をリリースしました。

      アクション: このフィックス・パックを適用する必要があります。Portal Serverの履歴ログを確認し、必要なフィックスがすべてインストール済であることを確認します。詳細は、Portal InfoCenterドキュメントを参照してください。

   2. WebSphere Application Serverセキュリティを無効にしてWebSphere Portalをインストールします。

      
      

      注意: Portal Serverのインストール中は、グローバル・セキュリティとJava 2セキュリティの両方を無効にする必要があります。

      
      

      詳細は、IBM WebSphere Portal InfoCenterドキュメントを参照してください。

   3. 「コネクタのインストール準備」に示す手順でOracle Access Managerをインストールして構成します。

2. 「WebSphere用コネクタのインストール」に示す手順で、WebSphere用コネクタをインストールし、NetpointWASRegistryおよびTAIコンポーネントを構成します。

3. 「コネクタの設定の完了」に示す手順でコネクタの設定とテストを実施します。

4. WebSphere管理コンソールでセキュリティをカスタム・レジストリに変更します。

   これは、WASとOracle Access Managerの間の接続を確立するNetPointWASRegistryを規定します。WASはNetPointWASRegistryを使用して、アクセス・システムのセキュリティ・ポリシーでポータル・ユーザーを認証して許可します。

5. 次のシステム管理者の資格証明がNetPointWASRegistry.propertiesファイルにクリアテキストで設定されていることを確認します。

   OB_AdminUserName=admin OB_AdminUserCreds=password

   ここで、OB_AdminUserNameの値は、マスター管理者またはマスターID管理者であるPortal Server管理者のユーザーIDです。

   これはCMRに必須です。システム管理者の資格証明はクリアテキストで設定する必要があります。NetPointWASRegistryはパスワードを読み取って暗号化し、暗号化されたパスワードでpropertiesファイルにリライトします。暗号化機能はregistryTesterプログラムの実行により、WebSphereからと同様に実行できます。これらのパラメータの追加には、NetPointWASRegistryProperties.sampleファイルに含まれるコメントを参照してください。「NetPointWASRegistry.properties」も参照してください。

   
   

   注意: WebSphere用コネクタが暗号化パスワードでファイルをリライトする際に、NetPointWASRegistry.propertiesの形式は失われます。必要に応じてNetPointWASRegistry.propertiesのコピーを保存します。

   
   

6. WAS Serverを再起動します。

7. WebSphere Application ServerとPortal Serverが停止していることを確認します。

8. 次のファイルのバックアップ・コピーを作成します。

   WPS_install_dir/config/wpconfig.properties file
   
   

   ここで、WPS_install_dirはWebSphere Portal Serverのインストール先ディレクトリです。

9. wpconfig.propertiesファイルを編集し、次を追加します。

   PortalAdminId (Example: PortalAdminId=DN of wpsadministrator)
   PortalAdminIdShort (Example: PortalAdminIdShort=wpsadministrator)
   PortalAdminPwd (Example: PortalAdminPwd=wpsadminpassword)
   WasUserid (Example: WasUserid=wasadministrator)
   WasPassword (Example: WasPassword=wasadminpassword)
   PortalAdminGroupId (Example: PortalAdminGroupId=DN of PortalAdminGroupId)
   PortalAdminGroupIdShort (Example: PortalAdminGroupIdShort=PortalAdminGroupId)
   
   

10. WebSphere Application Serverを再起動します。

11. オプション: PortalでPUMAトレースをオンにします。これには、log.propertiesファイルに次を入力します。

    例:

    WPS_install_dir\shared\app\config\log.properties
    
    

    traceString=com.ibm.wps.services.puma.*=all=enabled:com.ibm.wps.puma.*=all=enabled:com.ibm.wps.command.puma.*=all=enable

12. 次のファイルをバックアップします。

    WPS_install_dir/shared/app/wmm/wmm.xmlファイル

13. CMR構成を変更するファイルを次のように編集します（lookasideフラグをfalseに設定する必要があります）。

    customRepositoryAttributes.xmlという名前のファイルはダミー・ファイルであり、WebSphereまたはOracle Access Managerの構成の一部ではありません。

    <supportedMemberTypes>
    
    <supportedMemberType name="Person"
     rdnAttrTypes="uid"
     defaultParentMember="o=company,c=us"
     defaultProfileRepository="CNR"/>
     <!-- o=company,c=us is Root DN. please enter the DN in your environment. -->
    
     <supportedMemberType name="Group"
     rdnAttrTypes="cn"
     defaultParentMember="o=company,c=us"
     defaultProfileRepository="CNR"/>
     <!-- Name of the CMR information tag -->
     </supportedMemberTypes>
    
     <profileRepository name="NetpointCustomRepository" UUID="CNR"
     description="This is Oracle WMM custom MemberRepository implementation."
     vendor="Oracle"
     adapterClassName="com.oblix.registry.NetPointMemberRepositoryImpl_v5"
     specVersion="1.0" adapterVersion="2.0"
     configurationFile="customRepositoryAttributes.xml"
     wmmGenerateExtId="false" supportGetPersonByAccountName="false"
     supportDynamicAttributes="false" profileRepositoryForGroups="CNR"
     enableTrace="true " PumaService.properties="WPSInstallDir/shared/app/config/services/PumaService.properties"
    NetPointWASRegistry.properties="NetpointWASConnInstallDir\oblix\config\NetPointWASRegistry.properties">
    
    <!-- 1. com.oblix.registry.NetPointMemberRepositoryImpl_v5 is name of the CMR implementtion class
    2. Mention path of the PUMA service against PumaService.properties paramter.
    3. NetPointWASRegistry.properties - Path of the Oracle Access Manager WAS registry configuration file.
    For Unix this path should be mentioned as "NetpointWASConnInstallDir/oblix/config/NetPointWASRegistry.properties
    4. CustomRepositoryAttributes.xml is a dummy file.
     -->
    
     <readMemberType>
    
     <memberType name="Person" /> <memberType name="Group" />
     <!-- Only read access to portal is provided by COREid Connector CMR-->
     </readMemberType>
     <createMemberType>
     <!-- <memberType name="Person" /> <memberType name="Group" /> -->
     <!-- Commented out - can't create in the sample -->
     </createMemberType>
    <updateMemberType>
     <!-- <memberType name="Person" /> <memberType name="Group" / > -->
     <!-- Commented out - can't update in the sample -->
     </updateMemberType>
     <deleteMemberType>
     <!-- <memberType name="Person" /> <memberType name="Group" /> -->
     <!-- Commented out - can't delete in the sample -->
     </deleteMemberType>
     <renameMemberType>
     <!-- <memberType name="Person" /> <memberType name="Group" /> -->
     <!-- Commented out - can't rename in the sample -->
     </renameMemberType>
     <moveMemberType>
     <!-- <memberType name="Person" /> <memberType name="Group" /> -->
     <!-- Commented out - can't move in the sample -->
     </moveMemberType>
     <nodeMaps>
     <nodeMap node="o=company,c=us" pluginNode="o=company,c=us" />
     <!-- Root DN configured in your environment -->
     </nodeMaps>
     </profileRepository>
    
    

14. PumaService.propertiesファイルで、次のフィルタがご使用の環境で正しいことを確認し、必要に応じて値を編集します。

    例:

    WPS_install_dir\shared\app\config\services\PumaService.properties
    user.base.attributes=cn,uid,cn,logonId,logonPasswordVerify,logonPassword ...
    group.base.attributes=cn,uniqueOwnerIdentifier,membergroups,groupmembers,memberGroupName,memberGroupType,distinguishedName...
    
    

    CMRがOracle Access Managerのバックエンド・アプリケーションから取り出すユーザーのすべての属性を、user.minimum.attributesの値が含んでいることを確認して、WAS Portal Serverに送信します。次に例を示します。

    user.minimum.attributes=cn,genUserid,cn,givenName,sn,mail...
    
    

    グループ・メンバーを取り出すuniquemember属性を必ず指定します。

    group.minimum.attributes=cn,uniquemember...
    
    

15. 『Oracle Access Manager IDおよび共通管理ガイド』に示すように、PumaService.propertiesファイルですべてのuser.minimum.attributesが管理者の正しい属性アクセス制御を持ち、IDシステムのパネルのいずれかに存在することを確認します。

    「IDシステム・コンソール」メニューから「User Manager構成」をクリックし、「タブの構成」、タブ・リンク、「オブジェクト・プロファイルの表示」、「パネルの構成」をクリックします。

16. 次のコマンドを実行してWebSphere Portalセキュリティを構成します。

    WPSConfigの一部の手順では、この手順の前に変更したファイルをすべて上書きするものがあるため、すべてのファイルをバックアップする必要があります。

    WPS_install_dir/config/WPSConfig.bat action-secure-portal-ldap
    
    

17. WebSphere Portal Serverを停止します。

18. WPSConfig.batを実行する前に行った構成ファイルの変更がすべて適切な状態であることを確認します。

19. WebSphere Portal Serverを再起動します。

20. 次のファイルでsystemcred.dnが有効であることを確認します。

    WPS_install_dir\shared\app\config\services\VaultService.properties file
    
    

    例:

    systemcred.dn=cn=PortalAdmin,o=company,c=us
    
    

    
    

    注意: これは、常に完全修飾されたwpsadminのunquietです。

    
    

21. 次のコマンドを実行してWebSphere Portal資格証明を構成します。

22. 次にアクセスします。http://host:port/wps/portal

    WPS_install_dir/config/WPSConfig.bat action-create-deployment-credentials

    ここで、hostは完全修飾されたサーバー名で、portはPortal Serverに構成されたポート番号です。

23. Oracle Access ManagerのAdminユーザーとしてPortalにログインします。

    正常にログインすると、AdminユーザーはOracle Access Managerリポジトリでユーザーとグループを検索できます。

10.9.3 Oracle Access ManagerでのWebSphere Portal V5.1の設定

WebSphere Portal V5.1とOracle Access Managerの統合は、インストールと構成の一連のタスクの中で行います。

WebSphere PortalとOracle Access Managerを統合する手順

1. 「コネクタのインストール準備」に示すタスクを実行します。

   1. 次の問題を訂正するために、WebSphereドキュメントに記載された適切なフィックス・パックを使用してWebSphere Application Serverをインストールします。

      例:

      問題: アクセス許可が、次のようにカンマセパレータの後に中間の空白を含むユーザーDNで動作しません。cn=PortalUser, o=company, c=us

      このポータル・ユーザーのアクセス許可の問題の詳細は、IBM社のFix PQ93461を調べてください。

      アクション: このIBM社のフィックス・パックを適用する必要があります。Portal Serverの履歴ログを確認し、必要なフィックスがすべてインストール済であることを確認します。詳細は、Portal InfoCenterドキュメントを参照してください。

   2. WebSphere Application Serverセキュリティを無効にしてWebSphere Portalをインストールします。

      
      

      注意: Portal Serverのインストール中は、グローバル・セキュリティとJava 2セキュリティの両方を無効にする必要があります。

      
      

      インストールの詳細は、IBM WebSphere Portal InfoCenterドキュメントを参照してください。

   3. フィックスのPQ99439およびPK02868_510を適用します。これはWebSphere Portal 5.1のカスタム・ユーザー・レジストリの構成に必要です。（これらのフィックスを適用しないと、タスクenable-security-wmmur-customは失敗します。）

   4. 入手可能な最新のMember Manager cumulative fix for WebSphere Portal version 5.1を適用します。これにはグループ・メンバーシップ機能のフィックスが含まれています。この累積フィックスは次のWebサイトにあります。

      http://www-1.ibm.com/support/docview.wss?rs=0&uid=swg24009153

   5. 「コネクタのインストール準備」に示す手順でOracle Access Managerをインストールして構成します。

2. 「WebSphere用コネクタのインストール」に示す手順で、WebSphere用コネクタをインストールし、NetpointWASRegistryおよびTAIコンポーネントを構成します。

3. 「コネクタの設定の完了」に示す手順でコネクタの設定とテストを実施します。

4. WebSphere管理コンソールでセキュリティをカスタム・レジストリに変更します。これは、WASとOracle Access Managerの間の接続を確立するNetPointWASRegistryを規定します。WASはNetPointWASRegistryを使用して、アクセス・システムのセキュリティ・ポリシーでポータル・ユーザーを認証して許可します。

5. 次のシステム管理者の資格証明がNetPointWASRegistry.propertiesファイルにクリアテキストで設定されていることを確認します。

   OB_AdminUserName=admin
   OB_AdminUserCreds=password
   
   

   ここで、OB_AdminUserNameの値は、マスターID管理者またはOracle Access Manager管理者であるPortal Server管理者のユーザーIDです。これはCMRに必須です。システム管理者の資格証明はクリアテキストで設定する必要があります。NetPointWASRegistryはパスワードを読み取って暗号化し、暗号化されたパスワードでpropertiesファイルにリライトします。暗号化機能はregistryTesterプログラムの実行により、WebSphereからと同様に実行できます。これらのパラメータの追加には、NetPointWASRegistryProperties.sampleファイルに含まれるコメントを参照してください。詳細は、「NetPointWASRegistry.properties」を参照してください。

   
   

   注意: WebSphere用コネクタが暗号化パスワードでファイルをリライトする際に、NetPointWASRegistry.propertiesファイルの形式は失われます。したがって、必要に応じてNetPointWASRegistry.propertiesのコピーを保存します。

   
   

6. WAS Serverを再起動します。

7. WebSphere Application ServerとPortal Serverが停止していることを確認します。

8. 次のファイルのバックアップ・コピーを作成します。

   WPS_install_dir/config/wpconfig.properties
   
   

   ここで、WPS_install_dirはWebSphere Portal Serverのインストール先ディレクトリです。

9. wpconfig.propertiesファイルを編集し、次を追加します。

   PortalAdminId (Example: PortalAdminId= DN of wpsadministrator)
   PortalAdminIdShort (Example: PortalAdminId= wpsadministrator)
   PortalAdminPwd (Example: PortalAdminPwd=wpsadminpassword)
   WasUserid (Example: WasUserid=wasadministrator)
   WasPassword (Example: WasPassword=wasadminpassword)
   PortalAdminGroupId (Example: PortalAdminGroupId= DN of PortalAdminGroupId)
   PortalAdminGroupIdShort (Example: PortalAdminGroupIdShort= PortalAdminGroupId)
   LTPAPassword (Example: LTPAPassword= Password configured for LTPA in the AppServer Configuration)
   WmmSystemId (Example: WmmSystemId= Set this value to same as that of PortalAdminIdShort)
   WmmSystemIdPassword (Example: WmmSystemIdPassword= Set this value to same as that of PortalAdminPwd)
   LDAPSuffix (Example: LDAPSuffix=o=company,c=us LDAP suffix of Oracle Access Manager installation)
   LDAPUserSuffix (Example: LDAPUserSuffix=ou=users Keep this blank if user-nodes are directly under LDAPSuffix)
   LDAPGroupSuffix (Example: LDAPGroupSuffix=ou=groups Keep this blank if group-nodes are directly under LDAPSuffix)
   LdapUserPrefix (Example: LdapUserPrefix=cn)
   LdapGroupPrefix (Example: LdapGroupPrefix=cn)
   
   

   PortalAdminId (Example: PortalAdminId= DN of wpsadministrator )
   PortalAdminIdShort (Example: PortalAdminId= wpsadministrator )
   PortalAdminPwd (Example: PortalAdminPwd=wpsadminpassword )
   WasUserid (Example: WasUserid=wasadministrator )
   WasPassword (Example: WasPassword=wasadminpassword )
   PortalAdminGroupId (Example: PortalAdminGroupId= DN of PortalAdminGroupId )
   PortalAdminGroupIdShort (Example: PortalAdminGroupIdShort= PortalAdminGroupId )
   LTPAPassword (Example: LTPAPassword= Password configured for LTPA in the AppServer Configuration)
   WmmSystemId (Example: WmmSystemId= Set this value to same as that of PortalAdminIdShort)
   WmmSystemIdPassword (Example: WmmSystemIdPassword= Set this value to same as that of PortalAdminPwd)
   LDAPSuffix (Example: LDAPSuffix=o=company,c=us LDAP suffix of Oracle Access Manager installation)
   LDAPUserSuffix (Example: LDAPUserSuffix=ou=users Keep this blank if user-nodes are directly under LDAPSuffix)
   LDAPGroupSuffix (Example: LDAPGroupSuffix=ou=groups Keep this blank if group-nodes are directly under LDAPSuffix)
   LdapUserPrefix (Example: LdapUserPrefix=cn )
   LdapGroupPrefix (Example: LdapGroupPrefix=cn )
   PortalAdminId (Example: PortalAdminId= DN of wpsadministrator )
   PortalAdminIdShort (Example: PortalAdminId= wpsadministrator )
   PortalAdminPwd (Example: PortalAdminPwd=wpsadminpassword )
   WasUserid (Example: WasUserid=wasadministrator )
   WasPassword (Example: WasPassword=wasadminpassword )
   PortalAdminGroupId (Example: PortalAdminGroupId= DN of PortalAdminGroupId )
   PortalAdminGroupIdShort (Example: PortalAdminGroupIdShort= PortalAdminGroupId )
   LTPAPassword (Example: LTPAPassword= Password configured for LTPA in the AppServer Configuration)
   WmmSystemId (Example: WmmSystemId= Set this value to same as that of PortalAdminIdShort)
   WmmSystemIdPassword (Example: WmmSystemIdPassword= Set this value to same as that of PortalAdminPwd)
   LDAPSuffix (Example: LDAPSuffix=o=company,c=us LDAP suffix of Oracle Access Manager installation)
   LDAPUserSuffix (Example: LDAPUserSuffix=ou=users Keep this blank if user-nodes are directly under LDAPSuffix)
   LDAPGroupSuffix (Example: LDAPGroupSuffix=ou=groups Keep this blank if group-nodes are directly under LDAPSuffix)
   LdapUserPrefix (Example: LdapUserPrefix=cn )
   LdapGroupPrefix (Example: LdapGroupPrefix=cn )
   
   

10. WebSphere Application Serverを再起動します。

11. オプション: PortalでPUMAトレースをオンにします。これには、通常次の場所にあるlog.propertiesファイルに次を入力します。

    WPS_install_dir\shared\app\config\log.properties

    traceString=com.ibm.wps.services.puma.*=all=enabled:com.ibm.wps.puma.*=all=enabled:com.ibm.wps.command.puma.*=all=enable

12. 次のファイルをバックアップします。

    WPS_install_dir/wmm/wmm.xml

    WPS_install_dir/wmm/wmm_DB.xml

13. wmm.xmlのコピーを作成し、wmm.xmlと同じフォルダにwmm_custom.xmlの名前で保存します（WPS_install_dir/wmm/wmm_custom.xml）。

    wmm_custom.xmlを編集してCMR構成を次のように変更し、lookasideフラグがfalseに設定されていることを確認します。

    <supportedMemberTypes>
    
    <supportedMemberType name="Person"
     rdnAttrTypes="uid"
     defaultParentMember="o=company,c=us"
     defaultProfileRepository="CNR"/>
     <!-- o=company,c=us is Root DN. please enter the DN in your environment. -->
    
     <supportedMemberType name="Group"
     rdnAttrTypes="cn"
     defaultParentMember="o=company,c=us"
     defaultProfileRepository="CNR"/>
     <!-- Name of the CMR information tag -->
     </supportedMemberTypes>
    
     <profileRepository name="NetpointCustomRepository" UUID="CNR"
     description="This is Oracle WMM custom MemberRepository implementation."
     vendor="Oracle"
     adapterClassName="com.oblix.registry.NetPointMemberRepositoryImpl_v51"
     specVersion="1.0" adapterVersion="2.0"
     configurationFile="customRepositoryAttributes.xml"
     wmmGenerateExtId="false" supportGetPersonByAccountName="false"
     supportDynamicAttributes="false" profileRepositoryForGroups="CNR"
     enableTrace="true " PumaService.properties="WPSInstallDir/shared/app/config/services/PumaService.properties"
    NetPointWASRegistry.properties="NetpointWASConnInstallDir\oblix\config\NetPointWASRegistry.properties">
    
    <!-- 1. com.oblix.registry.NetPointMemberRepositoryImpl_v51 is name of the CMR implementation class
    2. Mention path of the PUMA service against PumaService.properties paramter.
    3. NetPointWASRegistry.properties - Path of the Oracle Access Manager WAS registry configuration file.
    For Unix this path should be mentioned as "NetpointWASConnInstallDir/oblix/config/NetPointWASRegistry.properties
    4. CustomRepositoryAttributes.xml is a dummy file.
     -->
    
     <readMemberType>
    
     <memberType name="Person" /> <memberType name="Group" />
     <!-- Only read access to portal is provided by COREid Connector CMR-->
     </readMemberType>
     <createMemberType>
     <!-- <memberType name="Person" /> <memberType name="Group" /> -->
     <!-- Commented out - can't create in the sample -->
     </createMemberType>
    <updateMemberType>
     <!-- <memberType name="Person" /> <memberType name="Group" / > -->
     <!-- Commented out - can't update in the sample -->
     </updateMemberType>
     <deleteMemberType>
     <!-- <memberType name="Person" /> <memberType name="Group" /> -->
     <!-- Commented out - can't delete in the sample -->
     </deleteMemberType>
     <renameMemberType>
     <!-- <memberType name="Person" /> <memberType name="Group" /> -->
     <!-- Commented out - can't rename in the sample -->
     </renameMemberType>
     <moveMemberType>
     <!-- <memberType name="Person" /> <memberType name="Group" /> -->
     <!-- Commented out - can't move in the sample -->
     </moveMemberType>
     <nodeMaps>
     <nodeMap node="o=company,c=us" pluginNode="o=company,c=us" />
     <!-- Root DN configured in your environment -->
     </nodeMaps>
     </profileRepository>
    
    

14. wmm_custom.xmlの新しい内容で次のファイルを上書きします。

    WPS_install_dir/wmm/wmm.xml

    WPS_install_dir/wmm/wmm_DB.xml

15. 次のファイルにあるフィルタがご使用の環境で正しいことを確認します。

    WPS_install_dir\shared\app\config\services\PumaService.properties

    このファイルでは、CMRがOracle Access Managerから取り出すユーザーのすべての属性を、user.minimum.attributesが含んでいることを確認して、WAS Portal Serverに送信します。user.base.attributes内の必要な属性のリストには、WAS Portal Serverで属性値を指定してユーザーを検索するために必要なすべての属性を入力します。group.minimum.attributesには、uniqueMemberと、Groupオブジェクト・クラスに構成されたクラス属性を割り当てます。（次のサンプル・ファイルでは、cnです。）user.password.attributeにはパスワード属性の名前を設定します。directoryがCUSTOMと設定されていることを確認します。必要に応じて、値を編集します。

    #SAMPLE PumaService.properties file. Please make changes according to your environment
    
    #In the following sample file. User object classAttribute is uid and Group object class attribute is cn.
    
    #Please set these values according to your environment.
    
    user.fbadefault.filter=uid
    user.template.attribute=uid
    user.password.attribute=userPassword
    user.minimum.attributes=uid,cn
    user.base.attributes=uid,cn,givenName,sn,preferredLanguage
    user.sync.remove.attributes=passwordCreation,RDN,lastSession,selfAddress,packageSuppression,
    createdTimestamp,policyAccountId,registrationUpdate,uniqueUserIdentifier,memberId,ancestors,
    addressId,truncatedUniqueIdentifier,profileType,registration,primary,approvalState,lastOrder,
    publishPhone2,publishPhone1,salt,addressBookId,uniqueParentIdentifier,parentMemberId,
    registrationCancel,passwordExpired,previousLastSession,displayName,addressType,shortName,
    preferredLanguageId,userId,timeout,registerType,uniqueIdentifier,passwordInvalid,nickName,type,
    membergroups,income,age,organizationUnitId,demographicField6,children,household,status,
    passwordRetries,uniqueNumericIdentifier,cn
    group.fbadefault.filter=cn
    group.template.attribute=cn
    group.minimum.attributes=cn,uniqueMember
    group.base.attributes=cn,uniqueMember
    group.sync.remove.attributes=uniqueOwnerIdentifier,membergroups,groupmembers,memberGroupName,
    memberGroupType,distinguishedName,cn,uniqueNumericIdentifier,uniqueMemberIdentifier
    directory=CUSTOM
    ejbName=ejb/MemberServiceHome
    
    

16. すべてのuser.minimum.attributesに管理者の正しい属性アクセス制御が設定されていることを確認します。

    詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

    また、『Oracle Access Manager IDおよび共通管理ガイド』に記載されているように、すべてのuser.minimum.attributesがIDシステムのパネルのいずれかにあることを確認します。

    これらのパネルにアクセスするには、IDシステム・コンソールから「User Manager構成」をクリックし、「タブ」、タブへのリンク、「オブジェクト・プロファイルの表示」をクリックしてから、「パネルの構成」をクリックします。

17. ファイルWPS_install_dir/wmm/wmmWASAdmin.xmlを次のように変更します。

    <?xml version="1.0" encoding="UTF-8"?>
    <wmmWASAdmins>
      <admin logonId="PortalAdmin" logonPassword="oblixoblix" uniqueUserId="cn=Portal Admin,o=company,c=us"/>
    </wmmWASAdmins>
    
    

    logonId、logonPasswordおよびuniqueUserIdは、wpconfig.propertiesのPortalAdminIdShort、PortalAdminIdおよびPortalAdminPwdの新しい値にそれぞれ対応します。

18. WPS_install_dir/wmm/wmmur.xmlファイルを変更します。

    次に示すようにwmmnodeの値を、使用するLDAPRootに設定します。

    <node wmmnode="o=company,c=us"/>

19. サポートされる属性のみを含むようにWPS_install_dir/wmm/wmmAttributes.xmlを変更します。

    wmmAttributes.xmlファイルには、サポートされるすべての属性の定義を含んでいます。各属性の定義には、applicableMemberTypesおよびrequiredMemberTypesという名前の2つのプロパティがあります。これらのプロパティの値はサポートされるメンバー・タイプである必要があります。たとえば、wmm_custom.xmlに2つのsupportedMemberTypes（PersonおよびGroup）のみが指定されている場合、organizationalUnitやorganizationなど他のタイプをwmmAttributes.xml内の任意の属性に対してapplicableMemberTypesまたはrequiredMemberTypesにすることはできません。

20. WPS_install_dir/shared/app/config/services/VaultService.propertiesを変更します。

    systemcred.dnの値をwpsadministratorのDNに設定します。

    例:

    systemcred.dn=cn=Portal Admin,o=company,c=us
    
    

21. すべての構成ファイルをバックアップしてからPortal Serverを停止し、次のコマンドを実行してWebSphere Portalセキュリティを構成します。

    WPS_install_dir/config/WPSConfig.bat enable-security-wmmur-custom

22. 構成ファイルがすべて適切な状態であることを確認します。

    前の手順で作成したバックアップ・コピーと値を比較できます。

    wmm.xmlの内容は、wmm_custom.xmlの内容と一致する必要があります。

23. Portal Serverを再起動します。

24. 次のWebページにアクセスします。

    http://host:port/wps/portal

    ここで、hostは完全修飾されたサーバー名で、portはPortal Serverに構成されたポート番号です。

25. Oracle Access ManagerのAdminユーザーとしてPortalにログインします。正常にログインすると、Adminユーザーは他のOracle Access Managerリポジトリでユーザーおよびグループを検索できます。

10.9.4 Portal V5でのユーザーおよびグループの管理

ポータル管理者はIDシステムを使用して、ユーザーおよびグループの追加や削除、ユーザー・プロファイルと属性の変更など、ユーザーおよびグループの管理タスクを実行します。

IDシステムのユーザーおよびグループ管理機能を使用するために、WebSphere Portalでユーザーおよびグループを作成しないでください。かわりにIDシステムでユーザーおよびグループを作成し、変更します。

IDシステムから静的グループとグループ内のユーザー・メンバーシップを追加したり、削除したりできます。IDシステム内で更新する情報はWebSphere Portalに即座に反映されます。

注意: グループ・メンバーシップを認識するために、IDシステムでは拡張可能な動的グループが必要です。

ユーザーとグループは、IDシステムで作成した後、WebSphere Portalで検索できます。

ユーザーとグループの管理の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

10.9.5 ユーザー・プロファイルと属性の変更

ユーザーがIDシステムからプロファイルを変更すると、その変更は即座にWebSphere Portalに表示されます。これにより、ポータル開発者がユーザー・ページをパーソナライズする際に最新のユーザー情報を確実に使用できます。

必要に応じて追加の属性をユーザーのプロファイルにマッピングできます。属性のマッピングの詳細は、WebSphere Portalのドキュメントを参照してください。

10.9.6 Portal V5でのパスワード管理

ポータルはアクセス・システムのSSOを使用するため、ユーザーは認証時にOracle Access Managerパスワード・ポリシーの対象となります。

重要: パスワード管理機能を実装するには、ポータルのパスワード管理機能をオフにします。

Oracle Access Managerのパスワード管理機能には、パスワード・ポリシーの定義、パスワードのリセット、有効期限切れの通知およびロスト・パスワードのチャレンジ・フレーズなどがあります。

パスワード・ポリシーの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

10.9.7 WebSphere Portal V5のアクセス制御

ポータル管理者はポータルのアクセス制御機能を使用して、ポートレットへのアクセスを許可します。WebSphere Portalから、管理者は、ポータル管理権限とポートレットアクセス制御を許可するOracle Access Manager管理対象のユーザーとグループを検索します。

10.9.8 Portal V5のシングル・サインオン機能の構成

アクセス・システムとWebSphere Portal間のSSOを構成すると、WebSphere PortalはObSSOCookieを利用でき、WebSphere用コネクタはOracle Access Managerユーザーを認証できます。

WebSphere Portal ServerのSSOログアウトを構成すると、ユーザーがアクセス・システム保護対象のWebSphereリソースからログアウトしたときに、LTPAトークンとObSSOCookieの両方が確実に中断されます。ユーザーは、再度認証しないで他のWebSphereリソースや他のアクセス・システム保護対象のリソースにアクセスすることはできません。

• Oracle Access ManagerとWebSphere間のシングル・サインオン用のTAIを構成した場合、WebSphere Portal Serverからのシングル・サインオン・ログアウトを構成する必要があります。

• シングル・サインオンのTAIを構成していない場合、ユーザーはポータルのログアウト・ボタンを使用してアクセス・システム保護対象のリソースのすべてからログアウトできます。

WebSphere Portal V5のシングル・サインオンを構成する手順

1. WebSphere Portalのインストール時に選択したWebサーバーのWebGateプラグインをインストールします。

2. Policy Managerで、保護するURLを定義します。

ユーザーがこのURLにログインしようとすると、WebGateから認証を求められます。ユーザーがWebSphere PortalのrootにアクセスするときにWebGateから認証を求める場合は/を保護します。必要に応じて他の認可ルールを追加できます。

注意: リソースを保護するには、フォーム・ベースの認証スキームを使用することをお薦めします。ただし、Basic認証スキームを使用する場合、確実にObSSOCookieが設定されるように、「チャレンジ・リダイレクト」フィールドを別のWebGateに設定します。認証スキームの詳細は、『Oracle Access Managerアクセス管理ガイド』を参照してください。

シングル・サインオン・ログアウトの構成手順

1. 『Oracle Access Managerアクセス管理ガイド』に記載されているようにして、ポータルURLを保護するためにLDAPを使用するフォーム・タイプの認証スキームでアクセス・システム・ポリシーを作成します。

2. HTML、JSPまたはCGIプロトコルでカスタム・ログアウト・ページを作成します。

   Oracle Access Managerデフォルト・ログアウト・ページlogout.htmlは次の場所にあります。

   WebGate_install_dir\access\oblix\apps\common\bin

   ここで、 WebGate_install_dirはWebGateのインストール先ディレクトリです。

3. WebSphereを保護するWebGateがインストールされているWebサーバーのドキュメント・ルートにログアウト・ページを保存します。

   例:

   http://foobar/myportal/logout.html

   
   

   注意: ログアウト・ページの名前には文字列logoutを含めます。

   
   

4. 『Oracle Access Managerアクセス管理ガイド』に記載されているように、ログアウト・ページをアクセス・システム・ポリシーで保護します。

5. 次のファイルを見つけて開きます。

   WPS_install_dir\shared\app\config\services\ConfigServices.properties

   ここで、WPS_install_dirはWebSphere Portal Serverのインストール先ディレクトリです。

6. 次の2つのパラメータをConfigServices.propertiesファイルに追加します。

   redirect.logout = true

   redirect.logout.url = ログアウト・ページへのパス

   例:

   • http://foobar/myportal/logout.html

7. WebSphere Portal ServerおよびApplication Serverを再起動します。

10.10 WebSphere Application Server V6の構成

次の項に、Oracle Access ManagerとWebSphere Application Server V6を統合する方法を示します。

• WAS V6のNetPointWASRegistryの有効化

• WebSphere V6のNetPointWASRegistryのテスト

• WebSphere V6のTAIの構成

• WAS V6のTAIのテスト

• WAS V6のTAIのログの有効化

この統合用にサポートされているバージョンとプラットフォームを確認するには、次に示すMetalinkを参照してください。

Metalinkの情報を表示する手順

1. 次のURLに移動します。

   http://metalink.oracle.com

2. 「Certify」タブをクリックします。

3. 「View Certifications by Product」をクリックします。

4. 「Application Server」オプションを選択して「Submit」をクリックします。

5. 「Oracle Application Server」を選択して「Submit」をクリックします。

10.10.1 WAS V6のNetPointWASRegistryの有効化

WAS V6とWebSphere用コネクタをインストールし、これらが通信できることをテストで確認した後、WebSphere 6のユーザー・レジストリと連携するNetPointWASRegistryを有効化できます。これにより、WebSphere Application Serverの認証ソースとしてOracle Access Managerが機能するようになります。

注意: 次の手順では、Adminのロールに付加された任意のOracle Access Managerユーザーは、Admin（Administrator）というグループに属する必要があります。そうでないと、このユーザーはWebSphere管理コンソールにログインできない可能性があります。monitorなど、他のロールには制約はありません。したがって、WAS 6の管理コンソールでこのロールに付加された任意のOracle Access Managerユーザーは、WAS 6の管理コンソールにログインできます。

WAS 6でNetPointWASRegistryを有効化する手順

1. WebPassを保護するWebGateで「IPValidation」が「オフ」に設定されていることを確認します。

   アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、左側のナビゲーション・ペインの「AccessGate構成」をクリックし、WebPassを保護するWebGateのリンクをクリックして、「IPValidation」フィールドで「オフ」オプションを選択します。

2. 次のディレクトリにあるsecurity.xmlファイルのバックアップ・コピーを作成します。

   WPS_install_dir/profiles/default/config/cells/serverNodeName

   構成を変更するときは常にsecurity.xmlのバックアップ・コピーを作成します。新しい構成でエラーが発生した場合は、バックアップからリストアできます。

3. WebSphere管理サービスを開始します。

4. WebSphere管理コンソールにID管理者としてログインします。

   WAS 6の管理コンソールは次のURLからアクセスできます。

   http://hostname.domain.com:9060/ibm/console

   ここで、hostnameはWebSphereがインストールされているマシンの完全修飾名です（たとえば、xyz.domain.com）。

5. 「Security」「Global Security」および「Custom」に移動し、次の変数に値を入力します。

   • サーバー・ユーザーのID

   • サーバー・ユーザーのパスワード

   • カスタム・レジストリ・クラス名

   • Oracle Access Managerの管理者ID

   • ユーザーのパスワード

   • Oracle Access Managerクラス名: com.oblix.registry.NetPointWASRegistry

6. 「Configuration」、「Additional Properties」、「Custom Properties」、「New」に移動します。

   次のパラメータに値を入力します。

   • Name: NetPointWASRegistry.properties

   • Value: /opt/netpoint/oblix/config/NetPointWASRegistry.properties

   • Description: ユーザー・レジストリのプロパティ・ファイル

7. 「Apply」をクリックします。

8. 「Global Security」、「Authentication Mechanisms」、「LTPA」に移動します。

9. 「Configuration」タブでパスワードを指定し、「OK」をクリックします。

10. 「Single Signon (SSO)」をクリックします。

    • 「Enabled」ボックスをクリックします。

    • ドメイン名（たとえば、oracle.com）を入力し、「Apply」をクリックします。

11. 左側のナビゲーション・ペインで、「Security」をクリックし、「Global Security」をクリックし、次の手順を実施します。

    1. 「Active Authentication Mechanism」を「LTPA」に設定します。

    2. 「Active User Registry」を「Custom User Registry」に設定し、「OK」をクリックします。

    3. 「Enable Global Security」ボックスをクリックします。

    4. 構成をテストするには「Apply」をクリックします。

       情報が有効な場合、変更を確認するメッセージが上部に表示されます。有効でない場合、報告されたエラーを修正します。

    5. 「Save」をクリックします。

    6. 「Logout」をクリックし、ブラウザ・ウィンドウを閉じます。

    7. WebSphere Application Serviceを停止します。サービスを停止できなかったというメッセージを受け取ったら、タスク・マネージャに切り替え、現在実行中のJavaプロセスがないことを確認します。

12. WebSphere管理サービスを開始します。

10.10.2 WebSphere V6のNetPointWASRegistryのテスト

NetPointWASRegistryを有効にした後、正しく構成されたことを確認する必要があります。

NetPointWASRegistry構成をテストする手順

1. 次のURLでデフォルト・サーバー上で稼働するSnoopサーブレットのサンプルにアクセスします。

   http://hostname:9080/snoop

   ここで、hostnameはWebSphereがインストールされているマシンの完全修飾名です。

   あるいは、次のURLを使用できます。

   http://hostname:web_server_plug-in_port/snoop

   ここで、hostnameはWebSphereがインストールされているマシンの完全修飾ドメイン名です。

2. WebSphereによってチャレンジ方式の認証を求められたら、Oracle Access Managerで有効なユーザー名とパスワードを入力します。

   デフォルトで、任意の認証ユーザーにアクセスが許可されます。

3. WebSphere管理コンソールを起動し、「Security」、「Global security」、「Custom」で指定されたユーザーとしてログインします。

   構成が有効な場合、正常にログインできます。

4. ユーザーおよびグループと所属するロールを指定して、WebSphere管理コンソールのアクセス制御を設定します。

   詳細は、WebSphere 6のドキュメントを参照してください。

5. 管理コンソールのアクセスをサポートするために変更した.xmlファイルの名前を書き留め、「Save」をクリックします。

WebSphere用コネクタをインストールした後、NetPointWASRegistryおよびTAIを構成する必要があります。NetPointWASRegistryは認証を処理し、TAIはアクセス・システムのシングル・サインオンを支援します。

10.10.3 WebSphere V6のTAIの構成

Oracle Access ManagerとWASの間のシングル・サインオンを有効にするようTAIを構成します。WebSphere 6.0では、webgate.propertiesをインストールし、TAIを追加し、custom.propertiesを追加する必要があります。

WAS 6のTAIをインストールして構成する手順

1. 構成ファイルwebgate.propertiesをコピーします。コピー元は次のディレクトリです。

   CWS_install_dir/oblix/config

   ここで、CWS_install_dirはWebSphere用コネクタがインストールされているディレクトリです。コピー先のWebSphereインストール・プロパティ・ディレクトリは次の場所にあります。

   WAS_install_dir/properties

   ここで、WAS_install_dirはWebSphere Application Serverのインストール先ディレクトリです。

   Webgate.propertiesには、WebSphereがAccessGateへの接続に使用する構成情報が含まれています。

2. WebSphereインストール・プロパティ・ディレクトリで、webgate.propertiesファイルのパラメータ値を次のように変更します。

   OB_InstallDir = CWS_install_dir

   ここで、CWS_install_dirはWebSphere用コネクタのインストール先ディレクトリです。

   フロント・エンド・サーバーとして使用されるプロキシ・サーバー上に関連のWebGateがインストールされていて、WebSphere Application ServerとのインタフェースとなるWebサーバーにすべてのユーザー・リクエストを振り向けている場合、次のパラメータ値を指定します。

   • OB_IsProxyEnabled=true

   • OB_hostnames = serverName

     ここで、serverNameはプロキシ・サーバーの名前です。

   • OB_ports = portNumber

     ここで、portNumberはプロキシ・サーバーのポート番号です。

     
     

     注意: Authen以外のリソースを使用する場合、webgate.propertiesファイルにリソース名を指定する必要があります。

     
     

3. WebSphere管理コンソールを起動します。

4. 左側のナビゲーション・ペインで、「Global security」、「Select Authentication Mechanisms」、「LTPA」、「Trust Association,」、「Additional Properties」、「Interceptors」、「New」に移動します。

5. 「Name」フィールドにOblix TAI Interceptorと入力します。

6. 「Interceptor classname」フィールドにcom.oblix.tai.was5.WebGateTrustAssociationInterceptorと入力し、「OK」をクリックします。

7. 次の変更を行います。

   1. Name: com.ibm.websphere.security.trustassociation.types

      • Value: webgate

      • Description: TAIプロパティ

      「Required」チェック・ボックスを選択し、「OK」をクリックします。

   2. Name: com.ibm.websphere.security.trustassociation. webgate.config

      • Value: webgate

      • Description: WAS_install_dir/propertiesディレクトリ内にあるTAIプロパティ・ファイルの名前。

      「Required」チェック・ボックスを選択し、「OK」をクリックします。

   3. Name: com.ibm.websphere.security.trustassociation. webgate.interceptor

      • Value: com.oblix.tai.was5.WebGateTrustAssociationInterceptor

      • Description: WebSphere 6のTAIクラス

      「Required」チェック・ボックスを選択し、「OK」をクリックします。

8. ページの上部にある「Interceptors」をクリックし、「Save」をクリックします。

9. 次の場所に移動します。

   WAS_install_dir/profiles/default/config/cells/serverNodeName

10. security.xmlファイルのバックアップ・コピーを作成します。

11. WebSphere管理コンソールで、「LTPA」、「Trust Association」、「Interceptors」に移動します。

12. 「WebSeal Interceptor」を選択し、「Delete」をクリックします。

13. 「Trust Association」をクリックし、「Enable Trust Association」チェック・ボックスをクリックします。

14. 「Apply」をクリックし、「Save」をクリックします。

15. WebSphere管理コンソールからログアウトし、ブラウザを閉じます。

16. Websphere Admin Serverを停止します。

    エラー・メッセージが表示される場合は、タスク・マネージャを参照し、Javaプロセスが稼働していないことを確認します。

17. WebSphere管理サービスを再度開始します。

    サービスが開始されない場合は、security.xmlファイルでプロパティが正しく設定されていることと、webgate.propertiesファイルが正しい場所にあることを確認します。

18. 「WAS 5のTAIをインストールして構成する手順」に示す手順でリソースを保護するアクセス・システム・ポリシーを作成します。

    TAIを有効にした後で管理コンソールに容易にアクセスできるようにするには、「WebSphereのポリシー・ドメインの定義」で作成したポリシーを有効にする必要があります。「WebSphere V6.0の管理コンソール用のポリシー・ドメインの定義」で作成したポリシーも有効にする必要があります。

19. 次の項で、TAIが動作していることを確認します。

10.10.4 WAS V6のTAIのテスト

次の手順ではWAS V6のTAIのテストを説明しています。

TAIのテスト手順

TAIを構成した後、WebSphereとOracle Access Managerの間の認証とシングル・サインオンが正常にできるかどうかをテストします。

これらのテストを実施するには、WebSphereが提供するSnoopサーブレットを使用します。Snoopサーブレットには、認証されたユーザーのみにアクセスを許可するセキュリティの制約があります。

WebSphereセキュリティが有効になっていない場合、Snoopへのアクセスは制限されません。

WebSphereセキュリティとTAIが有効になっている場合、Snoopへのアクセスを試みるユーザーはアクセス・システムによってチャレンジ方式の認証を求められます。TAIが有効になっていない場合、Snoopへのアクセスを試みるユーザーはWebSphereによってもチャレンジ方式の認証を求められます。

アクセス・システムが保護するWebSphereリソースのシングル・サインオンをテストする手順

1. WASのアクセスに使用するWebサーバー上で、ドキュメント・ルートに移動し、testという名前のディレクトリを作成します。

2. testディレクトリで、index.htmlという名前のファイルを作成します。

3. アクセス・システムで、/snoopディレクトリおよび/testディレクトリを保護するポリシーを作成して有効にします。

4. 次のURLでSnoopサーブレットにアクセスします。

   http://hostname.domain.com:80/snoop

   ここで、hostnameはWebサーバーがインストールされているマシンの完全修飾名です。

   チャレンジ方式の認証を受けます。認証されると、Snoopサーブレットにアクセスできます。

5. /test URLにアクセスします。

   チャレンジ方式の認証を受けずに、URLへのアクセスとindex.htmlファイルの表示ができることを確認します。

10.10.5 WAS V6のTAIのログの有効化

WebSphere管理コンソールからTAIのログを有効化できます。

WAS V6のTAIのログを有効化する手順

1. WebSphere管理コンソールを起動します。

2. 「Troubleshooting」、「Logs and Trace」に移動します。

3. サーバーを選択します。

4. 「Change Log Level Details」を選択します。

5. 「Components」を選択します。

6. com.oblix.tai.was5.WebGateTrustAssociationInterceptorのデバッグ・ログを有効化します。

10.11 構成ファイル

WebSphere用コネクタとWASの統合時には、次の構成ファイルが使用されます。

• NetPointWASRegistry.properties

• WebGate.properties

• TrustedServers.properties

10.11.1 NetPointWASRegistry.properties

表10-1は、CWS_install_dir /oblix/configにあるNetPointWASRegistry.propertiesファイルのパラメータを示します。このファイルは、NetPointWASRegistryのインストール時に指定されたデータとロギングのデフォルト・パラメータ値の一部を含みます。次に例を示します。

# Logging level (none, info or debug);
OB_LogLevel=debug
OB_LogFileName=C:/CWS_install_dir/log

Oracle Access Manager WebSphere用コネクタは、Access ServerまたはIdentity Serverから取り出したデータをキャッシュします。WebSphereサーバーからの後続のリクエストでは、ユーザーとグループのデータがコネクタ・キャッシュから検索されます。キャッシュはスケジュールに基づいて更新されます。コネクタ・キャッシュ内のユーザー、グループまたはユーザー・プロファイルの属性エントリはそれぞれ、NetPointWASRegistry.propertiesファイルに定義される「TTL」（TTL）パラメータに関連付けられています。タイムアウト制限に到達した後でリクエストが発行されると、キャッシュ・ミス・ハンドラが呼び出され、Identity ServerおよびAccess Serverから取り出されたデータを更新します。NetpointWASRegistry.propertiesファイル内のすべてのキャッシュ・パラメータのデフォルト・タイムアウトは3600秒です。この値は必要に応じて設定できます。Identity ServerおよびAccess Serverとコネクタ間での動的キャッシュ更新はありません。ユーザー、グループまたはユーザー・プロファイル属性の変更を即座に反映するには、キャッシュ・タイムアウト値を0に設定します。値を0にするとコネクタ・キャッシュが無効になります。

注意: WebpassからGroupSrvCenterへのパフォーマンスは、IDシステム内のIdentityXML呼び出しを改善する構成オプションを追加することで向上しました。たとえば、ネストされたグループを使用されていなくてオフになっている場合、ネストされたグループに対してgetGroupsがリクエストを生成しないような新規のオプションを使用できます。

ヒント: 表10-1も参照してください。

表10-1 NetPointWASRegistry.propertiesのパラメータ

パラメータ名	説明	オプション/必須
インストール	.	.
OB_InstallDir	NetPointWASRegistryがインストールされるディレクトリ。	必須
ロギング	.	.
OB_LogLevel	ログ・ファイルに記録されるロギング・レベル。値は、none、infoおよびdebugです。	オプション
OB_LogFileName	カスタム・ユーザー・レジストリ（NetPointWASRegistry）のログ・メッセージのファイル名です。デフォルト: CWS_install_dir/log。 注意: CMRのログ・メッセージはWPS_install_dir/log/appserver-out.logファイルに向けられます。	オプション
OB_LogMilliSeconds=true	OB_LogFileNameで指定されたファイル内のログ・メッセージの日付時間の形式。trueの場合、ログ・メッセージは時刻をミリ秒の形式で示します。デフォルト: true。	オプション
WebPass	.	.
OB_WebPassHost	WebPassサーバーのホスト・マシンの名前。ホスト名は、OB_WebPassHost=hostname.acme.comなどのように完全修飾する必要があります。 フェイルオーバーのために複数のWebPassインスタンスを構成するには、名前をカンマで区切ります。 例: OB_WebPassHost=foo.domain.com, bar.domain.com ホスト名は指定した順序でポート番号に対応します。この表のOb_WebPassPortの説明の例を参照してください。	必須
OB_WebPassPort	ホスト・マシンのポート番号。 複数のWebPassインスタンスを構成するには、ポート番号をカンマで区切って指定します。次に例を示します。 OB_WebPassPort=80, 81 ホスト名は指定した順序でポート番号に対応します。この例では、hostname:portの数値の組は、次のようになります。 foo.domain.com:80 bar.domain.com:81 フェイルオーバーを機能させるには、ユーザー名、資格証明、WebGate保護など、他のすべての変数を同じにする必要があります。	必須
OB_WebPassIsProtected	値はtrueおよびfalseです。WebPassを保護する場合は、value=trueに設定します。	必須
OB_AdminUserName	IDシステムでは、WebPassへのIdentityXML呼び出しを行うためのAdminのユーザー名とパスワードが必要です。管理者権限の詳細は、「Identity Serverの構成」を参照してください。	必須
OB_AdminUserCreds	IDシステムでは、WebPassへのIdentityXML呼び出しを行うためのAdminのユーザー名とパスワードが必要です。パスワードを指定しないと、コネクタは機能しません。 注意: パスワードはクリアテキストで入力する必要があります。プログラムは最初の実行時にパスワードを暗号化してプロパティ・ファイルにリライトします。	必須
Cookie	.	.
OB_CookieDomain	WebGateインストーラ構成で指定されたCookieドメイン。WebPassが保護されている場合に必要です。 たとえば、.xyz.com	必須
OB_CookiePath	WebGateの構成で指定されたCookieのパス。WebPassが保護されている場合に必要です。 デフォルト: /。	必須
WebPass SSL	.	.
OB_WebPassSSLEnabled	WebPassがHTTPS接続を必要とするかどうかを指定します。値はtrueおよびfalseです。 デフォルト: false。	必須
ログインおよび検索の属性	.	.
OB_UserAttr	一意のユーザーID（uidなど）。	必須
OB_UserSearchAttr	LDAPからのユーザーのDN接頭辞（cnなど）。	必須
OB_GroupSearchAttr	LDAPからのグループのDN接頭辞（cnなど）。	必須
Active Directoryフォレスト	.	.
OB_WebPassADDomain	オプション。Adminユーザーのドメイン。Active Directoryフォレストに複数ドメインがある場合に使用します。たとえば、OB_WebPassADDomain=ou=company,dc=qalab,dc=acme,dc=comThe ADDomainは、Identity Serverで定義されたデフォルトと同じである必要があります。	オプション
返されるレコード	.	.
OB_WebPassXPIRecordsReturned	オプション。getUsersまたはgetGroupsに対して返すレコードの数。これは、WebSphere Portal.Default = return allの場合にのみ使用されます。	オプション
認証	.	.
OB_AuthnSchemeResourceTypeName	Authen	必須
OB_AuthnSchemeOperation	LOGIN	必須
OB_AuthnSchemeResourceName	/Authen/Basic	必須
OB_AuthzActionType	WAS_Registry	必須
OB_AuthzActionName	uid	必須
キャッシュ	.	.
OB_AllUserCache_enabled	すべてのユーザーのキャッシングを有効にします。値はtrueおよびfalseです。	オプション
OB_AllUserCache_timeout	全ユーザーのリストのキャッシュのタイムアウト。	オプション
OB_UserAttributesCache_enabled	ユーザー属性のキャッシングを有効にします。値はtrueおよびfalseです。	オプション
OB_UserAttributesCache_timeout	ユーザー属性のキャッシュのタイムアウト。タイムアウトはキャッシュ全体に対してです。	オプション
OB_UserAttributesCacheElement_timeout	キャッシュされるユーザー属性のタイムアウト。タイムアウトはユーザーごとです。	オプション
OB_GroupAttributesCache_enabled	グループ属性のキャッシングを有効にします。値はtrueおよびfalseです。	オプション
OB_GroupAttributesCache_timeout	グループ属性のキャッシュのタイムアウト。タイムアウトはキャッシュ全体に対してです。	オプション
OB_GroupAttributesCacheElement_timeout	キャッシュされたグループ属性のタイムアウト。タイムアウトはグループごとです。	オプション
OB_AllGroupCache_enabled	全グループのリストのキャッシングを有効にします。値はtrueおよびfalseです。すべてのグループに対してのみ使用されます。多くの場合、管理コンソールから使用されます。	オプション
OB_AllGroupCache_timeout	全グループのリストのキャッシュのタイムアウト。	オプション
OB_UserGroupsCache_enabled	ユーザーがメンバーであるグループのリストのキャッシングを有効にします。値はtrueおよびfalseです。ログイン・ユーザーが属するすべてのグループのキャッシュを保持します。	オプション
OB_UserGroupsCache_timeout	ユーザーが属するグループのリストのキャッシュのタイムアウト。タイムアウトはユーザーごとです。この値は、あまり大きい値にしないことをお薦めします。ユーザーのグループ・メンバーシップが変わる場合、新しいメンバーシップはキャッシュ・タイムアウト時にのみ有効になります。たとえば、3600の値は1時間に相当します。	オプション
OB_GroupMembersCache_enabled	グループ・リストおよび各グループのメンバー・リストのキャッシングを有効にします。値はtrueおよびfalseです。各グループのメンバーを格納します（頻繁に使用されるキャッシュではありません）。	オプション
OB_GroupMembersCache_timeout	グループ・リストと各グループのメンバー・リストのキャッシュのタイムアウトを指定します。	オプション
キーストア	.	.
OB_Keystore	HTTPS WebPassへのSSL接続を作成するときに、レジストリが使用するキーストア・ファイルを指定します。キーストアには、リクエスタの公開鍵と秘密鍵のペア、X.509証明書、レスポンダ・サーバーを証明する信頼できる認証局の証明書が含まれます。キーストアはJDK keytoolを使用して管理します。 例: CWS_install_dir/oblix/config/jssecacerts	オプション
OB_KeystorePassword	オプション。キーストアのパスワード。	オプション
ユーザーおよびグループ	.	.
OB_UserTabId	将来使用するためのものです。デフォルトを変更しないでください。デフォルト: Employees。	必須
OB_GroupTabId	将来使用するためのものです。デフォルトを変更しないでください。デフォルト: Groups。	必須
パフォーマンス	.	.
OB_NestedGroupsEnabled	値はtrueおよびfalseです。デフォルトはtrueです。ネストされたグループを使用しない場合にGroupSrvCenterのパフォーマンスを向上させるには、値をfalseに設定します。 ネストされたグループは検索に含まれません。OB_NestedGroupsEnabled=falseの場合、グループ検索でuniquemember属性はリクエストされません。 値がtrueの場合は、グループ検索でuniquemember属性が取得され、ネストされたグループの計算に使用され、グループが記録される前に削除されます。	オプション
OB_DynamicGroupsEnabled	値はtrueおよびfalseです。動的グループを使用しない場合にGroupSrvCenterのパフォーマンスを向上させるには、値をfalseに設定します。動的グループは検索に含まれません。	オプション
複数ドメインでの一意でないログインID	.	.
OB_DnIsUniqueIdentifier= 「WebGate.properties」のOB_DnIsUniqueIdentifier=も参照。	値はtrueおよびfalseです。デフォルトはfalseです。複数ドメインでの一意でないログインIDを持つ複数ドメイン・ディレクトリ・サーバーで動作するWebSphere用コネクタを有効にするには、値をtrueに設定します。	オプション

10.11.2 WebGate.properties

表10-2はwebgate.propertiesファイルのパラメータを示しています。このファイルは、CWS_install_dir /oblix/configにあり、コピーがWAS_install_dir \propertiesにあります。

表10-2 webgate.propertiesのパラメータ

パラメータ	説明
OB_InstallDir	NetPointWASRegistryがインストールされるディレクトリ。デフォルト: CWS_install_dir。
OB_ISPROXYENABLED	プロキシ・サーバーを使用しない場合は必要ありません。デフォルト値はfalseです。プロキシ・サーバーを使用する場合、値をtrueに変更する必要があります。
OB_hostnames	プロキシ・サーバーを使用しない場合は必要ありません。ホスト・マシンの名前。これはプロキシ・サーバーにのみ使用します。
Ob_loginID	必須ではありません。
OB_AuthnSchemeResourceTypeName	Authen
OB_AuthnSchemeOperation	LOGIN
OB_AuthnSchemeResourceName	/Authen/Basic
OB_AuthzActionType	uid
OB_DnIsUniqueIdentifier	複数ドメインでの一意でないログインIDを持つ複数ドメイン・ディレクトリ・サーバーで動作するWebSphere用コネクタを有効にする場合を除き、必須ではありません。 「NetPointWASRegistry.properties」の「複数ドメインでの一意でないログインID」も参照してください。

10.11.3 TrustedServers.properties

表10-3は、trustedservers.properties構成ファイルのパラメータを説明しています。

表10-3 TrustedServers.propertiesのパラメータ

パラメータ	説明
com.ibm.websphere.security.trustassociation.enabled	true
com.ibm.websphere.security.trustassociation.types	webgate
com.ibm.websphere.security.trustassociation.webgate.interceptor	com.oblix.tai.WebGateTrustAssociationInterceptor
com.ibm.websphere.security.trustassociation.webgate.config	webgate

10.12 TAIの実装の注意事項

次の実装は、複数ドメインでの一意でないログインIDを持つ複数ドメイン・ディレクトリ・サーバーで動作するWebSphere用コネクタを有効にするためのオプションです。

このオプションの実装を行うには、NetPointWASRegistry.propertiesファイルの次の2つのパラメータを使用します。

OB_DnIsUniqueIdentifier=

デフォルトはfalseです。DNを使用する場合、OB_DnIsUniqueIdentifierをtrueに設定します。

複数ドメインで一意でないログインIDを使用して、WebSphere用コネクタが複数ドメイン・ディレクトリ・サーバーで動作するには、webgate.propertiesファイルの次のパラメータも必要です。

OB_DnIsUniqueIdentifier=false

このオプション・パラメータは、userAttrまたはLoginIDのかわりにユーザーDNを渡すTAIモジュールを構成する場合に使用します。デフォルトはfalseです。OB_DnIsUniqueIdentifierパラメータをtrueに設定すると、DNはTAIとレジストリ間の通信に使用されます。DNを使用する場合、OB_DnIsUniqueIdentifierをtrueに設定します。

注意: NetPointRegistry.propertiesファイルおよびwebgate.propertiesファイルは同期がとれている必要があります。

前の段落で説明したオプションの実装は、次の警告に関係します。

• TAIまたはWebGateを認証の手段としてのみ使用する場合、複数ドメイン認証の要件となる可能性があるため、問題は発生しません。どのユーザーもWASアプリケーションに直接アクセスできません。

  
  

  注意: 例外は、IDシステム管理コンソールにログインする場合です。

  
  

• 一意のIDがすべてのドメインでWAS_ADMINアカウントに使用されます。

• このソリューションでは、個々のユーザーとロールのマッピングに関する機能の低下が発生します。

WAS 5では、IDシステム・グループによってのみロールのマッピングが行われます。

10.13 Active Directoryの実装の注意事項

次の項では、Active Directory上のWebSphere用コネクタの実装時に考慮する問題に言及します。

• Active DirectoryフォレストでのWebSphere用コネクタの構成

• NetPointWASRegistry.propertiesでのActive Directoryのドメインの設定

10.13.1 Active DirectoryフォレストでのWebSphere用コネクタの構成

Active DirectoryフォレストにWebSphere用コネクタを構成する手順を示します。

Active Directoryフォレスト用コネクタを構成する手順

1. アクセス・システム・コンソールで、Active Directoryフォレスト内のドメインに新しいBasic Over LDAP認証スキームを作成します。

   「プラグイン」フィールドで指定するベース資格証明は、ディレクトリ・サーバー・プロファイルで指定した検索ベースと同じである必要があります。

   
   

   インストール前の設定ですでに管理者を作成している場合、手順2を実施する必要はありません。詳細は、「コネクタのインストール準備」を参照してください。

2. 表示と委任管理の権限を指定してOracle Access ManagerでWebSphere管理者を作成します。

   管理者のログインIDは必ず一意にします。

3. WebSphere管理者をActive Directoryフォレストのドメインの管理者として指定します。

   このドメインは、手順1で認証スキームを作成したドメインと同じである必要があります。このために、表10-1に示すようにNetPointWASRegistry.propertiesファイルにOB_WebPassADDomainパラメータの値を指定します。

   親ドメイン内のユーザーは検索できますが、兄弟関係のドメインまたは子ドメイン内のユーザーは検索できません。

   
   

   注意: Active Directoryフォレストのすべてのドメインに管理者を作成する必要はありません。

   
   

10.13.2 NetPointWASRegistry.propertiesでのActive Directoryのドメインの設定

複数のドメインでActive Directoryを実行している場合、NetPointWASRegistry.propertiesファイルを手動で編集してOBWebPassADDomainパラメータの値を指定する必要があります。

たとえば、OBWebPassADDomain=dc=xyz, dc=acme, dc=com

ドメインは、Oracle Access Managerでデフォルト・ディレクトリ・サーバーに定義されるドメインと同じである必要があります。

詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。

#OB_UserAttrは、ログイン属性サンプルのLoginID（uidまたはgenuserid）である必要があります。

10.14 WebSphere用コネクタのトラブルシューティング

次に示すのは、WebSphere用コネクタに関して最も頻繁に挙がる質問のリストです。「Portal Server V5用コネクタのトラブルシューティング」も参照してください。

問題

WASのロールのマッピングでユーザーまたはグループを検索しようとしています。検索文字列を指定していますが、エラー・メッセージが出ます。

解決方法

WASのロール・マッピングではすべての検索文字列にワイルドカードが必要です。検索文字列の先頭と末尾にアスタリスク（*）を指定します。たとえば、"*user123*"という検索では、サブストリングとして"user123"を持つすべてのユーザーIDが返されます。

問題

WAS 5の管理コンソールからロックアウトされました。あるいは、構成変更の実施後にWebSphere 5 Serverが開始されません。どのように解決しますか。

解決方法

WAS_install_dir/config/cells/serverNameディレクトリにある、前のWAS 5.0 security.xmlファイルをリストアします。これは、前の世代のワーキング・コピーのバックアップを取得していることを前提にしています。

問題

Solarisで、WebSphere用コネクタのSSLコネクタを設定するときに、keytoolコマンドが「Signature not available」というエラーになります。

解決方法

これは、jdk 1.2.xの問題です。NTバージョンまたは他の任意のjdk1.3.xバージョンでcert db（jssecacerts）を作成し、Solaris上のWebSphereで使用します。

問題

「All the jars are not in classpath: NoClassDefException」というメッセージが出ます。

解決方法

NetPointWASRegistry.jarおよびjobaccess.jarがクラスパス内にあることを確認します。

問題

ピアが認証されないという例外SSLPeerUnverifiedExceptionが発生します。

解決方法

使用されるjvmが、caおよびサーバーの証明書をインポートしたjvmと異なります。jvmおよびkeytoolは同じインストールのものである必要があります。あるkeytoolを使用して証明書を追加し、他のインストール・ディレクトリからjavaを呼び出す場合、jvmは証明書を使用できず、この例外が発生します。

問題

ObConfig.NO_CONFIG_FILEを受け取りました。

解決方法

このエラーは、Access Manager SDKクライアント構成が見つからないことを意味します。NetPointWASRegistry.propertiesファイル内のInstall_Dirパラメータをチェックし、次のものがNetPointWASRegistryインストール・ディレクトリを指していることを確認します。次に例を示します。

# Installation directory of NetPointWASRegistry OB_InstallDir=/CWS_install_dir/oblix/config/

問題

UnsatisfiedLinkErrorを受け取りました。

解決方法

プラットフォームに応じたPATHまたはLD_LIBRARY_PATHにAccess Manager SDK libが存在しない可能性があります。

例:

• NTの場合: PATHを次のように指定します。

  set PATH=%PATH%;c:\CWS_install_dir\oblix\lib

• Solarisの場合: LD_LIBRARY_PATHを次のように指定します。

  setenv LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/CWS_install_dir/oblix/lib export LD_LIBRARY_PATH

  これはいずれもシステム・レベルで、または起動時に実行できます。

• AIXの場合: LIBPATHを次のように指定します。

  setenv LD_LIBRARY_PATH=$LIBPATH:/CWS_install_dir/oblix/lib export LIBPATH

  Access Manager SDK libがない場合、次のエラーを受け取る場合があります。

  "com.ibm.ejs.exception.InvalidUserRegistryConfigException: Custom [OSName]: com.oblix.registry.NetPointWASRegistry"

問題

com.oblix.access.ObAccessExceptionのNoClassDefFoundエラーを受け取りました。

解決方法

jobaccess.jarファイルがWebSphereのクラスパスにあることを確認します。

問題

ObSSOCookieが設定されているのを確認できません。

解決方法

WebSphere ServerとWebGateが稼働しているWebサーバーにアクセスするには完全修飾ドメイン名を使用してください。

よい例:

http://foobar.oblix.com:9080

悪い例:

http://foobar:9080

Cookieドメインで次をチェックします。

• プライマリCookieドメインがPolicy ManagerのWebGate構成に設定されていることを確認します。

• NetPointWASRegistry.propertiesファイルで、これらのパラメータの値が次のように設定されていることを確認します。OB_CookieDomain=.oblix.com, OB_CookiePath=/

問題

ObSSOCookieを参照すると、WebPassに拒否されます。

解決方法

次の手順を実施します。

• WebGateとWebpassがインストールされているマシン上の時刻が、WebSphere Server上の時刻と同期化されていることを確認します。

• WebGateの認証スキームで、WebpassリソースとWebSphere Serverリソースが同じセキュリティ・レベルであることを確認します。

問題

WebGateがObSSOCookieを拒否します。

解決方法

IPValidationパラメータが「オフ」に設定されていることを確認します。

アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、左側のナビゲーション・ペインの「AccessGate構成」をクリックし、WebPassを保護するWebGateのリンクをクリックして、「IPValidation」フィールドで「オフ」オプションを選択します。

問題

IdentityXML呼び出しが未認可の例外で失敗します。

解決方法

NetPointWASRegistry.propertiesファイルをチェックし、WebPassホスト名が完全修飾されていることを確認します。

例:

OB_WebPassHost=foobar.oblix.com

OB_WebPassPort=80

問題

WebSphere Administrative Serverの再起動時に、「server specific error 10」というメッセージを受け取りました。

解決方法

WebSphere Administration Serverを再起動する前に、すべてのJavaプロセスが中断されていることを確認します。

問題

次の例外を受け取りました。

Exception in thread "main" com.ibm.websphere.security. CustomRegistryException: admin at com.oblix.registry.NetPointWASRegistry.getUserDisplayName(NetPointWASRegistry.java:622) at com.oblix.tools.registryTester.main(registryTester.java:69)

解決方法

この例外には、多くの理由が考えられます。NetPointWASRegistryファイルで、デバッグ・フラグをオンにし、次のようなデバッグ・ログのパスをチェックします。

OB_LogLevel=debug

OB_LogFileName=/oblix/NetPointWASRegistry/log

問題

Oracle Access Managerログ・ファイルに次のエラーを見つけました。

Mon Jan 06 14:57:21 PST 2003: Error making SOAP request java.io.FileNotFoundException: 
http://cobalt.oblix.net:80/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi 
at sun.net.www.protocol.http. HttpURLConnection.getInputStream(HttpURLConnection.java:529)
at com.oblix.soapclient.OblixSoapClient.doRequest(OblixSoapClient.java,Compiled Code) 
com.oblix.registry.NetPointWASRegistry.realGetUserDisplayName (NetPointWASRegistry.java:650)
at com.oblix.registry.NetPointWASRegistry.getUserDisplayName( NetPointWASRegistry.java:607)
at com.oblix.tools.registryTester.main(registryTester.java,Compiled Code).

解決方法

IPValidationパラメータが「オフ」に設定されていることを確認します。

アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、左側のナビゲーション・ペインの「AccessGate構成」をクリックし、WebPassを保護するWebGateのリンクをクリックして、「IPValidation」フィールドで「オフ」オプションを選択します。

問題

Oracle Access Managerログ・ファイルに次のエラーを見つけました。

Mon Jan 20 15:37:24 GMT-06:00 2003: Error making SOAP request java.io.IOException: 
Server returned HTTP response code: 401 for URL: 
http://foobar.oblix.com:80/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi
at sun.net.www.protocol.http.HttpURLConnection.getInputStream (HttpURLConnection.java:604)
at com.oblix.soapclient.OblixSoapClient.doRequest(OblixSoapClient.java:285)

解決方法

WebGateのIPValidationパラメータが「オフ」に設定されていることを確認します。

アクセス・システム・コンソールから、「アクセス・システム構成」をクリックし、左側のナビゲーション・ペインの「AccessGate構成」をクリックし、WebPassを保護するWebGateのリンクをクリックして、「IPValidation」フィールドで「オフ」オプションを選択します。

問題

次の例外を受け取りました。"com.ibm.ejs.exception.InvalidUserRegistryConfigException: User [username] not authenticated"?

解決方法

NetPointWASRegistry.propertiesで、OB_UserAttr、OB_UserSearchAttrおよびOB_GroupSearchAttrが正しく設定されていることを確認してください。

OB_UserAttr=samaccountname

OB_UserSearchAttr=cn

OB_GroupSearchAttr=cn

問題

Oracle Access Managerログ・ファイルに次のエラーを見つけました。

java.lang.StringIndexOutOfBoundsException: String index out of range: -10 
at java.lang.String.substring(String.java(Compiled Code)) 
at com.oblix.soapclient.OblixSoapClient.handleSoapResponse(OblixSoapClient.java:345) 
at com.oblix.soapclient.OblixSoapClient.doRequest(OblixSoapClient.java:297) 
at com.oblix.registry.NetPointWASRegistry.realGetUserDisplayName (NetPointWASRegistry.java:650)
at com.oblix.registry.NetPointWASRegistry.getUserDisplayName (NetPointWASRegistry.java:607)
at com.oblix.registry.NetPointWASRegistry.getUniqueUserId (NetPointWASRegistry.java:680)
at com.ibm.ejs.security.registry.CustomRegistryImpl.createCredential (CustomRegistryImpl.java:698)
at com.ibm.ejs.security.registry.CustomRegistryImpl.authenticate (CustomRegistryImpl.java:166)
at com.ibm.ejs.security.registry.RegistryBean.authenticate (RegistryBean.java:109) at
com.ibm.ejs.security.registry.EJSRemoteStatelessRegistry.authenticate(EJSRemoteStatelessRegistry.java:25) 
at com.ibm.ejs.security.registry._Registry_Stub.authenticate(_Registry_Stub.java:275) 
at com.ibm.ejs.security.ltpa.LTPAServerObject.authenticate(LTPAServerObject.java:97) 
at com.ibm.ejs.security.util.LTPAAuthenticationCache.update(LTPAAuthenticationCache.java:167) 
at com.ibm.ejs.security.util.Cache.get(Cache.java:114) 
at com.ibm.ejs.security.util.LTPAAuthenticationCache.getCredential(LTPAAuthenticationCache.java:82) 
at com.ibm.ejs.security.SecurityServerBean.authenticateBasicAuthData(SecurityServerBean.java:145) 
at com.ibm.ejs.security.EJSRemoteStatelessSecurityServer.authenticateBasicAuthData(EJSRemoteStatelessSecurityServer.java:49) 
at com.ibm.ejs.security._SecurityServer_Stub.authenticateBasicAuthData(_SecurityServer_Stub.java:281) 
at com.ibm.WebSphereSecurityImpl.SecurityServerImpl.authenticateBasicAuthData(SecurityServerImpl.java:69) 
at com.ibm.ISecurityLocalObjectLTPAImpl.PrincipalAuthenticatorImpl.authenticate(PrincipalAuthenticatorImpl.java:437) 
at com.ibm.ISecurityLocalObjectBaseL13Impl.LoginHelperImpl.request_login_controlled(LoginHelperImpl.java:1092) 
at com.ibm.ISecurityLocalObjectBaseL13Impl.LoginHelperImpl.request_login_controlled(LoginHelperImpl.java:827) 
at com.ibm.ISecurityLocalObjectBaseL13Impl.CredentialsImpl.get_mapped_credentials(CredentialsImpl.java:1206) 
at com.ibm.ISecurityLocalObjectBasicAuthImpl.CredentialsImpl.get_mapped_credentials(CredentialsImpl.java:188) 
at com.ibm.ISecurityLocalObjectBaseL13Impl.VaultImpl.setServerCred(VaultImpl.java:3862) 
at com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthenticatorImpl.setServerCred(PrincipalAuthenticatorImpl.java:9 79) 
at com.ibm.ISecurityLocalObjectLTPAImpl.PrincipalAuthenticatorImpl.authenticate(PrincipalAuthenticatorImpl.java:302) 
at com.ibm.ISecurityLocalObjectBaseL13Impl.LoginHelperImpl.request_login_controlled(LoginHelperImpl.java:1092) 
at com.ibm.ISecurityLocalObjectBaseL13Impl.LoginHelperImpl.request_login_controlled(LoginHelperImpl.java:827) 
at com.ibm.ISecurityLocalObjectBaseL13Impl.CredentialsImpl.get_mapped_credentials(CredentialsImpl.java:1206) 
at com.ibm.ISecurityLocalObjectBasicAuthImpl.CredentialsImpl.get_mapped_credentials(CredentialsImpl.java:188) 
at com.ibm.ejs.security.SecurityCollaborator.getActualCredential(SecurityCollaborator.java:999) 
at com.ibm.ejs.security.SecurityContext.getActualCreds(SecurityContext.java:75) 
at com.ibm.ejs.security.Initializer.bindServerIdToAdminApp(Initializer.java:458) 
at com.ibm.ejs.security.Initializer.initialize(Initializer.java:217) at com.ibm.ejs.security.Initializer.serverStarted(Initializer.java:133) 
at com.ibm.ws.runtime.Server.fireServerStarted(Server.java:2001) 
at com.ibm.ws.runtime.Server.fireServerStarted(Server.java:1994) 
at com.ibm.ejs.sm.server.AdminServer.initializeRuntime0(AdminServer.java:1144) 
at com.ibm.ws.runtime.Server.initializeRuntime(Server.java:884) 
at com.ibm.ejs.sm.server.AdminServer.main(AdminServer.java:392) 
at java.lang.reflect.Method.invoke(Native Method) 
at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:158)

解決方法

Identity Serverが稼働していることを確認します。

問題

Oracle Access Managerから更新されたパスワードを受け付けたにもかかわらず、Portal Serverが古いパスワードでのログインを許可します。

解決方法

Portal Serverのインストールでは、セキュリティ・キャッシュのタイムアウトを600秒に設定しているため、この時間はキャッシュ内に古いパスワードが保管されます。このパラメータは、WebSphere Application Server管理コンソールのセキュリティ・センターの「General」タブの下にあります。

問題

Oracle Access Managerユーザーが非アクティブな状態になってもWebSphereリソースにアクセスできます。

解決方法

これを回避するには、WebSphereが使用するすべての認証スキームに次の行を追加します。

(|(!(obuseraccountcontrol=*))(obuseraccountcontrol=ACTIVATED))

問題

WebSphere Portal Serverが開始されず、セキュリティ例外が発生します。

解決方法

LPTAトークン・ドメインが正しく設定されていることを確認してください。

問題

URLリソースをBasic Over LDAP認証スキームで保護する場合、TAIが有効でも、シングル・サインオンが機能しません。

解決方法

「WebSphere V5のTAIの構成」に示す手順に従っていること、Basic Over LDAP認証スキームの「チャレンジ・リダイレクト」フィールドを設定していることを確認します。

問題

WebSphere管理コンソールのイベント ビューアに次のエラーが表示されます。

CNTR0020E: Non-application exception occurred while processing 
method isAllLevelNone on bean BeanId(admin#repository.jar#PmiService, null):
javax.transaction.TransactionRolledbackException: 
CORBA TRANSACTION_ROLLEDBACK 0 No; nested exception is:
org.omg.CORBA.TRANSACTION_ROLLEDBACK: minor code: 0 completed: No
org.omg.CORBA.TRANSACTION_ROLLEDBACK: minor code: 0 completed: No
at com.ibm.ejs.jts.jts.JBrokerSupport$RI.client_unmarshalled_reque st (JBrokerSupport.java:405)
at com.ibm.CORBA.iiop.RIs.iterateClientRequestPreRIs(RIs.java (Compiled Code))
at com.ibm.CORBA.iiop.ClientRequestImpl.reInvoke (ClientRequestImpl.java:851)
at com.ibm.CORBA.iiop.ClientDelegate.invoke (ClientDelegate.java:894)
at com.ibm.CORBA.iiop.ClientDelegate.invoke (ClientDelegate.java:409)
at org.omg.CORBA.portable.ObjectImpl._invoke (ObjectImpl.java:258)
at com.ibm.ejs.sm.agent._AdminAgent_Stub.invokeActiveObject (_AdminAgent_Stub.java:39)

解決方法

これは、WebSphere Application Serverの起動時間が長い場合に発生する可能性があります。この問題には複数の理由が考えられます。たとえば、起動サーブレット（load-on-startup = true）で、サーブレットに対するinit()メソッドの実行に長時間かかる場合があげられます。

Ping初期タイムアウトがApplication Serverの開始に必要な時間より小さい値に設定されている場合、Application Serverが完全に始動してserverIsAliveメッセージを送出する前にPing初期タイムアウト警告の期限が切れます。結果として、管理サーバーはApplication Serverプロセスを中断して再起動しようとします。この状況で、クローンの状態が実行中として記録されます。

PMIクライアントは、クローンが稼働中であることを示し、クローン上のisAllLevelNoneメソッドを呼び出そうとします。クローンは存在しないため、エラー・メッセージを出して失敗します。

これを修正するには、Ping初期タイムアウトをApplication Serverが完全に開始できるだけの時間より大きい値に設定します。

問題

セキュリティを有効にして認証メカニズムとしてLDAPを構成した後、管理サーバーを再起動すると、トレース・ファイルに次のエラーが出力されます。

[02.03.21 08:37:59:957 CST] 4be2cc Initializer W SECJ0007E: 
Error during security initializationjava.lang.NullPointerException 
at com.ibm.ejs.security.ltpa.LTPAPrivateKey.decode(LTPAPrivateKey.java:50) 
at com.ibm.ejs.security.ltpa.LTPAPrivateKey.<init>(LTPAPrivateKey.java:40) 
at com.ibm.ejs.security.ltpa.LTPAServerBean.updateAll(LTPAServerBean.java:106) 
at com.ibm.ejs.security.Initializer.updateActiveLtpaConfig(Initializer.java:392) 
at com.ibm.ejs.security.Initializer.propagateSecurityConfig(Initializer.java:296) 
at com.ibm.ejs.security.Initializer.initialize(Initializer.java:173) 
at com.ibm.ejs.security.Initializer.serverStarted(Initializer.java:129) 
at com.ibm.ws.runtime.Server.fireServerStarted(Server.java:1977) 
at com.ibm.ws.runtime.Server.fireServerStarted(Server.java:1970) 
at com.ibm.ejs.sm.server.AdminServer.initializeRuntime0(AdminServer.java:1123) 
at com.ibm.ws.runtime.Server.initializeRuntime(Server.java:882) 
at com.ibm.ejs.sm.server.AdminServer.main(AdminServer.java:391) 
at java.lang.reflect.Method.invoke(Native Method) 
at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:158)
[02.03.21 08:38:00:001 CST] 4be2cc Server A WSVR0023I: 
Server __adminServer open for e-business

解決方法

キーとパスワードの同期がとれなくなる場合があります。WebSphereで使用する新しいキーを作成します。

新しいキーを作成するには、次のようにします。

1. 「Authentication」タブの下でSecurity Center（4.0x）またはGlobal Security Wizard（3.5x）から、「Generate Keys」をクリックします。

2. 入力を求められたら、新しいキーのパスワードを入力します。

問題

ユーザーがWebSphere管理コンソールにログインしようとすると、次のエラーが発生します。

ADGU2009E: Security Error: Either username/password is wrong or this user is not authorized to connect to admin server.

解決方法

セキュリティが有効になっている場合、WebSphere管理コンソールにログインできるのは次のユーザーのみです。

• カスタム・レジストリ/LDAPのセキュリティIDに定義されたユーザー。

• 管理ロールに定義されたユーザー。

問題

WASリソースまたはWebSphere Portalリソースにアクセスしようとして、「Not Authorized」というエラーを受け取りました。

解決方法

このエラーはObSSOCookieが送信されていない場合に発生します。ObSSOCookieを送信するためにページをリフレッシュします。

フォーム・ベースの認証スキームを使用してこの問題を回避することをお薦めします。Basic認証スキームを使用する場合、確実にObSSOCookieが送信されるように、「チャレンジ・リダイレクト」フィールドに別のWebGateを設定します。

問題

TAIが次のスタック・トレースでエラーになる場合。

... 1493ff35 JaasLoginHelp E SECJ4001E: Login failed for testeisintuser/Default Realm ....

このエラーはObSSOCookieが送信されていない場合に発生します。

解決方法

次を実施します。

1. ObSSOCookieを送信するためにページをリフレッシュします。

2. 次のクラスに対して追加のセキュリティ・デバッグを有効にします。

   com.ibm.ws.security.*

   com.ibm.websphere.security.*

   com.ibm.WebSphereSecurityImpl.*

   SASRas

3. セキュリティのランタイムの動作の詳細を表示するには、次のコンポーネントでトレースを有効にし、出力を確認します。

   com.ibm.ws.security.*=all=enabled:com.ibm:WebSphereSecurityImpl.*=all=enabled:com.ibm.websphere.security.*=all=enabled.

   このトレース文はセキュリティ・ランタイムのトレースを収集します。

   com.ibm.ws.console.security.*=all=enabled.

   このトレース文はセキュリティ・センターGUIのトレースを収集します。

   SASRas=all=enabled.

   このトレース文は、SASのトレースを収集します（下位レベルの認証ロジック）。

   ログには、詳細なデバッグ・メッセージが出力されていて、何がエラーとなっているのかがわかります。

問題

TAIログに次のようなエラーが出力されます。

Error no action found

解決方法

WebSphereのポリシー（Authen/Basic）を保護する認証スキームに対する認証スキーム・レベルが、WebSphereリソースを保護する認証スキーム・レベル以下であることを確認します。

WAS_REGISTRYアクションが、適切に設定されていることを確認します（「WebSphereのポリシー・ドメインの定義」を参照）。認可条件式が設定されていること、および認可成功時のWAS_REGISTRYアクションが設定されていることを確認します。

問題

WAS Registrytester.batが失敗することがあります。

システム変数がパスに基づいて旧バージョンのobaccess.dllを取得することがあります。

解決方法

システム変数をチェックして、正しく設定されていることを確認します。たとえば、$PATHと$CLASSPATHが正しく設定されている必要があります。

問題

「WebSphere Portal Admin」ページでユーザーを検索できません。

解決方法

次を実施します。

1. wpsadminとしてログインし、「Portal Administration」、「Security」、「Access Control List」に移動します。

2. 「Get groups and users」をクリックします。ワイルドカード文字「*」を使用してユーザーを検索し、wpsadminを選択してリストに追加し、「OK」をクリックします。

3. ユーザーwpsadminに対して「Select the objects for the permissions」でユーザー・グループを選択し、「Go」をクリックします。

4. ユーザーwpsadminのグループAll Authenticated Usersに管理のための各種権限を与え、「Save」をクリックします。

5. 「Users and Groups」、「Manage Users」に移動し、ワイルドカード文字「*.」を使用してユーザーを検索し、すべてのユーザーを表示します。

6. グループを表示するには、手順a、bおよびcを繰り返し、wpsadminに対して表示する必要のあるグループそれぞれに管理のための各種権限を与え、「Save」をクリックします。

問題

IBM WebSphere Portal Serverが「No Portlets to display」というエラーになります。

解決方法

次を実施します。

1. WebSphere管理コンソールにログインします。WebSphere Portalアプリケーションに移動します。

2. 「JVM settings」タブをクリックし、「System Properties」に次を追加します。

   "HttpSession.RecurseThroughProxy", value = "true"

3. WebSphere Portalアプリケーションを再起動します。

10.14.1 Portal Server V5用コネクタのトラブルシューティング

次のPortal Server V5の問題を対象としています。

• Portal Server V5のインストールに関連する問題

• カスタム・セキュリティ統合に関連する問題

10.14.1.1 Portal Server V5のインストールに関連する問題

Portal Serverのインストールに関連して発生する可能性のある問題がいくつかあります。次に示す問題と解決方法の記述を参照してください。

問題

WebSphere AppServerとPortal Serverはいずれも正常にインストールされたが、Portal Serverのページ（wps/portal）にアクセスできません。

解決方法

該当のPortal Serverバージョンとの統合のためにApplication Serverに適用する必要のあるフィックス・パックを確認します。フィックス・パックを適用する順序は重要です。

たとえば、Application Server 5.0とPortal Server 5.0の場合は、フィックス・パック1をWebSphere Application Serverに適用する必要があります。パッチ適用の順序は、次のようになります。

• Wasfp1

• Pmefp1

• Fixes

• Manualfixes

$WAS_install_dir/properties/version/historyフォルダをチェックして、Application Serverに適用するフィックスのリストを確認できます。

詳細は、IBM WebSphereのサイトから入手できるWebSphere Portal InfoCenterドキュメントを参照してください。

問題

Portal Server（wps/portal）へのログイン時に、次のエラー・メッセージが表示されます。

There has been an application error!Please contact to your system administrator to report this error.

解決方法

必要なフィックス・パックがApplication Serverに適用されていることを確認してください。この項の最初の問題を参照してください。また、WebSphere Application ServerでJava 2セキュリティが無効になっていることを確認してください。

Java 2セキュリティを無効にする手順

1. WebSphere Application Server Consoleにログインし、「Security」、「Global Security」に移動します。

2. 「Enforce Java 2 Security」オプションのチェック・ボックスを無効にします。

3. 変更内容を保存し、WebSphere Application ServerとPortal Serverの両方を再起動します。

   
   

   注意: WebSphere Application Serverのグローバル・セキュリティを無効にしてPortal Serverをインストールすることをお薦めします。

   
   

問題

Portal Serverに正常にログインしたときに、Portal AdminがPortal Serverを管理するための「Administration」リンクを表示できません。このリンクはページの右上に表示されます。

Administrationポートレットがシステム上にデプロイされていません。

解決方法

次を実施します。

1. WPSconfig.{bat | sh}ポートレット・スクリプトを実行し、同じものをデプロイします。

   このスクリプトはWPS_install_dir/configフォルダにあります。詳細は、wpsconfg.xmlファイルを確認してください。

2. Portal Serverを再起動し、システム管理者の資格証明を使用してログインします。

   Portal Adminユーザーは、「Administration」リンクを表示し、Portal Serverアプリケーションを設定できます。

1. 
   

   注意: 同じスクリプトで、Portal Serverのインストールに付属するサンプル・ポートレット・アプリケーションもデプロイします。また、WPS_install_dirはPortal Serverのインストール先ディレクトリです。

   
   

問題

Portal Serverに正常にログインしたときに、Portal Adminでポートレット・ページを表示できません。次のようなエラー・メッセージが表示されます。

There is no content available.Please check if there is content defined for the markup of your client device.

このメッセージは、Portal Serverにポータル・ページが作成されていないために出力されます。

解決方法

Portal Serverにページを作成し、このページにポートレットを追加します。

ページを追加するには、ページの追加権限と修正権限が必要です。また、新しいページを追加したり、ページを編集したりするポートレットをインストールする必要があります。

必要なポートレットがシステムにデプロイされているかどうかを確認するには、問題3を参照してください。

問題

Portal Serverのuser searchインタフェースからユーザーを検索するときには、検索結果として空のレコードを受け取る場合があります。この問題は、ディレクトリ・サーバーに格納されているユーザー名がLatin ISO-8859-1形式である場合に発生します。

解決方法

次の環境変数の設定を解除します。

unset LC_COLLATE LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME

10.14.1.2 カスタム・セキュリティ統合に関連する問題

次の問題は、カスタム・セキュリティ統合に関連する問題です。

問題

Portal Server構成は、カスタム・メンバー・リポジトリ（WASコネクタ）に対応して実施しましたが、ユーザーはカスタム・データ・ストアのユーザーIDでPortal Serverにログインできません。ユーザーはOracle Access Manager内に存在します。

解決方法

$WPS_install_dir\shared\app\wmm\ wmm.xmlファイルを確認します。ProfileRepositoryタグがカスタム・メンバー・リポジトリの実装に対して正しく構成されていることを確認します。

WPSconfigスクリプトの実行によってwmm.xmlファイルが変更されたり、LDAP設定がカスタム・メンバー・リポジトリの設定を置き換えたりすることがあります。

注意: カスタム・メンバー・リポジトリ用に構成したwmm.xmlファイルのバックアップを常に保存しておくことをお薦めします。

問題

Portal Adminはカスタム・データ・ストア内のユーザーを検索できますが、ポートレット・アクセス許可を割り当てると、正常にログインした後にユーザーはポートレットを表示できません。

この問題は、カスタム・データ・ストア内にあるユーザーDNに中間の空白が含まれるために発生します。

たとえば、cn=Portal User, o=company, c=usのようになっています。

WebSphere Portalは、内部的なCloudscapeデータベース内にある許可されたユーザーDNと付き合せる前にDNを正規化します。文字列のエントリが一致しないと、そのユーザーへのアクセス許可はエラーとなります。

解決方法

この問題を解決するには、IBMから提供されるフィックス・パックPQ93461を適用します。

問題

Portal ServerからIDシステム・ユーザーまたはグループを検索する際に最初の10エントリのみを取り出す（あるいは、取り出すエントリの数を指定する）にはどうしたらよいですか。

解決方法

取り出すレコード数のパラメータは、NetpointWASRegistry.propertiesファイルで構成可能です。

パラメータの名前はOB_WebPassXPIRecordsReturnedです。

このパラメータが定義されていない場合、またはゼロに設定されている場合は、Oracle Access Managerリポジトリ内のすべてのユーザーまたはグループを取り出します。

問題

Portal Adminユーザーがポートレットをインストールできません。

この問題は、Portal Server内の無効なデプロイの資格証明に関連します。

解決方法

WPSConfig.{bat/sh} action-create-deployment-credentialsスクリプトが実行されているかどうかを確認します。

このスクリプトの実行により、Portal Server内に必要なクリデンシャル・ボールトが作成されます。

このスクリプトの実行前に、wpsconfig.propertiesファイルを確認してください。『Oracle Access Managerインストレーション・ガイド』で言及されている構成パラメータの値をすべてチェックします。

$WPS_install_dir\ shared\app\config\services\VaultService.propertiesに正しいsystemcred.dn値が含まれることも確認します。これはPortal AdminユーザーDNである必要があります。

正常に実行された後で、Portal Serverに対してクリデンシャル・ボールトが作成されたことを確認します。

「Portal Server Login」、「Administration」、「Access」、「Credential Vault」、「Manage System Vault Slots」から同じ内容をチェックします。

問題

Oracle Access ManagerのWASレジストリおよびCMRのデバッグ・ログをどのような方法で入手できますか。

解決方法

WASレジストリ・ログでは、NetpointWasRegistry.propertiesファイルの次のパラメータを設定します。

OB_LogLevel=debug

OB_LogFileName=log file complete path

CMRログとPortal Serverログのセットを有効にするために、$WPS_install_dir\ shared\app\config\log.propertiesファイルの次のパラメータを設定します。

traceString=*=all=enabled

com.ibm.wps.services.puma.*=all=enabled:

com.ibm.wps.puma.*=all=enabled:

com.ibm.wps.command.puma.*=all=enabled:

com.ibm.wps.engine.commands.*=all=enabled:

com.ibm.wps.services.authentication.*=all=enabled:

com.ibm.ws.security.*=all=enabled:

com.ibm.websphere.security.*=all=enabled

pumaサービス・ログはすべて「Trace.log」ファイル内に生成されます。

ログの有効化の詳細は、Portal Server InfoCenterドキュメントを参照してください。

問題

WebSphere Application ServerとPortal Serverの停止および起動をどのように行いますか。

解決方法

Application Server使用の開始および停止の手順

• 次のように、startServerコマンドを実行します。

  $WAS_install_dir/bin/startServer name_of_app_server

  （デフォルト名はserver1です）

• 次のように、stopServerコマンドを実行します。

  $WAS_install_dir/bin/stopServer name_of_app_server -username WAS_Admin_userid -password WAS_Admin_Pwd

Portal Server使用の開始および停止の手順

• 次のように、startServerコマンドを実行します。

  $WAS_install_dir/bin/startServer name_of_portal_server

  （デフォルト名はWebSphere_Portalです）

• 次のように、stopServerコマンドを実行します。

  $WAS_install_dir/bin/stopServer name_of_portal_server -username PortalAdmin -password PortalAdminPwd

問題

Portal AdminがOracle Access Managerリポジトリ内のユーザーを検索できません。しかし、ユーザーはPortal Serverにログインできます。

解決方法

解決方法: PumaService.propertiesファイルのuser.fbadefault.filterパラメータをチェックします。このパラメータは、カスタムCMR実装に渡される属性名を含む必要があります。WASコネクタはこの属性を使用して、Portal Adminユーザーが有効なユーザーであることを確認します。

例外の詳細はtrace.logファイルをチェックします。

問題

Portal Serverの開始時に、CMRが無効なポータル管理者資格証明を受け取ります。

解決方法

$WPS_install_dir/configフォルダからWpconfig. {bat/sh} action-secure-portal-ldapスクリプトを実行します。

問題

Oracle Access Managerセキュリティを有効にして、管理者IDでポートレットをインストールできません。

解決方法

解決方法: 適切な資格証明が使用されていることを確認するために、次の手順を実施します。

1. WasUseridとWasPasswordの正しい値が次のファイルに設定されていることを確認します。

   wpconfig.properties

   WasUseridは、管理DNではなく、管理ユーザーIDである必要があります。必要に応じて、任意のプレーン・テキスト・エディタを使用して、wpconfig.propertiesを開き、WasUseridとWasPasswordの値を修正します。wpconfig.propertiesを保存して閉じます。

2. 次のコマンドを実行したことを確認します。

   wpconfig.bat\.sh action-create-deployment-credentials

   このコマンドを実行していないことを発見したら、コマンドを実行し、ポートレットのインストールに進みます。

   以前にWasUseridまたはWasPasswordに適切でない値を指定してスクリプトを実行したことに気付いた場合は、次の2つのコマンドを実行して無効な値を修正します。

   wpconfig.bat\.sh action-remove-deployment-credentials

   wpconfig.bat\.sh action-create-deployment-credentials

3. 「Portal Administration」、「Access」、「Credential Vaults」、「Manage system vault slots」、「deployment.user.Vault」に移動して、管理者IDが正しく定義されていることを確認します。

問題

WebSphere 6.0では、WebSphere Application Server管理コンソールから検索を実行した場合にユーザーが1件も返されません。

通常は、Oracle Access Managerログに次で始まるエラー・メッセージが出力されます。

Error making SOAP request . . .

解決方法

$LANG変数およびすべての$LC_*変数がen-USに設定されていることを確認します。SLES 9のlocaleコマンドでこれらの変数の現在の値をチェックできます。

問題

WebSphere Application Server 6.0のクライアント証明書認証機能でWebサーバーのhttpsポート上のSnoopアプレットにアクセスできません。

解決方法

Webサーバーが使用するSSLポートが、Application Server上のdefault_host仮想ホスト構成に追加されていることを確認します。これが存在しない場合は、次の手順を実施します。

1. WebSphere管理コンソールを起動します。

2. 「Environment」、「Virtual Hosts」、「default_host」、「host aliases」に移動します。

3. ホスト名* Port: 443を追加します（これは、Webサーバーが使用するSSLポートです）。

4. 変更内容を保存します。

5. 次の手順を実施してプラグインを再生成します。

   1. 「Servers」、「Web servers」に移動します。

   2. プラグインを作成するWebサーバーを選択します。

   3. 「Generate Plugin」を選択します。

      生成されたプラグインを表示するには、「WebServerName」、「plugin properties」、「View」、「PlugInFileName」に移動します。

   4. Webサーバーを再起動します。

6. SSLポートが有効になっていることを確認するには、次の手順を実行します。

   1. テスト・リソースを保護するアクセス・システム・ポリシーを無効にします。

   2. WebSphere Authenticationを排他的に使用してテスト・リソースにアクセスを試みます。

      次のURLを使用します。

      https://WebServerHostMachineName:sslPortNumber/snoop

   3. これが正常に機能したら、アクセス・システム・ポリシーを再度有効にします。