Anything-as-a-Sourceを使用する

Anything-as-a-Source（XaaS）を使用すると、信頼できるあらゆる情報源をOktaに統合して、信頼できる情報源を基にしたHR主導のプロビジョニングのメリットを実現できます。XaaSでは、Oktaと信頼できる情報源間の同期条件を柔軟に定義できます。また、一部のIDはOktaでの表記を必要とせず、XaaSは無関係のデータを除去して適切なIDのみを同期できます。

前提条件

  • Oktaプロファイルソーシング機能を利用できること。
  • 公開API、レポート、ファイル出力、あるいはその他の機構によってデータを抽出できる信頼できる情報源。
  • XaaS機能に関連するAPI呼び出しを行うAPIクライアント。このクライアントは、自動化プラットフォーム（Okta Workflowsなど）またはユーザー独自のカスタムホストされたコードの場合があります。

  • APIクライアントが、Okta APIを呼び出す権限を付与されていること。これは、 OAuth 2.0サービスアプリをセットアップする（または Okta Workflowsに統合されたOAuth 2.0クライアントを使用する）ことで実現できます。

  • Okta Workflowsを使用する場合は、Okta Workflowsプラットフォームを利用できること。
  • orgでアイデンティティソースアプリ機能が有効化されている必要があります。この機能を有効にするには、Oktaアカウントチームまでお問い合わせください。

XaaS統合を構築する

XaaS統合の構築には、次の手順が含まれます。

  1. カスタムIDソースを作成して構成する。
  2. カスタムIDソースを使用してデータを同期する。

カスタムIDソースを作成して構成する

信頼できる情報源から得たデータを同期する前に、まずは以下の手順に従ってOkta orgに統合を作成する必要があります。

  1. Admin Consoleで、［Applications（アプリケーション）］［Applications（アプリケーション）］に移動します。

  2. ［Browse App Catalog（アプリカタログを参照）］をクリックします。
  3. ［Custom Identity Source（カスタムIDソース）］」を検索して選択し、［Add Integration（統合を追加）］をクリックします。
  4. 任意。新しい統合の名前を指定し、アプリをユーザーに表示するかどうかを指定します。
  5. ［Done（完了）］をクリックします。
  6. ［Provisioning（プロビジョニング）］タブに移動します。
  7. ［Settings（設定）］で［Integration（統合）］を選択します。
  8. ［Configure API Integration（API統合を構成）］をクリックし、［Enable API Integration（API統合を有効化）］を選択します。
  9. ［設定］で［To Okta（Oktaへ）］を選択します。

    この統合タイプでは［アプリへ］プロビジョニングはサポートされていないため、これらの設定は無視されます。

  10. 統合を構成します。例：
  • 新規ユーザーの確認を手動で行うかOktaが自動で行うかを構成する
  • 新規ユーザーと既存ユーザーが一致しているかどうかをOktaが判断する方法と、それを手動と自動のどちらで行うかを構成する
  • この統合をOktaのプロファイルソースとして指定する

インスタンスに関するURLのアイデンティティソースID（${identitySourceId}で参照されます）を検索できます。このIDについてはソースを構成する必要があり、次のURLではそれが強調されています。

カスタムIDソースの属性をマッピングする

統合のスキーマに属性を追加し、カスタムIDソースからOktaに送信されるデータを指定します。

  1. Admin Consoleで、［Directory（ディレクトリ）］［Profile Editor（プロファイルエディター）］に移動します。

  2. 任意。左側の［Filters（フィルター）］セクションで、［Apps（アプリ）］を選択します。
  3. 統合のリストからカスタムIDソースを見つけて選択します。
  4. （たとえば、Oktaプロファイルに含めたり、プロファイルマッピングで使用したりするために）Oktaに同期する必要がある属性ごとに、次の手順を実行します。
    1. ［Add Attribute（属性を追加）］をクリックします。
    2. stringを属性のデータタイプとして選択します。

      XaaSのIDソーススキーマはstring属性のみをサポートします。

    3. 新しい属性に関する表示名、変数名、（任意の）説明を入力します。Okta Expression Languageを受け付けます。
    4. 属性が必要かどうか、その範囲、または文字数制限など、関連するその他の制約を指定します。
    5. 追加する属性が他にもある場合、［Save and Add Another（保存してほかにも追加）］をクリックします。最後の属性を追加してから、［Save（保存）］をクリックします。
    6. ［プロファイルエディター］ページの［Mappings（マッピング）］タブに移動します。［Configure User Mappings（ユーザーマッピングを構成）］をクリックします。
  5. 左側のカスタムIDソース（appuser）属性から右側のOktaユーザーへのマッピングを作成します。

まだ必要な属性がOktaユーザーのプロファイルに追加されていない場合、「アプリ、ディレクトリ、IDプロバイダーにカスタム属性を追加する」を参照してください。

カスタムIDソースを使用してデータを同期する

これでIDソース統合がOkta組織に追加されたため、信頼できる情報源から得たデータをOktaに対して同期することができます。このセクションでは、情報源からデータを抽出した後にXaaS APIを使ってこの同期を実行する方法について説明します。

API呼び出しを使用して照合済みのユーザーを削除すると、Universal Directoryでユーザーを非アクティブ化できます。未照合のユーザーは、Universal Directoryに表示されません。

OAuth 2.0クライアントの作成

安全かつ標準的な認可を実現するには、専用のOAuth 2.0クライアントアプリを作成する必要があります。このアプリは、API呼び出しに必要なアクセストークンを取得するために使用されます。このクライアントの作成に関する詳細な手順については、「サービスアプリを使用してOkta向けOAuthを実装する」を参照してください。

APIクライアントとしてOkta Workflowsを使用する場合もOAuth 2.0構成を使用しますが、設定はWorkflows環境内で直接管理されます。具体的な認可手順については、「認可」を参照してください。

XaaSのカスタムクライアントを構築する

XaaS用のカスタムクライアントを構築する方法の詳細については、「Anything-as-a-Sourceカスタムクライアント統合を構築する」を参照してください。

Okta Workflows

OktaコネクターおよびCustom API Actionカードを使用することで、Okta Workflowsで任意のXaaS APIを呼び出すことができます（「Custom API Action（CAPIA）カード」を参照してください）。他の公開HTTPエンドポイントを呼び出すためにOkta Workflows APIコネクター（およびその他のコネクター）を使用できます。たとえば、データをHRシステムなど信頼できる情報源から直接取得するために、このコネクターを使用できます。

考慮事項

  • XaaSでは、インポートスケジュール、インポートセーフガード（アプリ単位またはOrg単位）、ユーザーインポートインラインフックが使用できません。

  • 一括インポートは、1セッションあたり最大1万ユーザー、グループ、またはメンバーシップに制限されています。

  • 一括インポートはバッチあたり200ユーザー、グループ、またはメンバーシップ単位で実行され、1つのインポートセッションで最大50件のPOSTリクエストが可能です。各リクエストのサイズは200 KBを超えないようにしてください。

  • アカウントの照合、リンク、プロファイルマッピングに関するAPIはありません。

  • 特定のセッションで同じユーザーを2回リスト追加すると、（競合状態やプロファイル競合など）データが不正確になる問題が生じます。

  • 空のプロファイルを送信すると空のユーザーが生成されますが、これはOktaが推奨しない操作です。

  • XaaSをOktaを使用する既存の統合（Workdayなど）に接続すると、データの正確性に問題が発生する可能性があるため、Oktaではサポートされていません。