最近、ServiceNow 統合の認証方法を最新化したいと考えているクライアントと仕事をしました。時間の経過とともに、ローカルサービスアカウントと統合固有の認証情報を組み合わせて使用して、複数のインターフェイスが実装されるようになりました。 各インターフェイスは機能していましたが、全体的なモデルの管理とサポートが難しくなっていました。
その目標は、ServiceNow を呼び出すシステムと外部 API を呼び出す ServiceNow をサポートできる再利用可能な認証パターンを利用することでした。 クライアントは、Microsoft Entra ID を信頼できる ID プロバイダーとして、OAuth 2.0 を共通の認証メカニズムとして決定しました。
課題
多くの場合、認証は統合アーキテクチャの一部ではなく、セットアップアクティビティとして扱われます。このアプローチは、インターフェイスの数が増え、チームが多くのアカウント、シークレット、トークン、アクセスパスを管理することになるまで機能します。
この実装では、次のようなモデルが必要でした。
- Microsoft Entra ID でアプリケーション認証を一元化します。
- パスワードとローカルで管理される統合認証情報への依存を減らします。
- 受信と送信の両方の REST 統合をサポートします。
- 専用のアプリケーション ID により、トレーサビリティを提供します。
- 各統合を実際に必要な ServiceNow API とロールに制限します。
ソリューションアーキテクチャ
|
Entra ID が認証します。ServiceNow が承認します。 |
受信トラフィックの場合、呼び出し元アプリケーションは Entra ID からアクセストークンを取得し、そのトークンを ServiceNow に提示します。ServiceNow はトークンを検証し、アプリケーション ID を ServiceNow ユーザーにマッピングしてから、プラットフォームロールと OAuth スコープを適用します。
送信トラフィックの場合、ServiceNow は OAuth アプリケーションレジストリと OAuth プロファイルを使用して Entra ID からアクセストークンを取得します。REST メッセージとフローデザイナーアクションは、トークンロジック自体を管理する代わりに、その構成を再利用します。
認証パターン
|
方向 |
トークン要求者 |
ID プロバイダー |
API クライアント |
認証ポイント |
|
インバウンド |
外部アプリケーション |
Microsoft Entra ID |
ServiceNow API |
ServiceNow のスコープとロール |
|
アウトバウンド |
ServiceNow |
Microsoft Entra ID |
外部 REST API |
外部 API 権限 |
受信 REST 統合の保護
インバウンド統合は、より興味深い設計上の問題を提示しました。ServiceNow は、Entra ID によって発行されたトークンを信頼し、呼び出し元アプリケーションを識別してから、共有ユーザー名とパスワードに依存せずに正しい ServiceNow アクセス許可を適用する必要がありました。
1. Entra OIDC プロバイダーを構成します
まずはServiceNowのOAuth OIDCプロバイダー構成から始めました。このレコードは、Entra ID によって発行された受信トークンを検証するために使用される信頼関係を確立します。
図1.受信 Entra 認証に使用される OAuth プロバイダーレコード。
レコードの下部には、OIDC メタデータ URL と要求マッピング構成が含まれています。
図2.OIDC メタデータとユーザー要求の構成。
2. アプリケーション ID をマッピングします
クライアントのアクセストークンには、許可されたアプリケーションを識別する「azp」クレームが含まれています。この要求属性を ServiceNow ユーザーレコードの専用の一意の ID フィールドにマッピングしました。これにより、各統合アプリケーションは、制御された ServiceNow ID に解決できました。
図3.azp から ServiceNow unique-ID フィールドへの要求マッピング。
対応する ServiceNow ユーザーレコードの [一意の ID] フィールドに Entra アプリケーション識別子が含まれています。この関連付けを設定すると、ServiceNow はトークンを目的の非インタラクティブ統合 ID に解決できます。
図4.一意の ID フィールドで一致した統合ユーザー。
3. 最小特権承認を適用します
認証だけでは、広範な API アクセスを提供することはできません。明示的な承認スコープを使用して、プロバイダーを統合用に承認された API に制限しました。
図 5.承認された API に制限された OAuth 承認スコープ。
マップされたユーザーには、受信データのロードと処理に必要な ServiceNow ロールが割り当てられます。正確なロールはインターフェイスによって異なりますが、専用の ID を使用し、その統合に必要なアクセス権のみを付与するという設計原則は変わりません。
図6.インバウンド統合ユーザーに割り当てられたロール。
送信 REST 統合の保護
アウトバウンド統合は、信頼の方向を逆にします。ServiceNow は OAuth クライアントになり、外部 API を呼び出すときに使用できるアクセストークンを要求します。
1. OAuth アプリケーションレジストリを構成します
OAuth アプリケーションレジストリレコードを使用して、Entra ID を介した認証に必要なクライアント構成とトークンエンドポイントを保存しました。レジストリレコードは、同じアプリケーション登録モデルとセキュリティモデルを使用するアウトバウンド統合のための再利用可能な基盤になります。
図 7.Entra ID 用に構成された OAuth アプリケーションレジストリ。
ServiceNow 環境間で構成を移動するときに、リダイレクト URL を確認する必要があります。トークン URL は、クライアントの ID 設計の一部であるのと同じ Entra テナントに関連付けたままにすることができます。
2. OAuth プロファイルを REST メッセージに関連付けます
REST メッセージは OAuth 2.0 プロファイルを参照します。実行時に、ServiceNow はプロファイルを使用してトークンを取得し、送信要求に含めます。これにより、認証構成が個々のスクリプトやフローデザイナーアクションから除外されます。
図8.OAuth プロファイルを使用するように構成された REST メッセージ認証。
REST メッセージが構成されると、フローデザイナーアクションは、個別のトークン生成プロセスを実装せずにその HTTP メソッドを呼び出すことができます。アクションは入力、要求コンテンツ、および応答処理に重点を置き、REST メッセージは認証を管理します。
このパターンが機能した理由
共通のアイデンティティレイヤー :受信インターフェイスと送信インターフェイスの両方で Entra ID を使用するため、サポートチームが理解する必要がある認証パターンの数が減ります。
明確な責任の分離 :Entra ID はアプリケーション ID を確立します。ServiceNow は、要求マッピング、OAuth スコープ、ユーザー、およびロールを通じてプラットフォームへのアクセスを制御します。
再利用可能な構成 :プロバイダー、レジストリ、プロファイル、REST メッセージ、およびフローデザイナーのレコードは、すべての統合のカスタムトークンロジックとして再作成するのではなく、構成要素として再利用できます。
監査可能性の向上 :専用のアプリケーション ID を使用すると、共有の汎用アカウントよりも統合が簡単に区別できます。
認証情報処理の削減 :OAuth はトークン発行を一元化し、認証ロジックをスクリプトまたは個々のフローに直接配置する必要性を最小限に抑えます。
最終的な考え
認証要件として始まったものが、再利用可能な統合パターンになりました。 アプリケーション認証に Microsoft Entra ID を使用し、プラットフォーム承認に ServiceNow を使用することで、受信と送信の両方の REST Web サービスに対して一貫したアプローチを作成しました。
拡大する ServiceNow 統合ポートフォリオを構築するチームの場合、標準の Entra パターンと OAuth パターンを早期に確立することで、すべての新しいインターフェイスが個別の認証設計演習になるのを防ぐことができます。
この記事は機械翻訳されております。最新は元となる記事をご覧ください: https://www.servicenow.com/community/developer-blog/using-microsoft-entra-id-to-secure-servicenow-in...。
免責事項: 一部の日本語は、翻訳ソフトウェアを使用してお客様の便宜のために翻訳されています。正確な翻訳をご提供できるよう相当な努力を払っておりますが、いかなる自動翻訳も人間の翻訳者に代わすることはなく、そのようなことは意図されておりません。翻訳は「現状のまま」提供されています。他言語への翻訳の的確性、信頼性または正確性については、明示または黙示を問わず、いかなる保証も行われません。翻訳ソフトには限界があるため、一部のコンテンツが正確に翻訳されていない場合があります。これらの資料の公用言語は英語です。翻訳の際に生じる相違または不一致は、コンプライアンスまたは履行の目的に関しては拘束力を有さず、法的効力はないものとします。
This article was machine translated and replicated from the original source: https://www.servicenow.com/community/developer-blog/using-microsoft-entra-id-to-secure-servicenow-in...。
