ServiceNowは様々なログイン方法に対応しており、その一つにSAML認証よるSSOがあります。この記事では、ServiceNowにSAML SSOできるようになるまでの環境構築手順を1から紹介します。
（全てDeveloper用の無料枠で再現可能です。）

SAMLそのものの説明はしませんが、各設定項目の説明は公式ドキュメント等を元に自分の理解を所々記載しています。とはいえSAML初心者が勉強しつつ設定をやってみた際の理解ですので、その点はご了承ください。

概要

SAMLにおいては、認証を行う側のシステムをIdP (Identity Provider) と呼び、IdPの認証情報を利用する側のシステムをSP (Service Provider) と呼びます。

今回の場合は、ServiceNowがSPということになります。
IdPは、実際には社内で使われているIDaaSなどで連携させることになりますが、ここではIdPとしてAuth0を使用します。

ServiceNowにおけるSSOのフローは、以下の公式ドキュメントにある概要図でおおよそのイメージを掴めるかと思います。
図の右側のCustomer Portal / SSO Solutionが今回でのAuth0に該当するような形です。
Typical SAML process flow (diagram)

手順概要

おおまかな構築の流れは以下の通りです。

Auth0の設定
1. ServiceNowをSPとして登録
2. テスト用ユーザーの作成
ServiceNowの設定
1. Multi-Provider SSO Pluginのインストール
2. ACR (Account Recovery) の有効化 (追記)
3. Multi-Provider SSOの設定
4. Auth0をIdPとして登録
5. テスト用ユーザーの作成
6. Connection Test & Activate
動作確認

今回ServiceNowは無料のDeveloperインスタンスを、Auth0はFreeプランを使用することとします。それぞれを使用できるまでの手順はここでは省かさせていただきます。

1. Auth0の設定

1-1. ServiceNowをSPとして登録

左側のメニューからApplications > Applications を開いて、Create Applicationを押下します。

Nameには任意の名称を入力して、Application Type は Regular Web Applicationsを選択します。
その後、Createを押下します。

Addonsのタブを開き、SAML2 WEB APPのトグルスイッチを押下します。(ポップアップが開きます。)

Usageのタブにて、IdPのMetadataをダウンロードしておきます。ダウンロードしたMetadataは、後のServiceNow側の設定で使用します。

続いてSettingsのタブを開きます。
Application Callback URLには以下を入力します。ここの内容は後ほど説明します。
([instance-name]は自身のものに置き換え)

https://[instance-name].service-now.com/navpage.do

Settingsには以下のJSONを入力します。こちらも、内容は後ほど説明します。
([instance-name]は自身のものに置き換え)

settings.json

{
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
  "nameIdentifierProbes": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  ],
  "logout": {
    "callback": "https://[instance-name].service-now.com/navpage.do"
  }
}

入力を終えたら、そのまま一番下までスクロールし、Enableを押下します。

1-2. テスト用ユーザーの作成

ユーザーストアはIDaaSには直接持たせずADなどと連携するケースも多いかと思いますが、今回は小規模なテスト環境なので、Auth0のビルトインDBに直接ユーザーを作成します。

User Management > Usersのメニューを開き、Create Userを押下します。

EmailとPasswordを入力し、Createを押下します。
（今回は適当な自前のGmailアドレスで登録しています。）

その後、設定したメールアドレス宛に、Verificationのメールが届くので、メールに記載されているリンクにアクセスしてVerificationを済ませます。

(Optional)
Nameにはデフォルトでメールアドレスがそのままセットされますが、任意の名前に変更しておきます。
なお、下図を見ると分かりますが、Auth0上でのuser_idは自動的に割り振られるようです。

2. ServiceNowの設定

2-1. Multi-Provider SSO Pluginのインストール

ServiceNowに、SSO機能を導入するためのPluginをインストールします。

System Application > All Available Application > Allのメニューを開き、"Integration - Multiple Provider Single Sign-On Installer" をインストールします。

Activateを押下します。

完了したらClose & Reload Formを押下します。

2-2. ACR (Account Recovery) の有効化

San Diego以降のバージョンにおいては、SSOを使用するにあたっては、ACR (Account Recovery) の機能を有効化することが必須となっています。
ACRは、例えばIdPの証明書切れなどの問題によってSSOログインが成立しなくなってしまった場合に備え、管理者のみローカル認証によるログイン (SSOバイパス) ができるようにする機能です。
なお、ACRを有効化すると次の変化があります。

ACR Userとして登録した管理者ユーザー以外は、ローカル認証でのログインは出来なくなります。
ACR Userがローカル認証でログインをした場合は、特殊なロールが割り当てられた状態でのログインとなり、操作できるのは基本的にSSO周りの設定のみに限定されます。adminロールを持つユーザーであっても、ACR Userとしてログインする場合はSSO周りの設定のみにしか権限が与えられません。

ACRのセットアップを行うには、Navigation BarからMulti-Provider SSO > Account Recovery > Propertiesのメニューを開きます。
下図の画面が現れますので、Step2.の「Click here」の部分を押下します。

ACR Userのローカル認証はローカルパスワード + MFAですので、MFAの登録を促されます。
Google AuthenticatorなどのTOTPアプリを自身のスマートフォンにインストールした上で、画面のナビゲーションに従いデバイス登録をします。

デバイス登録が完了するとEnable account recoveryボタンを押せるようになります。
ボタンを押下してACRの有効化は完了です。

2-3. Multi-Provider SSOの設定

Navigation BarからMulti-Provider SSO > Administration > Propertiesのメニューを開きます。下図の通り設定し、Saveを押下します。

各項目の詳細

詳しくは以下の公式ドキュメントが参考になります。
Configure Multi-Provider SSO properties

Enable multiple provider SSO
- Yesを選択します。
- 有効にすることで、ServiceNowのログインページ (/login.do) に、Use External Loginのリンクが現れ、ユーザーがSSOログイン用のページへ遷移できるようになります。
Enable Auto Importing of users from all identity providers into the user table
- SAML User Provisioningの機能を有効化するか否かの設定です。
- SAML認証でSSOするには、対象のユーザーがUser Table [sys_user] に存在していることが前提です。ただし、User Provisioning機能を使うと、User Tableに存在しないユーザーがSAMLでの初回ログインを行ったときに、そのユーザーが自動的にUser Tableに登録されます。これによりUser Tableに存在していなかったユーザーも最初からSAMLでのログインが可能になります。
- 今回はいったん、事前にUser Tableに存在しているユーザーのみをSAML認証の対象とするため、Noを選択します。
- SAML User Provisioningについては、別途下記の記事を作成しました。よろしければこちらもご参照ください。
  - [ServiceNow] SAML SSOしたとき自動でユーザーレコードの作成/更新をする (SAML User Provisioning)
Enable debug logging for the multiple provider SSO integration
- debuggingを有効化するか否かの設定です。
- 今回はNoを選択します。
- 通常運用時に有効化しているとパフォーマンスやディスク容量に影響を及ぼす可能性もあるので注意が必要です。
The field on the user table that identifies a user accessing the "User identification" login page
- SSOログインのページ(/login_locate_sso.do)で、ユーザーに自分自身のIDとして入力させる値を設定します。
- ServiceNowは、ここで入力された値を元にSSOをリクエストしたユーザーが誰なのかUser Tableからレコードを検索して特定します。
- 設定できるのはUser Tableで定義されているフィールド名です。(ラベル名ではない。)
- デフォルトはuser_nameですが、ユーザー側の視点だとメールアドレスのほうが扱いやすいと思うので、emailに変更します。
- ここで設定したFieldは、User Table上で一意の値を持つフィールドであることが保証されている必要があります。(例えばemailにする場合、同じメールアドレスを持つ異なるユーザーをUser Tableに作成することは可能ではあるが、SSOの観点ではそのようなユーザーが存在しないようにしなければならない。)

2-4. Auth0をSAML IdPとして登録

Multi-Provider SSO > Identity Providersのメニューを開きます。Newを押下して、新しいIdPの登録を行います。

SAMLを押下します。

ポップアップが現れますので、XMLを選択します。
テキストエリアには先の手順 (1-1) でAuth0から入手したMetadataの中身をコピペししてimportを押下します。

インポートしたMetadataに沿って各フィールドに値がセットされます。内容を確認したらUpdateを押下して保存します。
なお、IdPのMetadataにはX.509証明書も含まれていますので、X.509 Certificateの関連リストにも自動的にレコードが作成されます。

(補足)
各項目の詳細はここでは省かさせていただきますが、以下の公式ドキュメントに各項目の説明があります。
SAML 2.0 configuration using Multi-Provider SSO

保存した後、先程の画面でGenerate Metadataを押下するとMetadataを出力できます。
今回はIdP (Auth0) 側の設定は先に手動入力で行いましたが、本来であればこのSPのMetadataを読み込ませて設定をすることが多いかと思います。(Auth0ではSPのMetadataを読み込ませる方法が見当たらなかったため、手動で設定しました。)

Metadataから読み取ることのできる値には、例えば下記のものがあります。

項目名	記載場所	上記Metadataにおける値
SP Entity ID	`<Entity Descriptor>`タグ内の`EntityID=`に続く値	`[instance-name].service-now.com`
ACS URL	`<AssertionConsumerService>`タグ内の`Location=`に続く値	`[instance-name].service-now.com/navpage.do`
SLO URL	`<SingleLogoutService>`タグ内の`Location=`に続く値	`[instance-name].service-now.com/navpage.do`
NameID Format	`<NameIDFormat>`タグに囲まれた値	`urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`

Auth0の設定内容の振り返り

Auth0側にSPとしてServiceNowを登録する作業は先に済ませていましたが、ここで改めて内容を確認し、ServiceNow側の設定値とどのように対応させていたのか見てみたいと思います。

Application Callback URL

以下の通り設定していました。

https://[instance-name].service-now.com/navpage.do

Application Callback URLは、IdPが認証後にSPへAssertion (認証情報やユーザーの属性値などをXML形式で表したもの) を送る宛先のURLです。
ServiceNowにて出力したMetadataにおける<AssertionConsumerService>タグ内のLocation=に続く値を設定します。

(補足)
IdPによってはApplication Callback URLではなくて、ACS URL、Post-back URLなど別の呼び方かもしれません。

This may be called Assertion Consumer Service URL, Post-back URL, or Callback URL.

Manually configure SSO integrations

settings

以下の通り設定していました。
settingsの書式やデフォルト値は以下の公式ドキュメントに説明があります。
Customize SAML Assertions

settings.json

{
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
  "nameIdentifierProbes": [
    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  ],
  "logout": {
    "callback": "https://[instance-name].service-now.com/navpage.do"
  }
}

nameIdentifierFormat
- NameID Formatの指定です。
- ServiceNowにて出力したMetadataにおける<NameIDFormat>タグに囲まれた値を設定します。
- 今回はNameIDにemailを使用するので、NameID Formatもそれに合わせています。(NameIDについては後述)
- ちなみに指定しない場合、Auth0はデフォルト値のunspecifiedになります。
- ServiceNow側はNameID PolicyフィールドにてNameID Formatを変更できます。デフォルトでemailAddressに設定されているため変更しませんでした。
- なお、他にどんな種類のNameID Formatがあるかは「SAML ~ NameID Format をご紹介 ~」が参考になりました。
nameIdentifierProbes
- ユーザーのどの属性値をNameIDとしてSPへ提示するかの指定です。
- NameIDとは、ざっくりいうとIdPとSPの間で共有するユーザーの識別子です。
- Auth0はデフォルトだとuser_idをNameIDとしてSPに提示します (*1)
- 今回はemailをSPに提示するように変更をしました。
- ServiceNow側ではAdvancedタブにあるUser Fieldフィールドにて、IdPから提示されたNameIDをUser Table上のどのフィールドで検証するか指定できます。デフォルトでemailに設定されているため変更しませんでした。

(*1) より正確には、Auth0はuser_id → email → nameの順に見ていき、最初に値があったものをNameIDとしてSPに提示するようです。

Auth0 will try each of the attributes of this array in order. If one of them has a value, it will use that for the Subject/NameID.The order is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (mapped from user_id), http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress (mapped from email), http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name (mapped from name).

Customize SAML Assertions

logout.callback (*2)
- Single Logout (SLO) のRequest, ResponceをSPへ送る宛先のURLです。
- ServiceNowsにて出力したMetadataにおける<SingleLogoutService>タグ内のLocation=に続く値を設定します。

(*2) SLOの設定は必須でないようですので、不要な場合はlogoutのキーごと消します。なお、その場合はServiceNow側でもIdentity Provider's SingleLogoutRequestフィールドを空欄にします。

2-5. テスト用ユーザーの作成

ServiceNowのUser Tableにユーザーを作成します。

前準備として、先ほど登録したIdPのsys_idを取得しておきます。
Multi-Provider SSO > Identity Providersのメニューを開き、先ほど登録したIdPのレコードで右クリックをし、copy sys_idでsys_idをクリップボードにコピーしておきます。

User Administoration > User を開き、Newを押下します。

ユーザーを作成します。ポイントは次の2点です。

EmailはAuth0で作成したユーザーのメールアドレスと一致させる
- (補足:Auth0はNameIDとしてメールアドレスを提示するよう設定し、ServiceNowは受け取ったNameIDの値をEmailフィールドの値で検証するよう設定したため)
SSO Sourceには先ほどコピーしたsys_idを使って、sso:[sys_id]と設定する
- (補足:SSO Sourceのフィールドが見えない場合はForm Layoutを変更して追加)

それ以外の項目は、(SAML SSOの観点では) 特に何でも良いです。

2-6. Connection Test & Activate

これにて準備が整いましたので、実際にSAML連携ができるかServiceNow側からテストします。
(このテストに成功しないとIdPとの連携をActiveにできません。)

Multi-Provider SSO > Identity Providersのメニューにて、先ほど登録したIdPのレコードを開きます。上部のTest Connectionを押下してテストを実施します。

正しく設定ができていれば、Auth0の認証画面が現れます。
Auth0にて作成したユーザーのメールアドレスとパスワードを入力してLOG INを押下します。

LOG IN押下後、SSO Login/Logoutのテスト結果が表示されます。全て問題なければ下図の通りとなります。
内容を確認したらActivateを押下して、IdPの連携を有効化します。
(SLOの設定を省略した場合はSSO Logout Test Resultsにバツが表示されますが、Activateすることは可能です。)

以上で設定は完了です。

3. 動作確認

実際にSAMLでログインが出来るか確かめます。

Private Windowなどで新しいブラウザを開き、ServiceNowのログインページにアクセスします。
Use external loginを押下します。

メールアドレスを入力してSubmitを押下します。
(ここで入力欄にEmailと表示されているのは、2-2.にてThe field on the user table...をemailにしたためです。)

Submitを押下すると、入力されたメールアドレスに基づいてUser Tableから該当するユーザーのレコードが特定されます。特定したユーザーのレコードからSSO Sourceの値を読み取って、そのIdPのLogin画面へリダイレクトします。

Auth0の認証画面が現れるはずですので、Auth0にて登録したユーザーのメールアドレスとパスワードを入力しLOG INを押下します。

上手く認証が通れば、実際にTEST USERとしてログイン出来ているのが確認できます。

おわりに

業務アプリをServiceNowへ移行するお仕事をやっていてServiceNowを触りはじめましたが、そのとき社内のSSOシステムとServiceNowのSAML連携も初めて行いました。本記事はそのときに調べたことをまとめる形で書きました。

慣れていればどのIdP/SPを使っていてもどこに何を設定すれば良いかすぐに分かると思いますが、はじめての場合は苦戦するかもしれません。本記事が少しでもその理解の助けになれば幸いです。

参考

SAML 認証はどのように機能するか？