| Oracle® Identity Manager Webservicesコネクタ・ガイド リリース11.1.1 E91915-02 |
|
 前 |
 次 |
この章では、次のオプションの手順について説明します。
|
注意: Oracle Identity Managerリリース11.1.2以降では、参照問合せはサポートされません。Oracle Identity Managerシステム管理コンソールでの「フォーム・デザイナ」を使用した参照の管理の詳細は、Oracle Fusion Middleware Oracle Identity Managerの管理ガイドで参照の管理を参照してください。 |
|
注意: このガイドでは、Webサービス・エンドポイントを公開するターゲット・システムのことをターゲット・システムと呼んでいます。ターゲット・システムとしてACME Webserviceを使用して、構成とコネクタ・オブジェクトについて説明します。 |
この項では、コネクタの保護を有効にする次の手順について説明します。
このコネクタでは、ターゲットWebサービスの操作はSOAPメッセージを使用して呼び出されます。SOAPメッセージはデフォルトでは暗号化されないため、Enterprise Managerまたはテスト・ユーティリティで表示可能です。これは、パスワードのような機密情報を渡す場合に脅威となります。機密情報を保護するには、次のカスタムWebサービス・ポリシーを使用できます。
機密フィールドがOracle Identity Managerによって暗号化され、この暗号化された値がSOAコンポジットに送信されます。
値を暗号化するためのキーとして、コネクタのITリソースのパスコード属性が使用されます。
パスコードにはアルファベット、数字および特殊文字を含める必要があります。
パスコードには大文字と小文字の両方を含める必要があります。
パスコードの長さは最小8文字です。
パスコードは定期的に変更する必要があります。
知られているキーワードやすぐにわかるキーワードに類似しているパスコードは使用できません。
SOAコンポジットで指定するパスコードは、コネクタITリソースのパスコード・パラメータの値と一致している必要があります。
SOAコンポジットでは、パスワードの復号化を処理するカスタム・アウトバウンド・ポリシー(oimcp_WS_CONNECTOR_OUTBOUND)がターゲットWebサービス・パートナ・リンクに適用されます。
パスコード・フィールド、パスワード・フィールドおよびターゲット・ネームスペースはコンポジットで指定され、それらがポリシーによって使用され、パスワード・フィールドが復号化されます。
実行時には、ポリシーに従ってパスコードによるパスワード・フィールドの復号化が行われ、ターゲットWebサービスの操作を呼び出す前に、ターゲットSOAPペイロード内のフィールドが置き換えられます。
Enterprise Managerおよびペイロードでは、マスクされたパスワードのみが表示されます。
このカスタムWebサービス・ポリシーを構成するには、次のようにします。
コネクタのアウトバウンド・ポリシーをポリシー・ストアに追加します。これを行うには、次のようにします。
Enterprise Managerコンソールで、左ペインのWebLogicドメインを選択します。メイン・ページで、「WebLogicドメイン」、「Webサービス」、「ポリシー」の順に移動します。
「Webサービス・ポリシー」ページで、「ファイルからインポート」をクリックし、アウトバウンド・ポリシーを参照します。
ConnectorDefaultDirectory/Webservices-11.1.1.5.0/soa/policyディレクトリにoimcp_WS_CONNECTOR_OUTBOUNDポリシーがあります。付録B「アウトバウンド・ポリシーのサンプル」で、アウトバウンド・ポリシーのサンプルを添付します。
「OK」をクリックすると、ポリシーがインポートされます。
ポリシーがインポートされたかどうかを確認するには、http://soaserverhost:soaport/wsm-pm/validatorに移動して、インポートされたポリシーがこのページにリストされているかどうかを確認します。
カスタム・ポリシーJARファイル(Webservices-oim-integration.jar)をデプロイします。これを行うには、次のようにします。
WebLogic(管理)サーバーを停止します。
ConnectorDefaultDirectory/Webservices-11.1.1.5.0/soa/policy/のWebservices-oim-integration.jarファイルを$DOMAIN_HOME/libディレクトリにコピーします。
WebLogic Serverを再起動します。
SOAサーバーを停止します。
ConnectorDefaultDirectory/Webservices-11.1.1.5.0/soa/policy/のWebservices-oim-integration.jarファイルを$MW_HOME/Oracle_SOA/soa/modules/oracle.soa.ext_11.1.1/ディレクトリにコピーします。
ANT_HOME環境変数を設定し、antコマンドを実行します。
SOAサーバーを再起動します。
composite.xmlファイルでSOAコンポジットを構成します。これを行うには、パスワードの複合化を必要とするWebサービスの<binding.ws>タグ内に次のエントリを追加します。
<wsp:PolicyReference URI="oimcp/WS_CONNECTOR_OUTBOUND" orawsp:category="security" orawsp:status="enabled"/> <property name="passcode" type="xs:string">abcd1234</property> <property name="password.field.xpath.locations" type="xs:string">/ns6:ListOfUser/ns6:User/ns6:Password</property> <property name="target.payload.namespaces" type="xs:string">ns6=urn:/acme/xml/password</property>
このエントリの詳細は次のとおりです。
passcodeは、コネクタITリソースのpasscodeフィールドです
前述したパスコードに関するガイドラインを参照してください。
password.field.xpath.locationsは、暗号化されたパスワード・フィールドが含まれているXPathの場所のカンマ区切りリストです
target.payload.namespacesは、password.field.xpath.locationsの値に対応するターゲット・ネームスペースのカンマ区切りリストです
|
注意:
|
JDeveloperでSOAコンポジットをデプロイし、Oracle Identity Managerからパスワード・リセット操作をテストします。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。
JDeveloperで、SOAコンポジットのWebサービス・セキュリティ・ポリシーを構成できます。これを行うには、次のようにします。
ターゲットWebサービスを右クリックし、「WSポリシーの構成」をクリックします。
「SOA WSポリシーの構成」ウィンドウで、「セキュリティ」フィールドの横にあるプラス記号をクリックします。
クライアント・セキュリティ・ポリシーの選択ウィンドウで、認証用に追加するWebサービス・セキュリティ・ポリシーを選択し、「OK」をクリックします。
「OK」をクリックします。
コンポーネント・パレットで、「バインディング・プロパティ」の下にあるプラス記号をクリックして、必要なバインディング・プロパティを指定します。
SOAコンポジットの準備ができたら、JDeveloperで構築とデプロイを行うことができます。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。
資格証明ストア・ファクトリ(CSF)メカニズムを使用して、SOAコンポジットからターゲット・システムの資格証明を渡すことができます。手順は次のとおりです。
CSFでターゲット・システムの資格証明のキーを作成します。これを行うには、次のようにします。
Enterprise Managerコンソールで、左ペインのWebLogicドメインを選択します。メイン・ページで、「WebLogicドメイン」、「セキュリティ」、「資格証明」の順に移動します。
「キーの作成」をクリックし、資格証明の詳細を追加します。
「OK」をクリックしてキーを保存します。
composite.xmlファイルでSOAコンポジットを構成します。これを行うには、次のようにします。
ターゲットWebサービスを右クリックし、「WSポリシーの構成」をクリックします。
「SOA WSポリシーの構成」ウィンドウで、「セキュリティ」の下にあるセキュリティ・ポリシーを選択し、鉛筆記号を選択して編集します。
オーバーライド値列で、前の手順で作成したCSFキーの名前を入力し、「OK」をクリックします。
または、composite.xmlファイルにテキスト・モードで直接、バインディング・プロパティを追加することもできます。
<binding.ws port="urn:acme/ws/user/#wsdl.endpoint(User/Default)" location="userWrapper.wsdl" soapVersion="1.1"> <wsp:PolicyReference URI="oracle/wss_username_token_client_policy" orawsp:category="security" orawsp:status="enabled"/> <property name="csf-key" type="xs:string" many="false">acme-csf-key</property> </binding.ws>
Webサービス・セキュリティ・ポリシーの認証メカニズムではなく、カスタムSOAPヘッダーを使用してWebサービスを認証できます。このメカニズムは、ターゲットWebサービスの書式がWebサービス・セキュリティ・ポリシーに準拠していない場合に役立ちます。
カスタム・ヘッダーを使用して資格証明を渡すには、次のようにします。
XSDファイルのカスタム・ヘッダーで使用される要素のスキーマを定義します。JDeveloperで、SOAコンポジット・プロジェクトのxsdフォルダにファイルをコピーします。
ヘッダーの変数を作成します。BPELプロセスで、変数アイコン(x)をクリックし、変数を追加します。
「タイプ・チューザ」ウィンドウのカスタム・ヘッダーのXSDから変数タイプを選択します。
変数が変数リストに追加されます。
Assignアクティビティのヘッダーに値を割り当てます。
呼出し操作を編集します。
「ヘッダー」タブをクリックし、作成した変数を選択します。これにより、操作が呼び出されたときに、選択した変数がSOAPヘッダーに追加されます。
「適用」と「OK」をクリックします。
SOAコンポジットの準備ができたら、構築とデプロイを行うことができます。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。
ターゲットWebサービス操作が呼び出されると、構成した変数がSOAPヘッダーの一部となります。
この手順は、ターゲット・システムがSSL.を介してWebサービスを公開している場合にのみ実行できます。SSL証明書をインポートするには、次のようにします。
Webサービスを公開しているターゲット・システムのWebサイトからSSL証明書をダウンロードします。
Oracle WebLogic Server管理コンソールにログインします。
「ドメイン構造」で、「環境」を開きます(その横にある+をクリックします)。次に、「サーバー」をクリックします。
SOA管理対象サーバー名をクリックします。たとえば、soa_server1などです。
「キーストア」タブに切り替えます。
このページには、サーバーに関連付けられている様々なキーストアがリストされます。
keytool(キーと証明書の管理ユーティリティ)を使用して、このページにリストされているすべてのキーストアにSSL証明書をインポートします。
たとえば、Demo Trust Keystoreに証明書をインポートするには、サーバーをホストしているコンピュータから次のコマンドを実行します。
keytool -keystore <MW_HOME>/server/server/lib/DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase -import -file acme-cert.cer
同様に、リストされているその他のキーストアに証明書をインポートします。
Oracle WebLogic ServerとSOAサーバーを再起動します。
|
注意: この項では、属性という用語はユーザー・データを格納するIDデータ・フィールドを指します。カスタム属性を追加するには、対応する属性がターゲット・システムに存在することを確認する必要があります。存在しない場合、最初にカスタム属性をターゲット・システムに追加する必要があります。ターゲット・システムへのカスタム属性の追加に関する詳細は、管理者に問い合せてください。 |
プロビジョニング用のカスタム属性を追加するには、Oracle Identity ManagerとSOAコンポジットで構成します。これらの手順について、次の各項で説明します。
デフォルトでは、第1.7項「プロビジョニング時に使用されるコネクタ・オブジェクト」で示した属性が、Oracle Identity Managerとターゲット・システム間のプロビジョニング用にマップされます。カスタム属性またはコネクタで即時利用可能(OOTB)ではない他のユーザー属性を追加した後、必要に応じてプロビジョニング用のコネクタを構成することもできます。たとえば、CountryNameがターゲット・システムのユーザー・プロファイルに追加されたカスタム属性である場合、次の手順を実行してコネクタを構成して、この属性をプロビジョニングできます。
カスタム属性CountryNameの場合、ACME WSDLの対応する属性名を決定します。
Oracle Identity Manager Design Consoleにログインします。
Oracle Identity Managerリリース11.1.2.xを使用している場合、Oracle Identity System Administrationにログインし、http://docs.oracle.com/cd/E27559_01/admin.1112/e27149/form.htm#CACGHJIFで説明されている手順を実行します。
次のようにして、新しいバージョンのプロセス・フォームを作成します。
「開発ツール」を開きます。
「フォーム・デザイナ」をダブルクリックします。
UD_ACME_USRプロセス・フォームを検索して開きます。
「新しいバージョンの作成」をクリックします。
新規バージョンの作成ダイアログ・ボックスで、「ラベル」フィールドに新しいバージョンを入力し、「保存」をクリックします。
次のようにして、プロセス・フォームに新しいフィールドを追加します。
「追加」をクリックします。
リストにフィールドが追加されます。フィールドの詳細を入力します。
たとえば、CountryNameフィールドを追加する場合、「名前」フィールドにUD_ACME_USR_COUNTRYNAME、ラベル名フィールドにCountryNameと入力し、このフィールドの残りの詳細に入力します。
フィールドがLookupFieldタイプの場合、新しい参照定義(Lookup.ACME.CountryNameなど)を作成します。次に、適切なエントリを参照定義に追加します。
UD_ACME_USRプロセス・フォームを開き、「プロパティ」をクリックします。新たに追加したプロパティを選択し、プロパティの追加をクリックします。「参照コード」として「プロパティ名」を選択し、プロパティ値として新たに作成した参照Lookup.ACME.CountryNameを入力します。
「保存」をクリックします。
新規作成したフォームをアクティブ化するには、バージョンのアクティブ化をクリックします。
プロビジョニングの参照定義で、次のようにして、フィールドのエントリを作成します。
「管理」を開きます。
「参照定義」をダブルクリックします。
Lookup.ACME.UM.ProvAttrMap参照定義を検索して開きます。
「Add」をクリックし、フィールドのコード・キー値とデコード値を入力します。
コード・キー値は、フォーム・フィールドのラベル名にする必要があります。SOAコンポジットでマッピングが完了しているため、デコード値はコード・キー値と同じにすることができます。
たとえば、コード・キーおよびデコードフィールドにCountryNameと入力します。この属性がProvisioning Attribute Mapおよびプロセス・フォームに追加されると、属性がOracle Identity Managerアプリケーション・インスタンス・フォームに表示され、Oracle Identity Managerから入力値を提供できるようになります。
「保存」をクリックします。
Oracle Identity Managerリリース11.1.2.x以降を使用している場合は、新しいUIフォームを作成してこれをアプリケーション・インスタンスに添付し、この新しい属性を表示します。手順については、第3.2.1.2項「新規UIフォームの作成」および第3.2.1.6項「新規フォームによる既存アプリケーション・インスタンスの更新」を参照してください。
作成などの操作のために、SOAコンポジットにカスタム属性を追加できます。カスタム属性は、ペイロードの<otherAttributes>タグに渡されます。カスタム属性は、Lookup.ACME.UM.ProvAttrMap参照定義のデコード値CountryNameにすることができます。これを行うには、次のようにします。
Assignアクティビティで、userAccountの下にあるotherAttributesを開き、ターゲット属性に値をマップします。
「送信元XPath」フィールドを編集し、/valueの前に[name = 'CountryName']を追加します。
割当てを保存します。
青色の割当ての線が「送信元」リージョンのuserAccountに移動します。
プロジェクトを保存します。
プロジェクトをコンパイルしてデプロイできます。Enterprise Managerから操作をテストします。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。
更新操作用のカスタム属性を追加するには、次のようにします。これを行うには、次のようにします。
|
注意: 作成操作ができるように、Oracle Identity Managerのプロセス・フォームにフィールドが追加され、Lookup.ACME.UM.ProvAttrMapにエントリが追加されたことを確認します。 |
Design Consoleで、FIELD_NAME Updatedプロセス・タスクを追加します。
たとえば、カスタム・フィールドがLocationである場合、Location Updatedタスクを追加します。
adpACMEUPDATEATTRIBUTEVALUEアダプタを追加し、FirstName Updatedなどの既存のタスクに類似した統合を完了します。
SOAコンポジットで、udpatedAttributeの下にある「name」を「if」コンストラクトに、「value」をターゲット変数にマップします。
ソースに切り替えます。次に、サンプル・ソースを示します。
<xsl:if test="/types:update/updatedAttribute/name">
<firstName>
<xsl:value-of select="/types:update/updatedAttribute/value"/>
</firstName>
</xsl:if>
Lookup.ACME.UM.ProvAttrMap参照定義のコネクタ・フィールドのデコード値を確認します。
サンプルの属性名first nameの場合、デコード値はFirstNameです。
次のようにソースを変更します。
<xsl:if test='/types:update/updatedAttribute/name = "FirstName"'> <firstName> <xsl:value-of select="/types:update/updatedAttribute/updatedAttribute[name = 'FirstName']/value"/> </firstName> </xsl:if>
プロジェクトを保存します。
プロジェクトをコンパイルしてデプロイできます。Enterprise Managerから操作をテストします。詳細は、第2.5項「WebサービスSOAコンポジットのデプロイとテスト」を参照してください。
リコンシリエーション用のカスタム属性を追加するには、Oracle Identity ManagerとSOAコンポジットで構成します。これらの手順について、次の各項で説明します。
Oracle Identity ManagerでCountry Nameなどのカスタム属性を追加するには、次のようにします。
|
注意: プロビジョニングのための属性をすでに追加している場合、その手順の一部として実行した手順を繰り返す必要はありません。 |
Design Consoleで、Lookup.ACME.UM.ReconAttrMap参照定義を検索して開きます。
カスタム属性の新しいエントリを追加します。
リソース・オブジェクトのリコンシリエーション・フィールドのリストにカスタム・フィールドを追加します。次に、リコンシリエーション・プロファイルの作成をクリックします。
プロセス・フォームにカスタム・フィールドを追加します。
プロビジョニング・プロセスで、カスタム・フィールドのリコンシリエーション・フィールド・マッピングを作成します。
検索などの操作のために、SOAコンポジットにカスタム属性を追加できます。SearchOutputTransform.xslに示されているように、カスタム属性はペイロードの<otherAttributes>タグに渡されます。
この手順を実行するには、次のようにします。
otherAttributesの下にある「value」フィールドにカスタム属性をマップします。
otherAttributesの下にある「name」フィールドは、Lookup.ACME.UM.ReconAttrMap参照の属性のデコード値に設定する必要があります。
「name」を右クリックし、「テキストの設定」、「テキストの入力」の順にクリックします。
参照定義で定義したとおりにカスタム属性のデコード値を入力します。
「ソース」タブに切り替えて、otherAttributesのXSL変換コードを表示します。
otherAttributeタグは必要なだけ追加できます。タグを追加するとデザイン・ビューでエラーが表示されることがありますが、これらは無視できます。XSLT構文が正しければ、プロジェクトをデプロイしてテストできます。
|
注意: この項で説明されている手順は、ターゲット・システムのnameおよびUidフィールドに同じ値が格納されていない場合にのみ実行してください。 |
Uidフィールドのカスタマイズには、コンポジットのotherAttributes属性を構成し、それをLookup.ACME.UM.ReconAttrMap参照定義のUnique Idフィールドに割り当てることが含まれます。
これを行うには、UserInvokeSearchの後のTransformで、次の手順を実行します。
検索ブランチ変換を開き、次のようにUidフィールドをotherAttributes属性にマップします。
otherAttributes属性を検索して開き、「name」属性を右クリックします。
表示されるコンテキスト・メニューで、「テキストの設定」、「テキストの入力」の順に選択します。
「テキストの設定」ダイアログ・ボックスで「テキスト」を選択し、テキスト・フィールドにuidと入力し、「OK」をクリックします。
UserSearchTransformタブで、ターゲットUidフィールドをotherAttributesの属性値にマップします。
コンポジットを保存してコンパイルし、SOAサーバーにデプロイします。
Enterprise Managerから操作をテストして検索し、レスポンス・ペイロードを確認します。
ログインはloginフィールドに移入され、UidはotherAttributes属性でuidとして設定されます。
次のようにLookup.ACME.UM.ReconAttrMap参照定義を更新します。
Design Consoleにログインします。
「Administration」を開き、「Lookup Definition」をダブルクリックします。
Lookup.ACME.UM.ReconAttrMap参照定義を検索して開きます。
Unique Idコード・キーを検索して、デコード値をuidに更新します。
「保存」をクリックします。
Target User Reconciliationスケジュール済ジョブを実行します。このスケジュール済ジョブの詳細は、第4.2.2項「リコンシリエーション用のスケジュール済タスク」を参照してください。
リコンシリエーションが正常に実行されると、一意のID値がカスタム属性にマップされます。最新のイベントIDを開くと、「イベント管理」リージョンでこのマッピングを確認できます。
カスタム子フォームを追加するには、Oracle Identity ManagerとSOAコンポジットで構成します。これらの手順について、次の各項で説明します。
Oracle Identity ManagerでMailing Listなどのフィールドにカスタム子フォームを追加するには、次のようにします。
フォーム・デザイナで、Mailing Listフィールドの子フォームを作成します。
新しいバージョンの親フォームを作成し、それに子フォームを追加します。次に、新しいバージョンの親フォームをアクティブにします
Mailing List Insert、Mailing List UpdateおよびMailing List Deleteにプロセス・タスクを追加します。これらのプロセス・タスクは、子フォームの挿入、更新および削除タスクに似ています。
Lookup.ACME.UM.ProvAttrMap参照定義にエントリを追加します。
コード・キー: CHILD_TABLE~FIELD_LABEL
デコード: RELEVANT_STRING_VALUE
たとえば、コード・キー値はUD_ACME_CH2~Mailing List、デコード値はMailingListとなります。
|
注意: 複雑な子表の場合、デコード値はAttributeName~ObjectClass~TargetFieldNameになりますSOAコンポジットのComplexMultiAttributesに示されているように、AttributeNameおよびObjectClass属性の値を指定する必要があります。 |
ACME Webserviceでは、様々な複数値属性(子フォーム属性)に様々な操作(AddRoleやAddMailingList操作など)があります。
SOAコンポジットでMailing Listなどのフィールドにカスタム子フォームを追加するには、次のようにします。
SwitchアクティビティをUpdateAddAttributeValues OnMessageにドロップします。ソース・ビューでそれを非コメント化します(すでにコメント化されている場合)。
条件ボックスをダブルクリックして、切替え条件の編集ウィンドウを表示します。名前をRoleとして指定し、「式」リージョンの上にある「XPath式ビルダー」アイコンをクリックします。
「文字列関数」からcontainsを選択し、「式に挿入」をクリックします。
UpdateAddAttributeValuesOp_InputVariableの下で、最初の引数をattributeNameとして設定します。
2番目の引数をRoleとして設定し、ラベルをRoleとして設定します。
2番目の引数値は、Lookup.ACME.UM.ProvAttrMap lookupの最初の子表エントリのデコード値と同じです。
RoleブランチでAddRole操作を呼び出すために、Invokeアクティビティをドロップします。次に、otherwiseブランチでAddMailingList操作を呼び出すために、別のInvokeアクティビティをドロップします。
入力変数と出力変数を指定します。
Invokeアクティビティの前にAssignmentアクティビティを追加し、属性をターゲット操作属性にマップします。次に、UIDをReplyアクティビティの出力変数にマップします。
構成されたSOAコンポジットのサンプル・スクリーンショットを次に示します。
Role (複数値データまたは資格)などの子フォーム・データの追加と削除にはそれぞれ、UpdateAddAttributeValuesおよびUdpateRemoveAttributeValues操作が使用されます。
UpdateAddAttributeValuesのマッピングは次のとおりです。UdpateRemoveAttributeValuesのマッピングも同様です。
ターゲットがRole操作を別のWebサービスで公開している場合、ターゲットWebサービスによっては、新しいパートナ・リンクを作成する必要があります。
InvokeアクティビティをAddRoleなどのターゲット操作にドロップします。次に、入力変数と出力変数を指定します。
InvokeRoleAdアクティビティの前に、Assignアクティビティをドロップします。
Assignアクティビティで、UpdateAddAttributeValueOp_InputVariableの変数をRoleのInvokeアクティビティの入力変数にマップします。
ACME Web serviceの場合、最初の引数はUID、2番目の引数は属性名Roleです(複数の子表の場合、この値は変動します)。3番目の引数は属性値(Administratorなどの実際の役割名)です。
InvokeアクティビティとAddAttrValReplyアクティビティの間にAssignアクティビティをドロップします。次に、Invokeアクティビティの出力(UID)をResponse変数にマップします。
役割の追加でターゲットWebサービスがUIDを返さない場合、UdpateAddAttributeValues操作への入力呼出しで渡されるUIDとレスポンス変数の間でこの割当てが行われる場合があります。
同様の手順を行うことで、UdpateRemoveAttributeValues操作を使用するRemoveRole操作を構成できます。
コネクタのタイムスタンプ属性はlong型です。一部のターゲットWebサービスの属性については、型または形式が異なる場合があります。たとえば、Oracle CRM On Demandでは、変更された日付を増分リコンシリエーション属性として使用する場合、属性の型をlongに変更する必要があります。
タイムスタンプは最初、MM/dd/yyyyの書式の文字列です。Javaコードを記述して文字列をjava.sql.Timestamp書式に変換してから、getTime()メソッドを使用してlong型の値を導出することができます。
このJavaコードを使用して、SOAコンポジットで直接使用できるカスタムXPath関数を定義できます。この関数は、変更された日付を入力として受け取り、long型の出力を生成します。その後、この出力をタイムスタンプ属性にマップできます。
カスタム(ユーザー定義) XPath拡張関数を作成するには、Oracle Fusion Middleware Oracle SOA Suite開発者ガイドのユーザー定義XPath拡張関数の作成で説明されている手順を実行します。
DateStringをLong型に変換するカスタムXPath関数を定義するサンプルJavaコードを次に示します。
package org.webservices.conversion;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.List;
import oracle.fabric.common.xml.xpath.IXPathContext;
import oracle.fabric.common.xml.xpath.IXPathFunction;
public class ConvertDateStringToLong implements IXPathFunction {
public ConvertDateStringToLong() {
super();
}
public static Long convertDateStringToLong(String dateString) {
Date date = null;
SimpleDateFormat dateFormat = new SimpleDateFormat("MM/dd/yyyy HH:mm:ss");
try {
date = dateFormat.parse(dateString);
} catch (Exception e) {
e.printStackTrace();
}
long timeInLong = date.getTime();
return timeInLong;
}
public Object call(IXPathContext ixPathContext, List<?> list) {
return convertDateStringToLong((String)list.get(0));
}
}
|
注意: この手順は、ターゲット・システムの複数のインストールに対応するようにコネクタを構成する場合のみ実行します。 |
ターゲット・システムの複数のインストールに対してコネクタを構成する場合があります。次の例でこの要件について説明します。
Example Multinational Inc.の東京、ロンドンおよびニューヨークの事業所には、独自にターゲット・システムがインストールされています。最近、この会社では、Oracle Identity Managerをインストールし、これを構成してインストールされたすべてのターゲット・システムをリンクしようとしています。
このような例で示される要件に対応するには、ターゲット・システムの複数のインストールに対するコネクタを構成する必要があります。
ターゲット・システムの複数のインストールに対してコネクタを構成するには、次のようにします。
|
関連項目: この手順の各ステップを実行する方法の詳細は、Oracle Identity Managerのための『Oracle Fusion Middleware Oracle Identity Managerの管理』のコネクタのクローニングに関する項を参照してください |
各ターゲット・システム・インストールに対して1つのリソースを作成して構成します。
「IT Resources」フォームは「Resource Management」フォルダにあります。ITリソースは、コネクタのXMLファイルをインポートすると作成されます。このITリソースは、同じリソース・タイプの、残りのITリソース作成用のテンプレートとして使用できます。
各ターゲット・システム・インストールについてリコンシリエーションを構成します。手順については、4.2項「スケジュール済タスク」を参照してください。ITリソースの指定に使用される属性の変更と、ターゲット・システム・インストールを信頼できるソースとして設定するかどうかの指定のみが必要です。
必要であれば、ACME Webservice Userリソース・オブジェクトに対してリコンサイルされるフィールドを変更します。
管理およびユーザー・コンソールを使用してプロビジョニングを実行する場合、ユーザーのプロビジョニング先のターゲット・システム・インストールに対応するITリソースを指定できます。
Lookup.ACME.UM.ProvValidationsおよびLookup.ACME.UM.ReconValidations参照定義はそれぞれ、プロビジョニングおよびリコンシリエーション操作中に検証される単一値データを保持します。
たとえば、「名」属性からフェッチしたデータを検証して、そのデータに番号記号(#)が含まれていないことを確認します。また、プロセス・フォームの「名」フィールドに入力したデータを検証して、プロビジョニング操作中にターゲット・システムに番号記号(#)が送信されないようにします。
|
注意: Lookup.ACME.UM.ProvValidationsおよびLookup.ACME.UM.ReconValidations参照定義はオプションで、デフォルトでは存在しません。これらの参照をデコード値としてLookup.ACME.UM.Configuration参照定義に追加して、プロビジョニングおよびリコンシリエーション操作中に除外を有効にする必要があります。 |
データの検証を構成するには:
org.identityconnectors.acme.extension.ACMEValidator.などの完全修飾ドメイン名(FQDN)を持つJavaクラスで必須の検証ロジックを実装するコードを記述します。
この検証クラスには、検証メソッドを実装する必要があります。次のサンプル検証クラスは、「名」属性の値に番号記号(#)が含まれるかどうかを確認します。
package com.validationexample;
import java.util.HashMap;
public class MyValidator {
public boolean validate(HashMap hmUserDetails, HashMap hmEntitlementDetails, String sField) throws ConnectorException {
/* You must write code to validate attributes. Parent
* data values can be fetched by using hmUserDetails.get(field)
* For child data values, loop through the
* ArrayList/Vector fetched by hmEntitlementDetails.get("Child Table")
* Depending on the outcome of the validation operation,
* the code must return true or false.
*/
/*
* In this sample code, the value "false" is returned if the field
* contains the number sign (#). Otherwise, the value "true" is
* returned.
*/
boolean valid = true;
String sFirstName = (String) hmUserDetails.get(sField);
for (int i = 0; i < sFirstName.length(); i++) {
if (sFirstName.charAt(i) == '#') {
valid = false;
break;
}
}
return valid;
}
}
Design Consoleにログインします。
次のいずれかの新しい参照定義を作成します。
リコンシリエーション用のデータの検証を構成するには:
Lookup.ACME.UM.ReconValidations
プロビジョニング用のデータの検証を構成するには:
Lookup.ACME.UM.ProvValidations
コード・キー列で、検証するリソース・オブジェクト・フィールド名を入力します。たとえば、Aliasなどです。
デコード列で、クラス名を入力します。たとえば、org.identityconnectors.acme.extension.ACMEValidatorなどです。
参照定義に変更を保存します。
Lookup.ACME.UM.Configuration参照定義を検索して開きます。
コード・キー列で、次のエントリのいずれかを入力します。
リコンシリエーション用のデータの検証を構成するには:
Recon Validation Lookup
プロビジョニング用のデータの検証を構成するには:
Provisioning Validation Lookup
「Decode」列で、次のエントリのいずれかを入力します。
リコンシリエーション用のデータの検証を構成するには:
Lookup.ACME.UM.ReconValidations
プロビジョニング用のデータの検証を構成するには:
Lookup.ACME.UM.ProvValidations
参照定義に変更を保存します。
クラスを使用してJARを作成し、次のようにOracle Identity Managerデータベースにアップロードします。
Oracle Identity Manager JARアップロード・ユーティリティを実行して、JARファイルをOracle Identity Managerデータベースに投稿します。このユーティリティは、Oracle Identity Managerのインストール時に次の場所にコピーされます。
|
注意: このユーティリティを使用する前に、Oracle WebLogic ServerをインストールしたディレクトリにWL_HOME環境変数が設定されていることを確認してください。 |
Microsoft Windowsの場合:
OIM_HOME/server/bin/UploadJars.bat
UNIXの場合:
OIM_HOME/server/bin/UploadJars.sh
ユーティリティを実行すると、Oracle Identity Manager管理者のログイン資格証明、Oracle Identity Managerホスト・コンピュータのURL、コンテキスト・ファクトリ値、アップロードするJARファイルのタイプおよびJARファイルがアップロードされる場所の入力を求めるプロンプトが表示されます。JARタイプの値として1を選択します。
PurgeCacheユーティリティを実行して、サーバー・キャッシュからのデータセットのリクエストに関連するコンテンツをクリアします。
リコンシリエーションまたはプロビジョニングを実行して、Aliasなどのフィールドの検証を確認します。
Lookup.ACME.UM.ReconTransformations参照定義は、リコンシリエーション操作中に変換される単一値のユーザー・データを保持します。たとえば、「名」および「姓」値を使用して、Oracle Identity Managerの「氏名」フィールドの値を作成できます。
|
注意: Lookup.ACME.UM.ReconTransformations参照定義はオプションで、デフォルトでは存在しません。この参照をデコード値としてLookup.ACME.UM.Configuration参照定義に追加して、プロビジョニングおよびリコンシリエーション操作中に除外を有効にする必要があります。 |
リコンシリエーション中にフェッチした単一値のユーザー・データの変換を構成するには:
org.identityconnectors.acme.extension.ACMETransformationなどの完全修飾ドメイン名(FQDN)を持つJavaクラスで必須の変換ロジックを実装するコードを記述します。
この変換クラスは、変換メソッドを実装する必要があります。次のサンプル変換クラスは、ターゲット・システムの「名」および「姓」属性からフェッチした値を使用して、「氏名」属性の値を作成します。
package com.transformationexample;
import java.util.HashMap;
public class MyTransformer {
public Object transform(HashMap hmUserDetails, HashMap hmEntitlementDetails, String sField) throws ConnectorException {
/*
* You must write code to transform the attributes.
* Parent data attribute values can be fetched by
* using hmUserDetails.get("Field Name").
* To fetch child data values, loop through the
* ArrayList/Vector fetched by hmEntitlementDetails.get("Child Table")
* Return the transformed attribute.
*/
String sFirstName = (String) hmUserDetails.get("First Name");
String sLastName = (String) hmUserDetails.get("Last Name");
return sFirstName + "." + sLastName;
}
}
Design Consoleにログインします。
新しい参照定義Lookup.ACME.UM.ReconTransformationsを作成します。
コード・キー列に、変換するリソース・オブジェクト・フィールド名を入力します。たとえば、Aliasなどです。
デコード列で、クラス名を入力します。たとえば、org.identityconnectors.acme.extension.ACMETransformationなどです。
参照定義に変更を保存します。
Lookup.ACME.UM.Configuration参照定義を検索して開きます。
コード・キー列に、リコンシリエーション変換参照を入力します。
デコード列に、Lookup.ACME.UM.ReconTransformationsと入力します。
参照定義に変更を保存します。
クラスを使用してJARを作成し、次のようにOracle Identity Managerデータベースにアップロードします。
Oracle Identity Manager JARアップロード・ユーティリティを実行して、JARファイルをOracle Identity Managerデータベースに投稿します。このユーティリティは、Oracle Identity Managerのインストール時に次の場所にコピーされます。
|
注意: このユーティリティを使用する前に、Oracle WebLogic ServerをインストールしたディレクトリにWL_HOME環境変数が設定されていることを確認してください。 |
Microsoft Windowsの場合:
OIM_HOME/server/bin/UploadJars.bat
UNIXの場合:
OIM_HOME/server/bin/UploadJars.sh
ユーティリティを実行すると、Oracle Identity Manager管理者のログイン資格証明、Oracle Identity Managerホスト・コンピュータのURL、コンテキスト・ファクトリ値、アップロードするJARファイルのタイプおよびJARファイルがアップロードされる場所の入力を求めるプロンプトが表示されます。JARタイプの値として1を選択します。
PurgeCacheユーティリティを実行して、サーバー・キャッシュからのデータセットのリクエストに関連するコンテンツをクリアします。
リコンシリエーションを実行して、Aliasなどのフィールドの変換を検証します。
Lookup.ACME.UM.ProvExclusionListおよびLookup.ACME.UM.ReconExclusionList参照定義はそれぞれ、プロビジョニングおよびリコンシリエーション操作を実行しないターゲット・システム・アカウントのユーザーIDを保持します。
|
注意: Lookup.ACME.UM.ProvExclusionListおよびLookup.ACME.UM.ReconExclusionList参照定義はオプションで、デフォルトでは存在しません。これらの参照をデコード値としてLookup.ACME.UM.Configuration参照定義に追加して、プロビジョニングおよびリコンシリエーション操作中に除外を有効にする必要があります。 |
これらの参照に格納されている値の形式は次のとおりです。
| コード・キー | デコード | サンプル値 |
|---|---|---|
| ユーザー・ログインIDリソース・オブジェクト・フィールド名 | ユーザーのUser ID | コード・キー: ユーザー・ログインID
デコード: User001 |
| [PATTERN]接尾辞を持つユーザー・ログインIDリソース・オブジェクト・フィールド名 | java.util.regex.Patternクラスの表現によってサポートされる正規表現 |
コード・キー: ユーザー・ログインID[PATTERN]
ユーザーID User001、User002、User088のいずれかに一致するユーザーを除外するには: デコード: User001|User002|User088 ユーザーIDが00012で始まるユーザーを除外するには: デコード: 00012* 関連項目: サポートされるパターンの詳細は、 |
プロビジョニング操作中に除外する参照にエントリを追加するには:
Design Consoleで、「Administration」を開き、「Lookup Definition」をダブルクリックします。
新しい参照定義Lookup.ACME.UM.ProvExclusionListを作成します。
|
注意: リコンシリエーション操作中に除外するユーザーIDを指定するには、Lookup.ACME.UM.ReconExclusionListという新しい参照定義を作成して、その参照にエントリを追加します。 |
「追加」をクリックします。
コード・キーおよびデコード列に、除外する1つ目のユーザーIDを入力します。
|
注意: コード・キーはプロビジョニング操作中に適用される除外リストのリソース・オブジェクト・フィールド名を表します。 |
除外する残りのユーザーIDに手順3および4を繰り返します。
たとえば、ユーザーIDがUser001、User002およびUser088のユーザーをプロビジョニングしない場合、参照定義に次の値を移入します。
| コード・キー | デコード |
|---|---|
| ユーザー・ログインID | User001 |
| ユーザー・ログインID | User002 |
| ユーザー・ログインID | User088 |
また、パターン一致を実行して、ユーザー・アカウントを除外することもできます。java.util.regex.Patternクラスの表現によってサポートされる正規表現を指定できます。
|
関連項目: サポートされるパターンの詳細は、http://download.oracle.com/javase/6/docs/api/java/util/regex/Pattern.htmlを参照してください。 |
たとえば、ユーザーIDがUser001、User002およびUser088に一致するユーザーをプロビジョニングしない場合、参照定義に次の値を移入します。
| コード・キー | デコード |
|---|---|
| ユーザー・ログインID[PATTERN] | User001|User002|User088 |
ユーザーIDが00012から始まるユーザーをプロビジョニングしない場合は、次の値で参照定義を移入します。
| コード・キー | デコード |
|---|---|
| ユーザー・ログインID[PATTERN] | 00012* |
「保存」をクリックします。
第2.3.7項「検索操作の構成」で説明されている構成手順を実行すると、次のように子表を複数の属性にマップできます。
検索操作用に作成された変換マッピングを開きます。
|
注意: 作成された変換マッピングの複雑な子表をそれぞれ管理するために、complexMultiAttributesが使用されます。 |
Userフィールドに必要なマッピングを作成します。その後、複雑な子表をマップする必要があります。これを行うには、次の手順を実行します。
「for each」ループを追加して、子表の値に対して手順を繰り返します。
たとえば、この場合、Userの「Role」属性ごとに、連続して手順を繰り返す必要があります。各attributeValueは1つのRoleを表します。また、「for each」ループを使用して、各「Role」に対して手順が連続的に繰り返されます。
「for each」ループを追加して各子表エントリの値に対して手順を繰り返し、それをcomplexAttributeValuesの名前と値にマップします。
たとえば、この場合、各「Role」属性のroleName、roleStartDate、roleEndDateおよびprimaryに対して、連続して手順を繰り返す必要があります。Roleの各属性は、nameとvalueのペアで表されます。
たとえば、name変数は「RoleName」、value変数は「Developer」を持つことになります。同様に、Roleのその他の属性(RoleStartDate、RoleEndDate、primaryなど)も、nameとvalueのペアで表されます。
子表の各属性の繰り返しは、次のコードを使用して行われます。このコードは「for-loop」内に置かれ、各「Role」属性に対して手順を繰り返します。
<xsl:for-each select="node()">
<xsl:if test='(name() = "roleName") or ((name() = "roleStartDate") or ((name() = "roleEndDate") or (name() = "primary")))'>
<complexAttributeValues>
<name>
<xsl:value-of select="name()"/>
</name>
<value>
<xsl:value-of select="node()"/>
</value>
</complexAttributeValues>
</xsl:if>
</xsl:for-each>
前述の手順が完了したら、Oracle Identity Managerで次の手順を実行する必要があります。
Design Consoleにログインします。
次のようにして、複数の属性を持つ新しい子表を作成します。
第5.4.1項「Oracle Identity Managerでのカスタム子フォームの追加」に示されている手順に従って、新しい子表を作成します。
子表のすべての属性を追加の列に追加します。
たとえば、Roleの子表を作成した場合、新たに作成した子表に次の属性を追加する必要があります。
RoleName
RoleStartDate
RoleEndDate
Primary
下に示すように、「プロパティ」タブでプロパティの追加をクリックし、属性の必須プロパティを追加します。
「Save」、「Make Version Active」を順にクリックします。
新しいバージョンの親フォームを作成し、それに子フォームを追加します。これが完了したら、バージョンのアクティブ化をクリックして、新しいバージョンの親フォームをアクティブにします。
リソース・オブジェクトのリコンシリエーション属性のリストに、次のようにして、新しい属性を追加します。
「リソース管理」,を展開し、「リソース・オブジェクト」をダブルクリックします。
この手順で使用されている例に従って、SampleWS Userリソース・オブジェクトを検索して開きます。
「Object Reconciliation」タブで、「Add Field」をクリックします。
フィールドの詳細を入力します。
たとえば、「フィールド名」フィールドにRoleと入力し、フィールド・タイプ・リストから複数値属性を選択します。
「Save」をクリックして、ダイアログ・ボックスを閉じます。
新規作成したフィールドを右クリックして、「Define Property Fields」を選択します。
「Add Reconciliation Fields」ダイアログ・ボックスに、新規作成したフィールドの詳細を入力します。
たとえば、「フィールド名」フィールドにRoleNameと入力し、フィールド・タイプ・リストから「文字列」を選択します。
次の違いを除き、子表のすべての属性に対して手順gを繰り返します。
「フィールド名」フィールドにRoleStartDateと入力し、フィールド・タイプ・リストから「文字列」を選択します。
「フィールド名」フィールドにRoleEndDateと入力し、フィールド・タイプ・リストから「文字列」を選択します。
「フィールド名」フィールドにPrimaryと入力し、フィールド・タイプ・リストから「文字列」を選択します。
「保存」をクリックし、新しい属性に詳細を入力するたびに、繰り返しダイアログ・ボックスを閉じます。
次のようにして、新しい属性用のリコンシリエーション・フィールド・マッピングをプロセス定義に作成します。
「プロセス管理」を開き、「プロセス定義」をダブルクリックします。
この手順で使用されている例に従って、SampleWS Userプロセス定義を検索して開きます。
プロセス定義フォームのリコンシリエーション・フィールド・マッピング・タブで、フィールド・マッピングの追加をクリックします。
リコンシリエーション表マッピングの追加ダイアログ・ボックスで、表示されたリストからフィールド名および表名を選択します。
「Save」をクリックして、ダイアログ・ボックスを閉じます。
次のスクリーンショットは、SampleWS Userリコンシリエーション・マッピングへのフィールド名Roleの追加を示しています。
新規作成したフィールドを右クリックして、「Define Property Field Map」を選択します。
「Field Name」フィールドで、追加するフィールドの値を選択します。
次のスクリーンショットは、子表RoleのRoleNameフィールドの追加を示しています。
RoleStartDate、RoleEndDateおよびPrimaryの各フィールドに対して、手順fおよびgを繰り返します。
リコンシリエーションの参照定義で、次のようにして、フィールドのエントリを作成します。
「管理」を開きます。
「参照定義」をダブルクリックします。
「Add」をクリックし、フィールドのコード・キー値とデコード値を入力します。コード・キーとデコードの値は次の形式にする必要があります。
コード・キー: MULTIVALUED_FIELD_NAME~CHILD_RESOURCE_OBJECT_FIELD_NAME
デコード: AttributeName~ObjectClass~TargetFieldName
|
注意: SOAコンポジットのComplexMultiAttributesの下にあるAttributeNameおよびObjectClassに示されているとおり、AttributeNameおよびObjectClassの値を指定します。 |
「保存」をクリックします。
子表のすべての属性に対して手順cおよびdを繰り返します。
下のスクリーンショットは、すべてのマッピングが完了した時点のSampleWS UserのReconciliation Attribute Mapを示しています。
