ServiceNow
このガイドでは、Okta orgでServiceNowのプロビジョニングを構成する方法について説明します。
前提条件
- この手順ではServiceNowアプリのインスタンスがすでにOktaに追加され、SSOを設定済みであることを前提とします。「ServiceNow向けにSAML 2.0を設定するには」を参照してください。アプリケーションの追加に関する一般的な情報については、「既存のアプリ統合の追加」を参照してください。
- Okta要件:
Oktaの[General(一般)]タブの下で完全なベースURLが設定されていることを確認します。
次のタブでサインオンオプションを構成します。
[Next(次へ)]をクリックして[Provisioning(プロビジョニング)]タブに戻ります。
プロビジョニング機能
以下のプロビジョニング機能をサポートします。
新規ユーザーをプッシュ | Oktaを通して新規ユーザーが作成されると、サードパーティアプリケーションでも作成されます。 |
ユーザーの非アクティブ化をプッシュ | Oktaを通してユーザーが非アクティブ化されるかアプリケーションへのアクセスが無効化されると、サードパーティアプリケーションでもそのユーザーは非アクティブ化されます。 |
プロファイルの更新をプッシュ | Oktaを通してユーザーのプロファイルに加えられた変更がサードパーティアプリケーションにプッシュされます。 |
新規ユーザーをインポート | サードパーティアプリケーションで作成された新規ユーザーがダウンロードされ、既存のOktaユーザーとのマッチングのために新規AppUserオブジェクトに変換されます。 |
プロファイルの更新をインポート | サードパーティー製アプリケーションのユーザープロファイルに行われた更新がダウンロードされ、Oktaでローカルに保存されたプロファイルのフィールドに適用されます。アプリlがOktaのレコードシステムである場合、コアプロファイルフィールド(メール、姓、名)に加えられた変更はユーザープロファイルに適用されます。アプリがレコードシステムでない場合、アプリ固有のフィールドに加えられた変更のみがローカルユーザープロファイルに適用されます。 |
グループプッシュ | グループとそのメンバーをリモートシステムにプッシュできます。グループプッシュ操作(グループプッシュの機能強化を含む)の使用に関する詳細については、「グループプッシュの管理」を参照してください。 |
ユーザーの再アクティブ化 | Oktaを通してユーザーを再アクティブ化すると、そのユーザーはサードパーティアプリケーションでも再アクティブ化されます。 |
パスワードを同期 | Oktaからサードパーティアプリケーションにユーザーパスワードをプッシュします。 |
手順
ServiceNowプロビジョニングの構成
以下の手順に従い、ServiceNowの[Provisioning(プロビジョニング)]設定を構成します。
-
[Enable API Integration(API統合を有効化)]をオンにします。
-
ServiceNow API資格情報を入力します。
-
[Admin User Name(管理者ユーザー名)]:Organizationの管理者権限を持つServiceNowユーザー名を入力します。
-
[Admin Password(管理者パスワード)]:(上記の)管理者アカウントのパスワードを入力します。
-
[Test API Credentials(API資格情報のテスト)]をクリックして、資格情報を検証します。
-
-
[Save(保存)]をクリックします。
-
左パネルで[To App(アプリへ)]を選択し、次に有効化したい[Provisioning Features(プロビジョニング機能)]を選択します。
-
これで、(必要に応じて)ユーザーをアプリに割り当て、アプリケーションのセットアップを完了することができます。
ServiceNowスキーマ検出を使用してユーザープロファイルの属性を追加する
ServiceNowはユーザーのスキーマ検出をサポートするため、ユーザーのプロファイルに他の属性を追加することができます。
ユーザーのプロファイルに属性を追加するには、以下の手順に従ってください。
-
Okta Admin Consoleで、[Directory(ディレクトリ)]>[Profile Editor(プロファイルエディタ)]に移動します。
-
左のナビゲーションペインから[APPS(アプリ)]セクションを選択し、リストから目的のアプリを見つけます。プロファイル編集アイコンをクリックして、Profile Editorページを開きます。
-
属性のリストを確認し、さらに必要な場合は[Add Attribute(属性を追加)]をクリックします。拡張された属性リストが表示されます。
-
追加したい属性をチェックし、[Save(保存)]をクリックします。
-
追加された属性は、カスタム属性のリストでページを更新した後でも存在するはずです。これらのユーザー属性値をServiceNowとの間でインポートおよびプッシュできるようになりました。
-
これで、カスタム属性のマッピングを作成できます。
プロファイルマッピング
デフォルトの属性
左側のナビゲーションペインの[Directory(ディレクトリ)]>[Profile Editor(プロファイルエディタ)]>[APPS(アプリ)]セクションでデフォルトの属性を確認し、リストでアプリを見つけることができます。
Active Directoryマッピング
変更不可能な特定のフィールド向けに事前定義されたADマッピングがあり、これはADがソースとして構成されている場合のみに使用されます。
マネージャー/アシスタント機能
以下に例を示します。詳しくは、Okta開発者用ドキュメントの「ディレクトリおよびWorkday機能」、および「よく使用される式」を参照してください。
関数 |
説明 |
例 |
getManagerUser(managerSource).$attribute |
管理者のOktaユーザー属性値を取得します |
getManagerUser("active_directory").firstName |
getManagerAppUser(managerSource, attributeSource).$attribute |
任意のアプリインスタンスのアプリユーザーに対する管理者のアプリユーザー属性値を取得します。 |
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パラメーターに正しいアプリ名を渡します。
現時点では、managerSourceとassistantSourceでサポートされているのはactive_directoryのみです。
関数 | 説明 |
---|---|
hasDirectoryUser() |
ユーザーにActive Directoryが割り当てられているかどうかを確認し、ブール値を返します |
findDirectoryUser() |
Active Directoryアプリのユーザーオブジェクトを検索してそのオブジェクトを返します。ユーザーに複数のActive Directoryが割り当てられている場合と全く割り当てられていない場合はnullを返します。 |
カスタムマッピング
既存のServiceNowアプリのカスタムマッピングがある場合。
カスタム属性をOktaプロファイルからServiceNowコネクタでハードコーディングされ、orgで使用されていないフィールドにマッピングする場合は、そのハードコーディングされたフィールドをServiceNowの適切な列名に割り当てます-このマッピングを新しいServiceNowアプリ用に手動で作成します(「スキーマ検出」で説明)。
たとえば、OktaプロファイルにTシャツサイズ属性があるとします。現在、title属性は、orgで使用されていません。
-
顧客はuser.tshirtをServiceNow appuser.titleにマップします。
-
次に、ServiceNowアプリの[Provisioning(プロビジョニング)]セクションで、ユーザーはtitleがマップされる列名としてtshirtを入力します。
-
これで、(「スキーマ検出」の手順に従って属性を追加した後)、次のようになります。
制限事項
-
ServiceNowアプリに異なるユーザーIDと同じメールアドレスを持つ2人のユーザーが含まれている場合(たとえば、email=test_email@test.com)、Okta側で同じメールアドレスとユーザー名を持つユーザーを作成しようとすると(たとえば、Okta UserName = Okta email = test_email@test.com)、次のエラーが表示されます。
-
ServiceNow UD.1.0.4バージョンでは、[Time Zone(タイムゾーン)]ユーザープロパティーがユーザーグループレベルに移動されました。ServiceNow UDアプリがユーザーグループに割り当てられると、管理者はこのグループのすべてのユーザーに対して[Time Zone(タイムゾーン)]の値を選択できます。また、値は、以前のように通常のテキストフィールドではなく、ドロップダウンリストから入力されるようになりました。
上記の変更は、新しいコネクタバージョンで作成されたすべてのアプリケーションに適用されます。既存のコネクタには、次の2つのオプションがあります。
-
サポートに、このアプリのUDスキーマを更新されたバージョンに移行してもらいます。インポートされたすべてのカスタムユーザー属性は削除されるため、ServiceNowから属性データをフェッチするには、それらを再度追加してユーザーを再インポートする必要があります。
-
更新せずにコネクタを使い続けます。
グループレベルでタイムゾーン属性があるかどうかを判断するには、ServiceNowアプリケーションをユーザーグループに割り当ててみてください。
タイムゾーンなし(旧バージョン):
タイムゾーンあり(新バージョン):
-
-
ServiceNowアプリインスタンスに、以前にOktaにインポートされていない新しいコストセンター、会社、または部門に割り当てられたユーザーがいる場合、ユーザーをインポートする前にアプリケーションデータを更新する必要があります。そうしないと、インポートは失敗し、「An error occurred during import(インポート中にエラーが発生しました)」というエラーメッセージが表示されます。
アプリケーションデータを更新するには、[Applications(アプリケーション)]タブを選択し、[More(その他)]を選択して[Refresh Application Data(アプリケーションデータの更新)]をクリックします。アプリケーションデータは、数分後にバックグラウンドで更新されます。
-
列挙リストを無効にします。
-
[Disable Enumerated Lists(列挙リストを無効にする)]がオンになっている場合、その特定のアプリインスタンスに対して後でオフに戻すことはできません。つまり、この機能はアプリインスタンスに対して1回だけ有効にすることができます。
-
[Disable Enumerated Lists(列挙リストを無効にする)]を再度実行する場合は、新しい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を構成している場合は、「Okta Orchestration Activity Packのセットアップ」を参照してください。