本紙の目的

昨今運用系のアプリのレガシーマイグレをやっているが、そのマイグレ先としてServiceNowを考えている
この一貫でServiceNowとAzure Acitve Directory(以下AAD)の連携について調べていたので、その調査内容を備忘録的に残したい

やったこと（流れ）

基本的にこちらに従って進めていく。

Azure無料アカウントやServiceNow Developer Instanceの準備
AADへのユーザー作成
ServiceNowへのSSOプラグインインストール
SSO設定(Azure側, ServiceNow側)
接続テスト
その他気になった点の検証

上記の1については普通にドキュメントがあるのでここでは割愛。ちなみに参考として以下。

ということでその次から記載する。

AADへのユーザー作成

まずはAADのユーザーを直接指定して、それをServiceNowにプロビジョニングし、それをベースにSSO出来る状態を目指す。グループやスコープフィルターを利用した、実際のユースケースに近いものは「気になった点の検証」の部分で触れる。

公式ドキュメントはこちらを参照。

AAD画面の左メニューにある ユーザー を選択。

新しいユーザー をクリック

必須パラメータを踏まえて以下を設定しておく。

ユーザー名: keiichi.hikita.servicenow (@以降は自動選択されている)
名前: Keiichi Hikita (ServiceNow)
初期パスワード: 適当なパスワード

この状態で、画面下部の 作成 ボタンを押下。

ServiceNowへのMultiple Provider Single Sign-on Pluginインストール

ドキュメントを見ると、ServiceNow側に Multiple Provider Single Sign-On プラグインが必要と書かれている。
なので、Developer Instanceにログインして、上記プラグインをインストールする。

ServiceNowのFilter Navigatorに plugin と入力
表示された画面上部の検索枠に multiple provider single sign 等と入力
表示されたプラグインの Install ボタンをクリック

このような画面が出るので Activate を押下。

SSO設定(AAD側)

AADにServiceNowをアプリケーションとして追加

AADの画面左メニューにある エンタープライズアプリケーション を選択。

新しいアプリケーション を選択。

ギャラリーの下の方に ServiceNow があるのでこれを選択。
すると画面右側に名前の入力欄が表示される。
今回は ServiceNow Developer Instance としておいた。

するとこのような形でServiceNowがアプリケーションとして登録される。

シングルサインオンの設定

先程の画面の左メニューで シングルサインオン を選択する。

表示されたものの中から SAML を選択する。

この画面で必須となっているものを入力していく。ドキュメントによると以下を入力することになる。

識別子 (エンティティ ID): https://<instance-name>.service-now.com
応答 URL: https://<instancename>.service-now.com/navpage.do
サインオン URL: https://<instancename>.service-now.com/navpage.do

加えて、以下も入力しておく。

ログアウト URL: https://<instancename>.service-now.com/navpage.do

SAML署名証明書の設定

この手順では、後々使うので以下を行っておくように書かれている。

アプリのフェデレーションメタデータURL をコピーしておく
証明書 (Base64) をクリックして証明書をダウンロードしておく

が、一度も使わなかったので割愛で良さそう。

サインオンの構成

上記のSTEPに表示されている ステップバイステップの手順を表示 のリンクを選択する。

すると画面右側に以下のような内容が表示される。

以下を入力する。

管理ユーザー名: admin
管理パスワード: [Developer Instanceにおけるadminユーザーのパスワード

入力が完了したら 今すぐ構成 ボタンを押下する。

シングルサインオン構成に成功すると、画面右上にバルーンが表示される。

これが終わったら一旦AADは離れて、ServiceNow側の設定に移る。

SSO設定(ServiceNow側)

基本設定

本来の手順ではここでプラグインをインストールすることになっているが、それは既に終わっているので割愛してその続きから。

ServiceNowの左メニューで、 Multi-Provider SSO > Properties と選択
右画面のチェックボックスを全てONに
The field on the user table that identifies a user accessing the "User identification" login page. By default, it uses the 'user_name' field. に email と入力
Save ボタンを押下

次に以下を実施。

左メニューから Multi-Provider SSO > Identity Providers と選択
右ペインが切り替わったら Microsoft Azure Federated Single Sign-on... を選択

画面が以下のように切り替わる。

この画面において、チュートリアルでは色々URLのコピペ等を実施するように書かれているが、大半ここまでの手順の中で終わっているので改めての実施は不要。

必要な作業としては証明書の設定。
これを行うべく、画面下部の X.509 Certificates の横にある Edit ボタンを押下。

左側にある Microsoft Azure Federated Single Sign-on for ... を右矢印で追加する。

その後 Save を押下。

ユーザーのプロビジョニング

この後チュートリアルに従うと、画面右上の Test Connection ボタンを使ってSingle Sign-Onをテストすることになる。
その前にユーザープロビジョニングをしてしまう方がいいのでそれをやっておく。
（チュートリアルではテスト用のユーザーを専用で作っているが、どのみち必要になるので）

プロビジョニング対象の選択

一旦AADの画面に戻る。

この画面で、ユーザーまたはグループの追加 を選択。（この画面までの遷移はスクショのパンくずを参照）

この画面の意味合いは、「ユーザーやグループを作成する」のではなく、「アプリケーション(ここではServiceNow)にプロビジョニングするユーザーやグループを決定する」という意味になる。

先程作成したユーザーを選択して 選択 -> 割り当て の順にクリックする。
これで当該ユーザーがプロビジョニングの対象になる。

プロビジョニング設定

次に、先程選択したグループのプロビジョニング設定を行う。

画面左の プロビジョニング を選択。

以下を入力する。

プロビジョニングモード: 自動
インスタンス名: インスタンスホスト名(dev*****)
通知用メール: デプロイ結果の通知先メールアドレス

一旦この状態で保存する。

どうやらこの状態ではプロビジョニング機能自体はONになっていないようなので、もう一度同じ画面を開く。

画面右上の プロビジョニングの編集 を選択。

画面下部の プロビジョニング状態 を オン にする。

デフォルトだと40分サイクルでプロビジョニングされるらしい。

プロビジョニングが成功すると以下のような画面が表示される。

接続のテスト

うまく行かない編

これでユーザーのデプロイが終わったので接続のテストが行えるようになる。
改めてこの画面を表示。表示の流れを復習すると以下。

左メニューから Multi-Provider SSO > Identity Providers と選択
右ペインが切り替わったら Microsoft Azure Federated Single Sign-on... を選択

で、 Test Connection を押下する...がこれだと動作しなかった。

ちなみ後述の変更を行い、上手くいった場合が以下。

うまく行かない場合、Phase 5/5の Subject Confirmation Validated でエラーとなる。
エラーの内容は以下のような形。

User: ******** not found
Ensure that the user you are trying the test connection with is present in the system.
Ensure that 'User Field' property value corresponds to the value set in the IDP returned through 'Subject NameID' in the response.

調べていくと以下の内容が見えてきた。

AADにおけるSAML Response上飛んでくる識別ID(Subject > Name ID属性)が userprincipalname になっている
- この属性の値が自分の環境だと異様に長い(130文字程度になっていた)ため、ServiceNow sys_user table側で正しく格納できていない。そもそもメールアドレスとは異なる値になっていた(#EXT とかいう文字列も入っていた)
これとマッチするフィールドをServiceNow側で探すためのフィールドは、前述の手順からsys_user.emailに設定している
という理由もあり、当然両者がマッチしない

余談としてAADからのプロビジョニングにおいて、ServiceNowのsys_user.emailが飛んでこない(これの原因が現在不明。マッピング的には正しいはずだがうまく行っていないので継続調査)

ちなみにSAMLの仕組みを理解する目的としては、この辺りが大変勉強となった。

ということで以下を実施した。

AADのシングルサインオン設定を一部変更

（上記は設定変更後の画面になってしまっており恐縮ですが）のSTEP2上の 編集 を選択し、、、

一位のユーザー識別子 (名前 ID) を user.mail に変更する。

ServiceNow 該当ユーザのemailを手動設定

前節の設定完了後、プロビジョニングが終わるまで待つ。
その後、ServiceNow側で該当ユーザのemailを手動設定する。

ServiceNowの左メニューから System Security > Users と選択。

この画面で、該当のユーザーレコードを検索し、 Email フィールドをダブルクリックして値を変更する。

これによりSAMLの識別子がメールアドレスとなり、かつそれをServiceNow側でも突合出来るようになったはず。

うまく行った編

この状態で Test-Connection。

このように Microsoft サインイン 画面が出るので、メールアドレスとパスワードを入力して進めていけば無事ログインできるようになった。

これでほぼシングルサインオン環境は整ったと言える。

あとはAuto-Redirect設定とかがあるらしい（動画によると）けど今回あまり関係ないので割愛。

実際のユースケースに向けて色々調査

ユーザーを作るたびに手動で割当(＆プロビジョニング)するのは当然嫌なので、特定の属性(等何かしらの目印)を持つユーザーが作成されたら自動でServiceNowにプロビジョニングされるようにしたい。

自分たちの場合、AAD上のユーザーは全社員分予め存在するため、そのユーザーの中からServceNowにプロビジョニングする対象を指定する方法を決めておいて、それを(既に存在するユーザーに)設定したら従って勝手にプロビジョニングされてほしい。

また、逆に不要になったユーザーはServiceNowから削除したい。（Inactiveにするのでも良い）

ということで以下のような内容を確認してみた。

Q. 割り当てユーザーから削除したユーザーはServiceNow側ではどうなる？

2ユーザーを割り当てて一度プロビジョニングをし、
その後特定のユーザーを割当対象から除外して再度プロビジョニングした場合、
その除外されたユーザーはServiceNowではどうなるのか？

A. InActiveになる

まず最初がこう。2ユーザーを割り当ててプロビジョニングした状態。

ここから割り当てユーザーを削除して次のプロビジョニングが走った状態。

除外したユーザーだけ Active=false になっている。

Q. ユーザーの属性を活用して自動プロビジョニングの対象にできるか？

A. 可能。方法は大きく2つくらいありそう

スコープフィルターを使う方式

例えばグループが自分たちの権限では作成できない・・・みたいな場合(?)に、ある属性が特定の値になっているユーザーをグルーピングしてServiceNow側にプロビジョニングする・・・とかできれば良いのかなと考えた。

プロビジョニングの設定時に、ユーザーの属性等でフィルタを行うことが出来る。

プロビジョニングの画面下部に スコープフィルターの追加 というリンクがあるのでこれを選択する。
（とはいえ、単に 編集 画面に入れれば良いので、このリンクを辿る意味は実はあまり無い）

マッピング を開いて Provision Azure Active Directory Users を選択する。

ソースオブジェクトスコープ を選択する。

この画面上部にある スコープフィルターの追加 から条件を追加することができ、この条件に合致したものをプロビジョニング対象にすることが出来る。

例えばこのような形で、 department 属性が servicenow のユーザーのみをプロビジョニング対象にすることが出来る。(逆に言うと department 属性が servicenow ではないユーザーは、割り当て対象として一覧に表示されていたとしても、プロビジョニングの対象から除外されるということを意味する)

ということで以下を行ってみる。

一旦2ユーザをActiveな状態にプロビジョニングする
その後上述のスコープフィルターを設定する
片方のユーザーのみdepartment属性に servicenow を設定する

この状態でプロビジョニングが走ると、もう一方のユーザーは（department=servicenowが設定されていないので） Active=false になる。というのが期待値。

結果、その通りの状態となった。(画面は前述のものと変わらないので割愛)

実際には拡張属性（というのをどう使えば良いのかわかっていないが）等を使って同様のことを行うのが良いのかもしれない。

グループを使う方式

プロビジョニングの対象としてグループを指定することが出来る。
この場合、グループ自体、及びそのメンバーであるユーザーがプロビジョニングされる。
これを利用し、グループにユーザーを追加するだけで自動的にプロビジョニング対象にするというイメージ。

グループの作り方や、ユーザーをグループに所属させる方法は公式ドキュメントを参照。

また、グループをプロビジョニング対象にするためにはライセンスを有効化する必要があるので、それについては後述する。

まずServiceNowグループだけをプロビジョニング対象として指定する。

なお、このグループとユーザーの関係は以下のようになっている。

Group-1(ServiceNow Group)
 ├ User-1(keiichi.hikita)
 └ User-2(keiichi.hikita.servicenow)

つまり画面でいうと以下。
グループ ServiceNow の配下にこれらのユーザーがメンバーとして登録されている状態。

この状態で(今回は一旦ServiceNow側からユーザーを全て物理削除し)プロビジョニングを実行すると、ユーザーとグループの関係性を維持したまま、ユーザーとグループの双方がプロビジョニングされた。

上の画面の通り、ServiceNow側にGroupがプロビジョニングされ、そのメンバーにユーザー2名が紐付いている。
(Userの名前の連携がうまく行っていないのは一旦無視...)

ちなみにこのグループによるプロビジョニングと、前述のスコープフィルターによるユーザーの絞リ込みの両方が設定されている場合、そのANDが取られる。

例

Groupをプロビジョニング対象としており、そのグループのメンバーに2ユーザーが居ると仮定する
うち1ユーザーのみがスコープフィルターを通過可能な状態となっている
この場合、グループ自体、および1ユーザー(フィルター通過したユーザー)だけがプロビジョニングされる

試用ライセンスのアクティベート

Azure試用版のデフォルトの状態だと、後述する手順に記載されている AADからServiceNowへのグループのプロビジョニング ができない。
そのため、最初に有効化しておく。

まずAADの左メニューで ライセンス を選択する。

メニューが切り替わるので、 すべての製品 を選択する。

試用/購入 を選択する。

画面右側に表示された各ライセンスの アクティブ化 ボタンを押下する。

すると次のようにActivateしたライセンス一覧が表示される。

次にこのライセンスを作成したグループに割り当てる。

AADのホームから グループ を選択。

ライセンスを割り当てたいグループを選択。

左メニューの ライセンス を選択。

右ペインに表示される 割り当て を選択。

割り当てたいライセンスを選択して、画面下部の 保存 を押下。

こうしておくことで、前述の手順でAADからServiceNowへのグループのプロビジョニング(含むユーザー)が出来るようになる。

まとめ

ServiceNowとAADの連携や、実際のユースケースに向けた検証を行った。

結果は想定していた期待値とほぼ同じ動きをしている。
自分たちのユースケースでは、グループベースのプロビジョニングが有効そう。

一部謎な部分もある(ユーザーのメールアドレスがプロビジョニングされない等）が、そこは追々調べていきたい。

Azure Active DirectoryとServiceNowの連携を検証してみたのでメモ