認証
合成テストには、Splunk Synthetic Monitoring がそのテストタイプでサポートしている認証方法を組み込むことができます。
Syntheticsテストでは、以下の認証方法を設定に利用可能です:
|
テストタイプ |
認証メソッド |
|---|---|
|
ブラウザ |
|
|
アップタイム |
|
|
API |
HTMLログインフォームによる基本認証
テスト対象がユーザー名とパスワードを入力するためのHTMLフォームを提供している場合は、ブラウザテストを以下のように設定します。
-
このテスト対象のユーザー名とパスワード用にグローバル変数を作成します。ベストプラクティスは、 パスワード用に作成したグローバル変数を非表示にすることです。詳細については、「グローバル変数」を参照してください。
-
ブラウザテストの設定ページで、[Simple] トグルを選択します。
-
Edit steps or synthetic transactions を選択します。
-
Fill in fieldというタイプのステップを追加し、以下のように設定します:
-
[Selector] に、ターゲットページのユーザー名フィールドの ID、名前、XPath、 CSS 、リンク、または JS パスを入力します。Chrome の要素セレクタの詳細については、「Chrome DevTools」を参照してください。
-
[Value] には、ユーザー名を格納したグローバル変数名を、env. を先頭につけて二重中括弧で囲んで入力します。たとえば、
{{env.test1_username}}のようになります。
-
-
Fill in fieldというタイプのステップを追加し、以下のように設定します:
-
[Selector] に、ターゲットページのパスワードフィールドの ID を入力します。
-
[Value] には、パスワードを格納したグローバル変数名を、env. を先頭につけて二重中括弧で囲んで入力します。たとえば、
{{env.test1_password}}のようになります。
-
-
Clickというタイプのステップを追加し、以下のように設定します:
-
[Selector] に、ターゲットページのログインボタンの ID を入力します。
-
(オプション)Wait for navigation**を待機するミリ秒数に設定します。
-
-
ログインが成功したことを確認するために、Assert text presentというタイプのステップを追加し、以下のように設定します:
-
Textには、ログインが成功した場合にのみテスト対象ページに表示される文字列を入力します。
-
(オプション)ページが確実にロードされるように、Wait for up toをミリ秒単位で十分に大きな値に設定します。
-
-
Submit を選択します。
ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。
HTTPヘッダーによる基本認証
テスト対象がHTTPヘッダーにログイン認証情報が含まれることを期待している場合、ブラウザテストを以下のように設定します。
-
このテスト対象のユーザー名とパスワード用にグローバル変数を作成します。ベストプラクティスは、 パスワード用に作成したグローバル変数を非表示にすることです。詳細については、「グローバル変数」を参照してください。
-
ブラウザテストの設定ページで、[Advanced] トグルを選択します。
-
[Security] セクションまで下にスクロールします。
-
Authenticationの行で、以下のように値を設定します:
-
左のフィールド(ヒントのテキストUsername)に、ターゲットページのユーザー名を入力します。
-
右のフィールドには、このターゲットページのパスワードを格納したグローバル変数名を、
env.を先頭につけて二重中括弧で囲んで入力します。たとえば、{{env.test1_password}}のようになります。使用可能なグローバル変数のリストを表示するには、右側のペインを展開します。
-
-
ブラウザテストの設定ページで、[Simple] トグルを選択します。
-
Edit steps or synthetic transactionsを選択します。
-
[Go to url] というタイプのステップを追加し、[URL] にターゲットの認証ページの URL を入力します。
-
ログインが成功したことを確認するために、Assert text presentというタイプのステップを追加し、以下のように設定します:
-
Textには、ログインが成功した場合にのみテスト対象ページに表示される文字列を入力します。
-
(オプション)ページが確実にロードされるように、Wait for up toをミリ秒単位で十分に大きな値に設定します。
-
-
Submitを選択します。
ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。
APIリクエストヘッダーによる基本認証
curl -G https://api.twilio.com/2010-04-01/Accounts.json -u <YOUR_ACCOUNT_SID>:<YOUR_AUTH_TOKEN> などの API メソッドをサポートするターゲット用です。ベアラートークンをサポートするターゲットに対して、これらの手順を変更できます。
テスト対象がAPIリクエストヘッダーにログイン認証情報が含まれることを期待している場合、ブラウザテストを以下のように設定します。
-
テストターゲットのユーザー名とパスワードの組み合わせを base64 エンコードした文字列を取得します。base64 エンコードされた文字列を取得する方法はいくつかあります。例:
-
ブラウザのコンソールから JavaScript 関数 btoa を実行します:
btoa("myusername:mypassword") -
Linuxのターミナルでこのコマンドを実行します:
echo -n 'myusername:mypassword' | base64
-
-
base64 値を隠されたグローバル変数に格納します。詳細については、「グローバル変数」を参照してください。
-
API テストの設定ページで、テスト内の既存のリクエストを選択するか、[Add requests] を選択します。
-
Requestセクションを展開し、以下の情報を入力します:
-
[URL] に、テストターゲットの URL を入力します。
-
Add request header を選択します。
-
[Authorization] ヘッダーを選択し、その値として [
Basic] という単語を入力してから半角スペースを入れ、base64 でエンコードされたユーザー名とパスワードを結合したグローバル変数の名前を入力します。変数には、先頭にenv.を付け、二重中括弧で囲む必要があります。たとえば、{{env.est1_base64_auth}}のようになります。使用可能なグローバル変数のリストを表示するには、右側のペインを展開します。
-
-
Submit を選択します。
ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。
SMSによる多要素認証
テストターゲットが多要素認証のために SMS を通じてワンタイムパスコード(OTP)を送信する場合、ブラウザテストは SMS メッセージから OTP を取得し、テストターゲットのページの入力フィールドに入力する必要があります。これを行うには、ブラウザテストを次のように設定します。
前提条件
-
仮想電話番号
SMS を介して認証に行うには、 SMS を介してワンタイムパスコードを受信できる仮想電話番号が必要です。複数のサービスが仮想電話番号を提供しており、Sinch サービス のように API を介して SMS の内容を取得できます。 このサービスを介してメッセージを受信する方法については、「Sinch API」を参照してください。
Twilio などの特定のサービスでは、OTP を含む着信 SMS メッセージがブロックされる場合があります。詳細については、Twilio の「OTP Message Body Filtered」ドキュメントを参照してください。
-
SMS通知
認証プロセスを強化するには、GitHubのような、SMS 通知を送信するサービスが必要です。
制限事項
コンテンツ セキュリティ ポリシー(CSP)の違反により、合成テスト中に一部のサービスにアクセスできない場合があります。このような場合の回避策は、サーバーにサードパーティサービスを実装し、connect-src を許可するように CSP で設定されたエンドポイントを提供することです。
-
ブラウザテストの設定ページで、[Simple] トグルを選択します。
-
Edit steps or synthetic transactions を選択します。
-
[Go to url] というタイプのステップを追加し、[URL] にターゲットの認証ページの URL を入力します。
-
[Save return value from JavaScript] というタイプのステップを追加し、[code] フィールドに、次の JavaScript を貼り付けます。このスクリプトは、
XMLHttpRequestを使用して指定された URL からデータを取得し、そのデータから OTP を抽出します。この OTP をotpという名前のグローバル変数に保存するようにテストを設定します。注: スクリプトの中で、変数 url に自分の仮想電話番号の SMS サービスの URL を設定します。JAVASCRIPTfunction getOtp() { const url = "https://your-page.example.com/sms"; var request = new XMLHttpRequest(); request.open("GET", url, false); request.send(); if (request.status == 200) { return parseOtp(JSON.parse(request.responseText)); } return; } function parseOtp(jsonResponse) { const firstInbound = jsonResponse.inbounds[0]; if (firstInbound && firstInbound.body) { // Extract the number using a regular expression const match = firstInbound.body.match(/\\b\\d{6}\\b/); if (match) { return match[0]; // Return the first matched number } } return; } return getOtp(); -
[Wait] というタイプのステップを追加し、待ち時間をミリ秒単位で指定します。この時間は、ターゲットが仮想電話番号に OTP コードを送信し、JavaScript が OTP を処理するのに十分な時間である必要があります。
-
Fill in fieldというタイプのステップを追加し、以下のように設定します:
-
Selectorには、ユーザーがOTPを入力するターゲットページのエレメントのIDを入力します。
-
[Value] には、JavaScript が OTP を格納したカスタム変数名に、custom. を先頭に付け、二重中括弧で囲んで入力します。たとえば、
{{custom.otp}}のようになります。
-
-
ログインが成功したことを確認するために、Assert text presentというタイプのステップを追加し、以下のように設定します:
-
Textには、ログインが成功した場合にのみテスト対象ページに表示される文字列を入力します。
-
(オプション)ページが確実にロードされるように、Wait for up toをミリ秒単位で十分に大きな値に設定します。
-
-
Submit を選択します。
ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。
メールによる多要素認証
テストターゲットが多要素認証のために電子メールを通じてワンタイムパスコード(OTP)を送信する場合、ブラウザテストは電子メールのメッセージから OTP を取得し、テストターゲットのページの入力フィールドに入力する必要があります。これを行うには、ブラウザテストを次のように設定します。
前提条件
電子メールアカウントへの接続および API を介した電子メールの管理をサポートする電子メールサービスが必要です。以下の手順では、Nylas サービス を使用する例を示します。このサービスからメッセージを取得する方法の詳細については、「API ドキュメント」を参照してください。
さらに、以下のステップでは、GitHub を使用して認証メールを送信することを示します。この認証メールは、認証メールから OTP を抽出するために不可欠です。
制限事項
電子メールサービスは API を介してアクセスできる必要があります。コンテンツ セキュリティ ポリシー(CSP)の違反により、合成テスト中に一部のサービスにアクセスできない場合があります。このような場合の回避策は、サードパーティのサービスをサーバーに実装し、connect-src を許可するように CSP で設定されたエンドポイントを提供することです。
-
ブラウザテストの設定ページで、[Simple] トグルを選択します。
-
Edit steps or synthetic transactions を選択します。
-
[Go to url] というタイプのステップを追加し、[URL] にターゲットの認証ページの URL を入力します。
-
[Save return value from JavaScript] というタイプのステップを追加し、[code] フィールドに、次の JavaScript を貼り付けます。このスクリプトは、
XMLHttpRequestを使用して指定された URL からデータを取得し、そのデータから OTP を抽出します。この OTP をotpというカスタム変数に保存するようにテストを設定します。注: スクリプトの中で、変数urlを自分のメール受信箱APIエンドポイントのURLに設定します。注: Nylas サービスを利用している場合、件名やその他のパラメータで特定のテキストを検索することで、未読メールを見つけることができます。詳細については、「Nylas API documentation for messages」を参照してください。JAVASCRIPTfunction getOtp() { const grantId = "<NYLAS_GRANT_ID>"; const jwToken = "<NYLAS_API_KEY>"; const from = "noreply@github.com"; const subject = "Your GitHub launch code"; const unread = "true"; const url = "https://api.us.nylas.com/v3/grants/" + grantId + "/messages?limit=1&unread=" + unread + "from=" + from + "&subject=" + subject; var request = new XMLHttpRequest(); request.open("GET", url, false); request.setRequestHeader('Authorization', 'Bearer ' + jwToken) request.send(); if (request.status == 200) { return parseOtp(JSON.parse(request.responseText)); } return "ERR"; } function parseOtp(jsonResponse) { const firstInbound = jsonResponse. data[0]; if (firstInbound && firstInbound.snippet) { // Extract the number using a regular expression const match = firstInbound.snippet.match(/\\b\\d{8}\\b/); if (match) { return match[0]; // Return the first matched number } } return "NO-OTP"; } return getOtp(); -
[Wait] というタイプのステップを追加し、待ち時間をミリ秒単位で指定します。この時間は、ターゲットが電子メールサービスに OTP コードを送信し、JavaScript が OTP を処理するのに十分な時間である必要があります。
-
Fill in fieldというタイプのステップを追加し、以下のように設定します:
-
Selectorには、ユーザーがOTPを入力するターゲットページのエレメントのIDを入力します。
-
[Value] には、JavaScript が OTP を格納したカスタム変数名に、custom. を先頭に付け、二重中括弧で囲んで入力します。たとえば、
{{custom.otp}}のようになります。
-
-
ログインが成功したことを確認するために、Assert text presentというタイプのステップを追加し、以下のように設定します:
-
Textには、ログインが成功した場合にのみテスト対象ページに表示される文字列を入力します。
-
(オプション)ページが確実にロードされるように、Wait for up toをミリ秒単位で十分に大きな値に設定します。
-
-
Submit を選択します。
ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。
SSOとActive Directoryによる多要素認証
シングルサインオン(SSO)による認証は、基本認証に似ています。SSO または Active Directory(AD)を使用するテストを作成するには、 Web ページを開き、SSO 認証リンクを選択して、SSO 認証に必要な情報を入力する一連の手順を設定する必要があります。このプロセス中に追加の Web ページがロードされる可能性があるため、次の手順に進む前に、各 Web ページのすべてのコンポーネントが完全にロードされたことを確認する手順を含めることが重要です。
SSO 認証では、追加の認証要素が必要になることがよくあります。ID プロバイダー(Google、Microsoft、Okta、Duo など)が追加のログイン要素を義務付けていない場合、テストは以下の例で示される認証ステップだけで済む可能性があります。
制限事項
ID プロバイダーは、電子メール、 SMS 、TOTP を介した検証など、ログインに対してさまざまな追加の要因を必要とすることがよくあります。このような場合、これらの追加のログイン要素に対応するために手順を変更または追加することが重要です。
TOTPによる多要素認証
テストターゲットに時間ベースのワンタイムパスコード(TOTP)を送信する必要がある場合は、以下のように設定します。
TOTPを生成するための秘密鍵を取得します。
秘密鍵は、テストターゲットとテスト認証アプリ(Okta など)の両方が、同じ一意の TOTP を生成するために使用する共有値です。この秘密鍵は、次の場所から取得できます。
-
テストターゲットの QR コード(画像)。
-
プレーンテキストの秘密鍵。QR コードを URL 文字列として表示したときに、テストターゲットの QR コードに埋め込まれた文字列として表示されます。たとえば、QR コードが
otpauth://totp/Slack:<username>@<somedomain>?secret=<long-string>&issuer=<app-name>&algorithm=SHA1&digits=6&period=30の場合、秘密鍵は<long-string>になります。
秘密鍵をタイプTOTPのグローバル変数に保存します。
グローバル変数を作成するには2つの方法があります:
-
Splunk Synthetic Monitoringランディングページから:
-
Splunk Synthetic Monitoringランディングページから、設定アイコンを選択し、Global variablesを選択します。
-
Create variable を選択します。
-
-
既存のテストのページから:
-
Edit test を選択します。
-
右側のVariablesパネルを展開し、Global variablesまでスクロールして、Addを選択します。
-
Add variableダイアログボックスで、次のように入力します:
-
[Variable type] プルダウンメニューで、[TOTP] を選択します。
-
[Variable name] フィールドに変数の名前を入力します。この名前を使用して、テスト内で変数にアクセスします。
-
秘密鍵は以下のいずれかの方法で保存します:
-
QR codeタブを選択し、そこにQRコード画像をドラッグします。
-
Manual inputタブを選択し、QRコードから取得した
<long-string>を貼り付けます。
-
-
(オプション)[Description] フィールドに、後で参照するために変数の目的を説明する文を入力します。説明は、変数を隠してその値を明らかにできない場合に特に役立ちます。
-
(オプション)Advanced Settingsを展開し、オプション設定を指定します:
-
(オプション)[digits] に、生成される TOTP の桁数を設定します。有効な値:4 ~ 8。デフォルト: 6。
-
(オプション)[TOTP expiration] に、TOTP の有効期間を秒単位で設定します。有効な値:10 秒 ~ 90 秒。デフォルト:30 秒。
-
-
(オプション)入力した秘密鍵を検証するには、Generate TOTPを選択します。
-
Add を選択します。
TOTP を使用してブラウザテストを設定
-
ブラウザテストの設定ページで、[Simple] トグルを選択します。
-
Edit steps or synthetic transactions を選択します。
-
[Fill in field] というタイプのステップを追加し、[Value] で、[TOTP] セクションまでスクロールダウンし(または検索フィールドに
totpと入力し)、作成した TOTP 変数の名前を選択します。{{totp.<variable-name>}}としてこの変数名を直接入力することもできます。 -
ログインが成功したことを確認するために、Assert text presentというタイプのステップを追加し、以下のように設定します:
-
Textには、ログインが成功した場合にのみテスト対象ページに表示される文字列を入力します。
-
(オプション)ページが確実にロードされるように、Wait for up toをミリ秒単位で十分に大きな値に設定します。
-
-
Submit を選択します。
ログインが機能していることを確認するには、[Try now] を選択します。結果が出るまでしばらく時間がかかる場合があります。[Try now result] ペインには、対象ページでテストがナビゲートした各画面と、メッセージ [Success] が表示されます。
mTLS 認証
相互 TLS(mTLS)認証は、クライアント(プライベートランナーまたはパブリックランナー)と Web サーバー(テストターゲット)の両方が接続を検証するための方法です。mTLS では、クライアントとサーバーの両方に証明書があり、双方がその証明書の公開キー/秘密キーのペアを使用して認証を行います。mTLS 認証を成功させるには、次の手順を実行します。
クライアント証明書を CERT タイプのグローバル変数に保存
これらの手順は、テストターゲットのクライアント証明書がすでにダウンロードされていることを前提としています。
グローバル変数を作成するには2つの方法があります:
-
Splunk Synthetic Monitoringランディングページから:
-
Splunk Synthetic Monitoringランディングページから、設定アイコンを選択し、Global variablesを選択します。
-
Create variable を選択します。
-
-
既存のテストのページから:
-
Edit test を選択します。
-
右側のVariablesパネルを展開し、Certificatesまでスクロールして、Addを選択します。
-
Add variableダイアログボックスで、次のように入力します:
-
[Variable type] プルダウンメニューで、[CERT] を選択します。
-
[Variable name] フィールドに変数の名前を入力します。この名前を使用して、テスト内で変数にアクセスします。
-
[Domain] フィールドに、テストターゲットの正確なドメインを入力します。たとえば、テストターゲットが
client.badssl.comの場合は、[Domain] をclient.badssl.comに設定します。[Domain] をbadssl.comに設定すると、ブラウザテストで mTLS 認証がタイムアウトエラーで失敗します。エラーが表示されるまでに最大 2 分かかる場合があります。[Domain] では、次のようなワイルドカードを使用できます。
*.example.comexample.**.example.**.*.**.*.*.example/**.*.*/*
-
クライアント証明書が PCKS#12 形式の場合は、まず、.pem 形式に変換します。
-
証明書と一致する方法を使用して、クライアント証明書をアップロードします。
-
証明書の公開キーと秘密キーが別々のファイルになっている場合は、[Upload Public Key] タブを選択し、ウィジェットに公開キーファイルをドラッグします。次に、[Upload Private Key] を選択し、秘密キーファイルをウィジェットにドラッグします。
-
証明書が、公開キーと秘密キーの両方を含む結合ファイルの場合は、[Upload Combined Key] タブを選択し、結合ファイルをウィジェットにドラッグします。
-
-
前の手順でアップロードした結合ファイルまたは秘密キーが暗号化されている場合は、その復号パスワードを [Private key password] フィールドに貼り付ける必要があります。Splunk Synthetics はこのパスワードを使用してファイルを 1 回開きますが、復号パスワードは保持されません。
-
(オプション)[Description] フィールドに、後で参照するために変数の目的を説明する文を入力します。説明は、変数を非表示にする場合に特に役立ちます。
-
Add を選択します。
クライアント証明書は、暗号化された形式で Splunk Synthetics データベースに安全に保存されます。
.p12 を .pem に変換
-
システムに OpenSSL をインストールします。
-
Linux では、通常、事前にインストールされています。インストールされていない場合は、パッケージマネージャを使用してインストールします。たとえば、Ubuntu では、
apt install opensslというコマンドを実行します。 -
macOS では、
brew install opensslというコマンドを実行します。 -
Windows では、OpenSSL バイナリをダウンロードするか、Chocolatey などのパッケージマネージャを使用します。
-
-
証明書の暗号化アルゴリズムと一致する次のコマンドを実行します。
-
証明書が標準規格(レガシー以外)のアルゴリズムで暗号化されている場合は、次のコマンドを実行します。
CODEopenssl pkcs12 -in input.p12 -out output.pem -aes256 -passin pass:your-p12-password値は次のとおりです。
- input.p12 は、入力となる PKCS#12 ファイルです。
- output.pem は、出力される PEM ファイルです。
- new-password は、.p12 ファイルの作成時に生成したパスワードです。
例:
CODEopenssl pkcs12 -in in-cert.p12 -out out-cert.pem -aes256 -passin pass:ABC123@GL -
OpenSSL 3.0+ を使用していて、証明書が RC2-40-CBC などのレガシーアルゴリズムで暗号化されている場合は、
opensslコマンドを-legacyオプションを付けて実行します。このオプションは、OpenSSL 3.0 以降でデフォルトでは非アクティブ化されている古い暗号化アルゴリズムのサポートを有効にします。CODEopenssl pkcs12 -legacy -in input.p12 -out output.pem -nodes値は次のとおりです。
- input.p12 は、入力となる PEM ファイルです。
- output.pem は、出力される PEM ファイルです。
結果として得られる .pem ファイルには、秘密キーと証明書の両方が含まれています。
-
-
秘密キーと証明書を個別に保存する必要がある場合は、次のコマンドを実行して抽出します。
-
秘密キーを抽出するには:
CODEopenssl pkey -in output.pem -out private-key.pem -
証明書を抽出するには:
CODEopenssl x509 -in output.pem -out certificate.pem
-
プライベートランナーの設定
-
tmpfs mount コマンド(または同様のコマンド)を使用して、プライベートランナーがテストの実行中にクライアント証明書を一時的に保存するために使用する次のフォルダをマウントします。
-
/tmpfs/certificates(アップタイムおよび API テストで使用)
-
/home/geppetto/.pki(ブラウザのテストで使用)
これらのフォルダに tmpfs ファイルシステムを使用すると、クライアント証明書をインスタンスディスクに保存せずに済みます。証明書をディスクに保存しないことで、テストの実行中に証明書をディスクドライブのバックアップに誤って含めるリスクを回避できます。
-
-
プライベートランナーが Docker 上にある 場合は、次の環境変数を docker run コマンドに追加します。
CODE-e "ENABLE_CLIENT_CERTS=true" -
プライベートランナーが Docker Compose 上にある 場合は、次の環境変数を docker-compose.yml コマンドに追加します。
CODEenvironment: ... ENABLE_CLIENT_CERTS: true
mTLS を使用してブラウザテストを設定
-
ブラウザテストの設定ページで、[Advanced] トグルを選択します。
-
[Security] セクションまで下にスクロールします。
-
[TLS/SSL validation] トグルを [On] に設定します。
-
[Certificate] プルダウンメニューで、クライアント証明書用に作成した
CERTグローバル変数を選択します。たとえば、{{cert.Badssl_com-test2}}のようになります。
mTLS を使用したアップタイム(HTTP)テストの設定
-
HTTP テストの設定ページで、[Security] セクションまで下にスクロールします。
-
[TLS/SSL validation] トグルを [On] に設定します。
-
[Certificate] プルダウンメニューで、クライアント証明書用に作成した
CERTグローバル変数を選択します。たとえば、{{env.est1_base64_auth}}のようになります。すべてのCERT変数の一覧を表示するには、右側のペインを展開します。 -
Submit を選択します。
mTLS を使用した API テストの設定
クライアント証明書を必要とする各 API リクエストに、証明書を追加できます。その場合は次の手順に従ってください。
-
API テストの設定ページで、テスト内の既存のリクエストを選択するか、[Add requests] を選択します。
-
[Request] セクションを展開します。
-
Add request header を選択します。
-
[Select certificate] ドロップダウンメニューで、作成済みの
CERT変数を選択します。たとえば、{{env.est1_base64_auth}}のようになります。すべてのCERT変数の一覧を表示するには、右側のペインを展開します。 -
[Submit] を選択します。
Basic authentication through HTML login forms
Configure your browser test with basic authentication through an HTML login form.
If your test target provides an HTML form for entering username and password, configure your browser test as follows.
To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.
Basic authentication through HTTP headers
Configure your browser test with basic authentication through an HTTP header.
If your test target expects login credentials to be included in an HTTP header, configure your browser test as follows.
To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.
Basic authentication through API request headers
Configure your API test with basic authentication through an API request header.
curl -G https://api.twilio.com/2010-04-01/Accounts.json -u <YOUR_ACCOUNT_SID>:<YOUR_AUTH_TOKEN>. You can modify these steps for targets that support a bearer token.
If your test target expects login credentials to be included in an an API request header, configure your browser test as follows.
To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.
Multifactor authentication through SMS
Configure your browser test with multifactor authentication through SMS.
If your test target sends a one time passcode (OTP) through SMS for multifactor authentication, your browser test must retrieve the OTP from the SMS message and enter it into the input field on the target’s page. To do this, configure your browser test as follows.
-
Virtual phone number
To authenticate through SMS, you must have a virtual phone number that can receive one time passcodes through SMS. Several services offer virtual phone numbers and provide SMS content through an API, such as the Sinch service . For instructions on receiving messages through this service, see the Sinch API .
Certain services, such as Twilio, may block incoming SMS messages containing OTPs. For more information, see Twilio's OTP Message Body Filtered documentation.
-
SMS notifications
To enhance the authorization process, you must have a service that sends SMS notifications, such as GitHub .
- Limitations
-
Some services may not be accessible during Synthetics tests due to violations of Content-Security-Policy (CSP). In such instances, a workaround is to implement third-party services on your server and provide an endpoint configured with CSP to allow
connect-src.
To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.
Multifactor authentication through email
Configure your browser test with multifactor authentication through email.
If your test target sends a one-time passcode (OTP) through email for multifactor authentication, your browser test must retrieve the OTP from the email message and enter it into the input field on the target’s page. To do this, configure your browser test as follows.
You must have an email service that supports connecting to your email account and managing your emails through an API. The steps below feature an example using the Nylas service . For detailed information on how to retrieve messages from this service, refer to its API documentation .
Additionally, the steps below demonstrate the use of GitHub to send an authorization email, which is essential for extracting the OTP from it.
- Limitations
-
Your email service must be accessible through an API. Some services may not be accessible during Synthetics tests due to violations of Content-Security-Policy (CSP). In such instances, a workaround is to implement third-party services on your server and provide an endpoint configured with CSP to allow connect-src.
To verify that the login is working, select Try now. Results may take a while. The Try now result pane should display each screen that your test navigated to on the target page, plus the message Success.
Multifactor authentication through SSO and Active Directory
Configure your test with multifactor authentication through SSO and Active Directory.
Authentication through Single Sign-On (SSO) is similar to basic authentication. To create a test that uses SSO or Active Directory (AD), you must configure a series of steps that include opening the webpage, selecting the SSO authentication link, and entering the required information for SSO authentication. Additional webpages may load during this process, so it’s crucial that you include steps to confirm that all of the components of each webpage have fully loaded before proceeding.
SSO authentication frequently involves additional authentication factors. If the identity provider (such as Google, Microsoft, Okta, Duo, and so on) does not mandate an extra login factor, your test might only need the authentication steps that are illustrated in the example below.
- Limitations
-
Identity providers often require various additional factors for login, such as verification via email, SMS, or TOTP. In such cases, it is essential to modify or add steps to accommodate these additional login factors.
- Add a step for selecting the webpage.
- Add a step for selecting the SSO authentication link.
- Enter the required information for SSO authentication.
- Add steps to confirm that all of the components of each webpage have fully loaded before proceeding.
Multifactor authentication through TOTP
Configure your browser test with multifactor authentication through TOTP.
If your test needs to send a time-based one-time passcode (TOTP) to its test target, configure your test as follows.
mTLS authentication
Configure your test for mTLS authentication.
Mutual TLS (mTLS) authentication is a method for a client (your private or public runner) and a web server (your test target) to both validate their connection. In mTLS, both the client and the server have a certificate, and both sides authenticate using their certificate's public/private key pair. Follow these steps to make sure that the mTLS authentication succeeds:
-
Save the client certificate in a global variable of type
CERT. -
Configure your test to reference the
CERTvariable.
Step 1: Save the client certificate in a global variable of type CERT
These steps assume that you've already downloaded the client certificate that matches the one on the test target.
There are two ways to create a global variable:
-
From the Splunk Synthetic Monitoring landing page:
-
From the Splunk Synthetic Monitoring landing page, select the settings icon, and then select Global variables.
-
Select Create variable.
-
-
From an existing test’s page:
-
Select Edit test.
-
Expand the Variables panel on the right, scroll to Certificates and select Add.
-
In the Add variable dialog box, enter the following:
-
In the Variable type pull-down menu, select CERT.
-
In the Variable name field, enter the name of the variable. You will use this name to access your variable within a test.
-
In the Domain field, enter the exact domain of the test target. For example, if the test target is
client.badssl.com, set Domain toclient.badssl.com. If you set Domain tobadssl.comthe mTLS authentication will fail with a timeout error in browser tests. The error might take up to two minutes to appear.You can use wildcards in Domain, such as:
*.example.comexample.**.example.**.*.**.*.*.example/**.*.*/*
-
If your client certificate is in PCKS#12 format, convert it into .pem format first:
-
Install OpenSSL on your system:
-
On Linux, it's typically pre-installed. If not, use your package manager to install it. For example, on Ubuntu, run the command
apt install openssl -
On macOS, run the command
brew install openssl -
On Windows, download the OpenSSL binary or use a package manager like Chocolatey.
-
-
Run the command below that matches your certificate's encryption algorithm:
-
If your certificate was encrypted with a standard (non-legacy) algorithm, run this command:
CODEopenssl pkcs12 -in input.p12 -out output.pem -aes256 -passin pass:your-p12-passwordwhere:
- input.p12 is the input PKCS#12 file.
- output.pem is the output PEM file.
- new-password is the password that was generated when the .p12 file was created.
For example:
CODEopenssl pkcs12 -in in-cert.p12 -out out-cert.pem -aes256 -passin pass:ABC123@GL -
If you're using OpenSSL 3.0+ but your certificate was encrypted with a legacy algorithm such as RC2-40-CBC, run the
opensslcommand with the-legacyoption. This option enables support for older encryption algorithms which are deactivated by default in OpenSSL 3.0 and later:CODEopenssl pkcs12 -legacy -in input.p12 -out output.pem -nodeswhere:
- input.p12 is the input PEM file.
- output.pem is the output PEM file.
The resulting .pem file contains both the private key and the certificate.
-
-
If you need to save the private key and the certificate separately, run these commands to extract them:
-
To extract the private key:
CODEopenssl pkey -in output.pem -out private-key.pem -
To extract the certificate:
CODEopenssl x509 -in output.pem -out certificate.pem
-
-
-
Upload the client certificate using the method that matches your certificate:
-
If your certificate has separate files for its public key and private key, select the Upload Public Key tab and drag the public key file into the widget. Then select Upload Private Key and drag the private key file into the widget.
-
If your certificate is a combined file containing both its public and private keys, select the Upload Combined Key tab and drag the combined file into the widget.
-
-
If the combined file or private key that you uploaded in the previous step was encrypted, you must paste its decryption password into the Private key password field. Splunk Synthetics uses this password to open the file once; it does not retain your decryption password.
-
(Optional) In the Description field, enter a description to explain the purpose of the variable for future reference. A description is particularly helpful when you conceal the variable.
-
Select Add.
The client certificate is securely stored in the Splunk Synthetics database in an encrypted format.
Step 2: Configure your private runner
-
Use the tmpfs mount command (or similar) to mount the following folders which are used by the private runner to store the client certificate temporarily while it's running a test:
-
/tmpfs/certificates (used during uptime and API tests)
-
/home/geppetto/.pki (used during browser tests)
Using the tmpfs file system for these folders helps you to avoid storing the client certificates on the instance disk. By not storing the certificates on disk you avoid accidentally including them in a disk drive backup if one were to occur while a test is running.
-
-
If your private runner is on Docker, add the following environment variable to your docker run command:
CODE-e "ENABLE_CLIENT_CERTS=true" -
If your private runner is on Docker Compose, add the following environment variable to your docker-compose.yml:
CODEenvironment: ... ENABLE_CLIENT_CERTS: true
Step 3: Configure your test to reference the CERT variable
- Browser
-
Note: Make sure that the domain of the selected certificate matches the domain of the page being tested
-
On the browser test’s configuration page, select the Advanced toggle.
-
Scroll down to the Security section.
-
Set the TLS/SSL validation toggle to On.
-
In the Certificate pull-down menu, select the
CERTglobal variable you created for the client certificate. For example,{{cert.Badssl_com-test2}}.
-
- Uptime (HTTP)
-
-
On the HTTP test’s configuration page, scroll down to the Security section.
-
Set the TLS/SSL validation toggle to On.
-
In the Certificate pull-down menu, select the
CERTglobal variable you created for the client certificate. For example,{{env.est1_base64_auth}}. To see the list of allCERTvariables, expand the pane on the right. -
Select Submit.
-
- API
-
You can add a client certificate to each API request that needs one. To do this, follow these steps:
-
On the API test’s configuration page, select an existing request in the test or select Add requests.
-
Expand the Request section.
-
Select Add request header.
-
In the Select certificate drop-down menu, select a
CERTvariable you've already created. For example,{{env.est1_base64_auth}}. To see the list of allCERTvariables, expand the pane on the right. -
Select Submit.
-
NTLM authentication
Configure your browser test with NTLM authentication.
NTLM (NT LAN Manager) is a challenge-response authentication protocol used in Windows environments. It allows browser tests to authenticate against web servers that require Windows credentials without needing special infrastructure.
NTLM authentication is supported on both public runners and private runners.
- Limitations
-
-
HTTP/2 not supported: NTLM requires a persistent TCP connection for the multi-step handshake. HTTP/2 multiplexing breaks this requirement. If your web server uses HTTP/2, NTLM authentication will fail. Ensure your server supports HTTP/1.1 fallback.
-
Browser tests only: NTLM authentication is not available for API or Uptime (HTTP) tests.
-
HAR capture: The initial 401 authentication response may not appear in the HAR file. The final authenticated response is captured normally.
-
-
A concealed global variable containing the username
-
A concealed global variable containing the password
-
The target website must use HTTP/1.1 (NTLM is not compatible with HTTP/2)
To configure a browser test with NTLM authentication:
- Create or edit a browser test.
- In the Advanced section, find the Authentication configuration.
- Enter your username in the format DOMAIN\username or username@domain.com
- Enter your password.
- Use concealed global variables for both username and password to keep credentials secure.
The Synthetics runner automatically passes these credentials to the Chromium browser, which handles the NTLM challenge-response handshake transparently.
Kerberos authentication
Configure your browser test with Kerberos authentication.
Kerberos is a ticket-based authentication protocol that uses a central key distribution center (KDC) to issue authentication tickets. It provides stronger security than NTLM but requires more infrastructure.
- Why Kerberos requires a private runner
- Kerberos authentication requires network access to your organization's Key Distribution Center (KDC), typically an Active Directory domain controller. Since the KDC is inside your organization's network and not accessible from the internet, public runners cannot reach it. Only private runners deployed within your network can access the KDC.
- Limitations
-
-
Private runner only: Kerberos cannot work on public runners because the KDC is not accessible from the internet.
-
Custom Docker image required: The standard Synthetics runner image does not include Kerberos client libraries.
-
Browser tests only: Kerberos authentication is not available for API or uptime (HTTP) tests.
-
Ticket expiration: Kerberos tickets expire (typically 8-24 hours). Ensure your runner has a mechanism to renew tickets before they expire.
-
Time synchronization: Clock skew between the runner and KDC must be less than 5 minutes. Configure NTP on your runner host.
-
Not officially supported as a custom build: Splunk supports the standard runner image. Custom images with Kerberos are a customer-managed configuration.
-
To use Kerberos authentication with a private runner, you need:
-
A private runner deployed within your network, with access to:
-
Your KDC (typically port 88/TCP and 88/UDP)
-
DNS servers that can resolve your Kerberos realm
-
-
A custom runner Docker image with Kerberos client libraries installed
-
A krb5.conf configuration file mapping your Kerberos realm to your KDC
-
Credentials for obtaining Kerberos tickets:
-
A keytab file (recommended for automated use), or
-
A username and password for
kinit
-
-
NTP synchronization: The runner's clock must be synchronized within 5 minutes of the KDC's clock