※本記事は、Paul Toal による “Managing Users in Identity Cloud Service – Part 2” を翻訳したものです。

2021年 8月 2日

 

前回の記事では、Oracle Identity Cloud Service（IDCS）内でユーザー管理を自動化するためのさまざまなオプションについて説明しましたが、よくあるユースケースの1つについては取り上げませんでした。それはOracle Fusion CloudアプリケーションからのIDの同期方法についてです。このユースケース自体に多数のオプションがあり、それぞれ特有の考慮事項があるため、改めて説明の機会を設けるのが良いと考えたからです。そこで、このパート2ではOracle Fusion Cloudに焦点を当てようと思います。

人材管理（HCM）システムは、通常、組織内でユーザーのレコードが始まる場所であるため、データの発生源として一般的です。そのため、このシステムからID管理（IDM）プラットフォームにデータを入力すると合理的です。

事前にFusion内に存在する各レコードについて（IDMの視点から）理解し、要件に基づいて必要なレコードは何かを明らかにすることが重要になります。本記事では説明用に、workerとuserという2種類のレコードについて取り上げます。

Fusionにログインするには、userレコードが必要です。ユーザー名とパスワードが含まれるこのレコードは、FusionのIAMプラットフォームに保存されます。userレコードがなければFusionにアクセスできません。これに対して、workerレコードについては、従業員（あるいは請負業者など）を表すレコードとして考えます。人を雇用すると、workerレコードが作成されます。このレコードに、住所、銀行口座詳細、等級、部門、勤務地など、その人についてHCMで得られる全情報が格納されます。userレコードとworkerレコードの関係については、同僚のOlaf Heimburgerがこちらの記事でわかりやすく説明しています。Olafは本記事で、私がFusionに関する正しい知識に基づいて説明できるようサポートしてくれました。

workerレコードとuserレコードには異なる情報が格納されるため、これらのレコードの違いは重要です。workerは完全に人事管理（HR）のためのレコードである一方、userレコードはFusionへの認証済みアクセスができるようにするためのスケルトン・レコードに過ぎません。同期オプションについて検討する際には、この点を覚えておく必要があります。オプションは基本的に3つあり、以下の図にまとめています。

それぞれのオプションについて確認しましょう。

 

1 – プッシュ

1つ目のオプションは、Fusionで標準提供されているEnterprise Scheduler Service（ESS）の同期ジョブを使用するものです。このジョブでIDCSに必要な詳細情報を提供するためには、いくつか基本的な構成を行う必要があります。そうすれば後はその名のとおり、スケジュールに基づいて、ユーザーをロールやロール・メンバーシップとともにFusionからIDCSへ同期してくれます。
この方法で特に注意すべき事柄の1つが、このジョブはFusionのuser APIから同期を行うため、userスケルトン・レコードにしかアクセスできないということです。つまり、同期されるのは以下のユーザー属性だけということになります。

  • ユーザー名
  • 名
  • 姓
  • 電子メール・アドレス
  • アクティブ・ステータス

しかも、このESSジョブ内ではユーザー・フィルタを利用できません。アクティブで、電子メール・アドレスがあり、Person構造を持つすべてのユーザーがFusionからIDCSへ同期されます。ただし、選択したロールとロール・メンバーシップのみをIDCSに同期するためのロール用フィルタは用意されています。

ESS同期ジョブを使用するメリットの1つは、ロールに接頭辞を付ける機能があることです。例として、1つのIDCSインスタンスで、2つのFusionインスタンスから、ロールとロール・メンバーシップの情報を同期しているとします。Fusionインスタンス名はPRODとTESTです。この両方にロールPayablesManagerが含まれている場合、どちらかでこのロールのメンバーシップが更新されるたびに、IDCSのPayablesManagerロールが上書きされることになります。この状況を回避するために、ロールの接頭辞付加機能を使用して、IDCSに同期される各ロールの先頭に値を追加することができます。つまり、PROD Fusion環境ではロールにPROD_という接頭辞を付け、TEST Fusion環境ではTEST_という接頭辞を付けるように構成できます。これで、1つのIDCSインスタンス内にPROD_PayablesManagerのロールとTEST_PayablesManagerのロールが存在することになり、各ロールのメンバーシップはそれぞれの環境から得た正しいものになります。

 

2- プル

2つ目のオプションは、IDCSアプリケーション・カタログの事前定義済みFusionアプリケーション・テンプレートを使用するというものです。この方法では、ユーザー、ロール、ロール・メンバーシップをIDCSにプルするために権限付き同期を使用して、IDCSでIDレコードの作成または更新のいずれかを行います。

アプリケーション・テンプレートもFusionのuser APIを使用するため、同期されるのはuserスケルトン・レコードのみです。

このプルの手法のおもなメリットは、フィルタがサポートされることです。設定時に、同期の対象とするFusionロール・サブセットを指定できます。指定したロールのメンバーであるユーザーのみがIDCSにプルされます。

 

3 – API

これまでの2つのオプションではいずれも、FusionのID情報がuser APIから取得されていました。すでに説明したとおり、このAPIはuserスケルトン・レコードを提示するだけで、Fusion内にあるworkerレコード全体にアクセスすることはできません。多くのユースケースでは、IDCS内でuserリストとそのFusionロールにアクセスできれば十分であり、他のIDCS連携アプリケーションにそれらを割り当てることができます。しかし、workerレコードの他の情報がIDCS内で必要になるようなユースケースもあります。

私が最近関わったユースケースでは、workerの個人用電子メール・アドレスを取得して、それをIDCS内の電子メール・アドレスとして使用する必要がありました。Fusion内では個人用電子メール・アドレスはuser API経由では閲覧できないため、オプション1、2のいずれも実現不可能でした。
幸い、Fusionはworker APIを公開しており、このAPIを使用すれば、必要なすべての属性をworkerレコードから抽出できます。そのため、任意の連携ツールを使用してFusionのworker APIからデータをプルして、REST API経由でIDCSに入力することができます。

たとえば、Oracle Integration Cloudを使用すれば簡単にこれを実行できるでしょう。以下にサンプルの手順を示します。

1. Fusionのworkerレコードの変更内容（新規雇用イベント、従業員情報の更新、退職など）が、worker APIを使用して取得されます。このジョブはスケジュールが設定されており、前回の実行日時以降のすべての変更内容が取得されます。

2. 次に、それらの変更内容が変換され、REST APIを使用してIDCSに伝播されます。IDCS内でユーザーが存在するかどうかの検索が実行され、存在しない場合はユーザーが作成されます。

以下に各オプションの概要を示します。

FusionからIDCSへのユーザーやロールの同期には正しい方法や間違った方法というものはありません。それぞれの手法にそれ特有の考慮事項があるため、ユースケースと要件を検討することで、使用すべき手法について判断を促すことができます。詳しくは、Oracle Identity Cloud Serviceのドキュメントを参照してください。 

IDCSについてはこちらのドキュメントで詳細をご覧いただけます。

 

Paul Toal
OCI Security Specialist Senior Director

Paulはセキュリティに20年以上携わり、現在はEMEA OCI Center of Excellenceセキュリティ部門のリーダーを務めています。Oracle Cloudの普及に取り組みながら、エンジニアリング・チームと緊密に連携して、お客様からのフィードバックを伝達し、新しいサービスの創出にも貢献しています。取締役からアーキテクトや開発者までの組織内のあらゆる階層で、リスク削減とデジタル・トランスフォーメーションの両方を目指したセキュリティの利用方法について説明し、実践しています。最近では、ソリューションのリード・セキュリティ・アーキテクトとして複数の大規模デジタル・トランスフォーメーション・プログラムに関わりました。

英国政府のアイデンティティ保証仕様（Gov.UK Verify）の原本著者の1人であり、この分野のイノベーションとソート・リーダーシップを常に先導しています。