ServiceNowによるプロビジョニングの承認

このガイドでは、Okta orgでServiceNowのプロビジョニングを構成する方法について説明します。

開始する前に

  • この手順ではServiceNowアプリのインスタンスがすでにOktaに追加され、SSOを設定済みであることを前提とします。「ServiceNow用SAML 2.0の構成方法」を参照してください。アプリケーションの追加に関する一般的な情報については、「既存のアプリ統合の追加」を参照してください。
  • Okta要件：

    1. Oktaの一般（General）タブの下で完全なベースURL（Base URL）が設定されていることを確認します。

    2. 次のタブでサインオン（Sign-On）オプションを構成します。

    3. 次へ（Next）をクリックしてプロビジョニング（Provisioning）タブに戻ります。

プロビジョニング機能

以下のプロビジョニング機能がプロビジョニングイベント用にサポートされます。

新規ユーザーをプッシュ Okta通して新規ユーザーが作成されると、サードパーティアプリケーションでも作成されます。
ユーザーの非アクティブ化をプッシュ Oktaを通してユーザーが非アクティブ化されるかアプリケーションへのアクセスが無効化されると、サードパーティアプリケーションでもそのユーザーは非アクティブ化されます。
プロファイルの更新をプッシュ Oktaを通してユーザーのプロファイルに加えられた変更がサードパーティアプリケーションプロファイルに適用されます。
新規ユーザーをインポート サードパーティアプリケーションで作成された新規ユーザーがインポートされ、既存のOktaユーザーとのマッチングのために新規AppUserオブジェクトに変換されます。
プロファイルの更新をインポート サードパーティ製アプリケーションのユーザープロファイルに行われた更新がダウンロードされ、Oktaでローカルに保存されたプロファイルのフィールドに適用されます。アプリが記録システムである場合、コアプロファイルフィールド（メール、名、姓など）に加えられた変更がOktaユーザープロファイルに適用されます。アプリがレコードシステムでない場合、アプリ固有のフィールドに加えられた変更のみがローカルユーザープロファイルに適用されます。
グループプッシュ グループとそのメンバーをリモートシステムにプッシュできます。グループプッシュ操作（グループプッシュの機能強化を含む）の使用については、グループプッシュを管理するを参照してください。
ユーザーの再アクティブ化 Oktaを通してユーザーを再度有効にすると、そのユーザーはサードパーティアプリケーションでも再アクティブ化されます。
パスワード同期 Oktaからサードパーティアプリケーションにユーザーパスワードをプッシュします。

手順

ServiceNowプロビジョニングの構成

  1. API統合を有効化（Enable API Integration）をオンにします。

  2. ServiceNow API資格情報を入力します。

    • 管理者ユーザー名（Admin User Name）：Organizationの管理者権限を持つServiceNowユーザー名を入力します。

    • 管理者パスワード（Admin Password）：管理者アカウントのパスワードを入力します。

    • API資格情報のテスト（Test API Credentials）をクリックして、資格情報を検証します。

  3. 保存（Save）をクリックします。

  4. 左パネルでアプリへ（To App）を選択し、次に有効化したいプロビジョニング機能（Provisioning Features）を選択します。

  5. これで、（必要に応じて）ユーザーをアプリに割り当て、アプリケーションのセットアップを完了することができます。

ServiceNowスキーマ検出を使用してユーザープロファイルの属性を追加する

ServiceNowはユーザーのスキーマ検出をサポートするため、ユーザーのプロファイルに他の属性を追加することができます。

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

  2. 左のナビゲーションペインからアプリ（APPS）セクションを選択し、リストから目的のアプリを見つけます。プロファイル（Profile）編集アイコンをクリックして、Profile Editorページを開きます。

  3. 属性のリストを確認し、さらに必要な場合は属性を追加（Add Attribute）をクリックします。拡張属性のリストが表示されます。

  4. 追加する属性を選択し、保存（Save）をクリックします。

  5. 追加された属性は、カスタム属性（Custom Attributes）のリストでページを更新した後でも存在するはずです。これらのユーザー属性値をServiceNowとの間でインポートおよびプッシュできるようになりました。

  6. これで、カスタム属性のマッピングを作成できます。

プロファイルマッピング

デフォルト属性

左側のナビゲーションペインのディレクトリ（Directory） > プロファイルエディター > アプリ（APPS）セクションでデフォルトの属性を確認し、リストでアプリを見つけることができます。

Active Directoryマッピング

変更不可能な特定のフィールド向けに事前定義されたADマッピングがあり、これはADがソースとして構成されている場合のみに使用されます。

マネージャー／アシスタント機能

以下に例を示します。詳しくは、Okta開発者用ドキュメントの「ディレクトリおよびWorkday機能」、および「よく使用される式」を参照してください。

関数

説明

例
getManagerUser(managerSource).$attribute

管理者のOktaユーザー属性値を取得します

 getManagerUser("active_directory").firstName
getManagerAppUser(managerSource, attributeSource).$attribute

任意のappinstanceのアプリユーザーに対する管理者のアプリユーザー属性値を取得します。

getManagerAppUser("active_directory", "google").firstName
getAssistantUser(assistantSource).$attribute

アシスタントのOktaユーザー属性値を取得します

 getAssistantUser("active_directory").firstName
getAssistantAppUser(assistantSource, attributeSource).$attribute

任意のアプリインスタンスのアプリユーザーに対するアシスタントのアプリユーザー属性値を取得します。

 getAssistantAppUser("active_directory", "google").firstName

managerSource、assistantSource、attributeSourceのパラメーターに正しいアプリ名を渡します。

関数 説明

hasDirectoryUser()

ユーザーにActive Directoryが割り当てられているかどうかを確認し、ブール値を返します。

findDirectoryUser()

Active Directoryアプリのユーザーオブジェクトを検索してそのオブジェクトを返します。ユーザーに複数のActive Directoryが割り当てられている場合と全く割り当てられていない場合はnullを返します。

カスタムマッピング

既存のServiceNowアプリのカスタムマッピングがある場合、カスタム属性をOktaプロファイルからServiceNowコネクターでハードコーディングされ、orgで使用されていないフィールドにマッピングできます。その後、そのフィールドをServiceNowの適切な列名に割り当てることができます。このマッピングを新しいServiceNowアプリ用に手動で作成します（スキーマ検出で説明）。

たとえば、OktaプロファイルにTシャツサイズ属性があるとします。現在、title属性は、orgで使用されていません。

  1. 顧客はuser.tshirtをServiceNow appuser.titleにマップします。

    servicenow_new_13

  2. 次に、ServiceNowアプリのプロビジョニング（Provisioning）セクションで、ユーザーはtitleがマップされる列名としてtshirtを入力します。

    servicenow_new_14

  3. これで、（「スキーマ検出」の手順に従って属性を追加した後）、次のようになります。

    servicenow_new_15

制限事項

  1. ServiceNowアプリに異なるユーザーIDと同じメールアドレスを持つ2人のユーザーが含まれている場合（たとえば、email=test_email@test.com）、次のエラーが表示されます。

    servicenow_new_16
    servicenow_new_17

  2. ServiceNow UD.1.0.4バージョンでは、タイムゾーン（Time Zone）ユーザープロパティがユーザーグループレベルに移動されました。ServiceNow UDアプリがユーザーグループに割り当てられると、管理者はこのグループのすべてのユーザーのタイムゾーンを選択できます。また、値は、以前のように通常のテキストフィールドではなく、ドロップダウンリストから入力されるようになりました。

    この変更は、新しいコネクターバージョンで作成されたすべてのアプリケーションに適用されます。既存のコネクターには、次の2つのオプションがあります。

    • サポートに、このアプリのUDスキーマを更新されたバージョンに移行してもらいます。インポートされたすべてのカスタムユーザー属性は削除されるため、ServiceNowから属性データをフェッチするには、それらを再度追加してユーザーを再インポートする必要があります。

    • 更新せずにコネクターを使い続けます。

    グループレベルでタイムゾーン属性があるかどうかを判断するには、ServiceNowアプリケーションをユーザーグループに割り当ててみてください。

    タイムゾーンなし（旧バージョン）：

    servicenow_new_18

    タイムゾーンあり（新バージョン）：

    servicenow_new_19

  3. ServiceNowアプリ インスタンスに、以前にOktaにインポートされていない新しい コストセンター、 会社、または部門に割り当てられたユーザーがいる場合、ユーザーをインポートする前にアプリケーションデータを更新する必要があります。そうしないと、インポートは失敗し、An error occurred during importというエラーメッセージが表示されます。

    アプリケーションデータを更新するには、アプリケーション（Applications）タブを選択し、その他（More）を選択してアプリケーションデータの更新（Refresh Application Data）をクリックします。アプリケーションデータは、数分後にバックグラウンドで更新されます。

  4. 列挙リストの無効化

    • 列挙リストを無効にする（Disable Enumerated Lists）がオンになっている場合、そのアプリインスタンスに対して後でオフにすることはできません。つまり、この機能はアプリインスタンスに対して1回だけ有効にすることができます。

    • 列挙リストを無効にする（Disable Enumerated Lists）を再度実行する場合は、新しいServiceNowアプリインスタンスを作成して構成する必要があります（新しいServiceNowアプリインスタンスのデフォルトの動作）。

その他の機能

以下の機能もServiceNowで使用できます。

Okta Identity Cloud for ServiceNow

ServiceNow ExpressまたはEnterprise用にOkta Identity Cloudアプリケーションを構成している場合は、「Okta Identity Cloud導入ガイド」を参照してください。ServiceNowストアで利用可能なOkta Identity Cloudは、ServiceNow内の「SSO Provided by Okta」プラグインを完全に置き換えることに留意してください。そのプラグインは廃止予定です。Okta Identity Cloudアプリは、標準のOkta統合とServiceNowのマルチプロバイダーSSOプラグインを介して、ServiceNowのすべてのSSOおよびユーザーライフサイクル機能を提供します。

Okta Orchestration Activity Pack

Okta Orchestration Activity Packを構成している場合は、「 OktaOrchestration Activity Packのセットアップ」を参照してください。

リソース

ライフサイクルWorkflowsの拡張とカスタマイズ