AWS IAM Identity Center をIdP としてDatadog のSAML JIT プロビジョニングとGroup Mapping を設定してみた
こんにちは、なおにしです。
Datadog でSAML 2.0 を使用したジャストインタイム（JIT）プロビジョニングを検証する機会がありましたのでご紹介します。
はじめに
Datadog を企業の複数部門で活用するような場合、ガバナンス施策としてMulti Organization 機能によって親組織と子組織を構成し、親組織から複数の子組織の利用状況を管理するケースもあるかと思います。
このような場合、親組織の管理チームが各子組織にログインし、管理権限によって各種設定をするというような運用も想定されます。
Datadog で子組織を作成すると、作成操作を実施した親組織のユーザーが子組織の管理ユーザーとして登録されます。子組織を作成したユーザーは、通常のDatadog 組織遷移と同じ操作で、操作対象の組織を切り替えることができます。
一方、Datadog のMulti Organization 機能では、AWS でいうところのOrganizationAccountAccessRole を使用したメンバーアカウントへのスイッチロールでのアクセスというような操作ができません。
つまり、親組織の管理チームとして複数の管理ユーザーが存在していても、子組織を作成した直後では作成した本人しか子組織にアクセスすることはできません。管理チームに所属する全員が子組織にアクセスできるようにするためには、子組織で全員を招待する必要があります。
子組織が少なければ、作成直後に対象者のメールアドレスを全て列挙して一括招待するという方法でも良いかとは思います。ですが、例えば子組織が増えてきた後に、管理チームにメンバーの増員があった場合はどうすれば良いでしょうか。全ての子組織で新メンバーを追加で招待する、または子組織での操作が必要になったタイミングで、既存のメンバーから招待してもらうといった運用が想像できます。子組織の数に比例して運用負荷が高まりそうです。
極論(暴論)としてadminのような管理アカウントを作成して複数のメンバーで使い回すという方法もありますが、当然こちらは監査やセキュリティ、コンプライアンスといった観点で完全に非推奨です。
ではどうするかということで、子組織が一定数増える場合という前提で、子組織作成時の初期設定でSAML 2.0 によるシングルサインオン(SSO)を設定することを検討します(※)。
今回はSAML 2.0 のIdP として、AWS IAM Identity Center を利用します。IAM Identity Center はSAML 2.0 のIdP として無料で利用可能ですが、当該用途で使用する場合はIAM Identity Center をAWS Organizations 管理アカウントのインスタンスで使用する必要があることにご注意ください。
なお、同様の取り組みは以下の弊社記事でも紹介されております。
概要やDatadog とIAM Identity Center の連携手順は上記の記事にまとまっていますので、本記事では割愛させていただきます。
違いとしては、本記事では「ジャストインタイム（JIT）プロビジョニング」を取り扱います。併せて、Group Mapping 機能によってSAML ログイン時に自動的にチームとロールを設定してみます。
※ 補足
より推奨されるのはSCIM (System for Cross-domain Identity Management) の適用かと思いますが、Datadog ではSCIM のIdP としてMicrosoft Entra ID と Okta のみをサポートしており、いずれもSCIM での利用には組織的/料金的な意味合いで導入ハードルが高めということもあり、今回は検討から除外しました。
SAML 2.0 のJIT プロビジョニングでは、Datadog 組織への初めてのログイン時にユーザーが作成はされますが、IdP 側でユーザーを削除したとしてもDatadog 組織では削除/無効化されません。ユーザーのプロビジョニングを自動化(同期)させる仕組みを実現するのはSCIM であり、SAML 2.0 が提供するのはあくまでSSO です。
このため、ユーザー作成の効率化を図ることはできますが、ユーザーの無効化については各Datadog 組織で個別に対応が必要です。なお、Datadog ではユーザーの削除はそもそも機能として提供されておらず、無効化操作のみが可能です。
既存のメンバーを無効にする
メンバーを無効にできるのは、Datadog Admin Role を持つユーザーなど、Access Management アクセス許可を持つユーザーのみです。ユーザーがダッシュボードまたはモニターを作成した可能性があるため、ユーザーを完全に削除することはできません。ユーザー ID は、ユーザーのアクションの記録を保持するために使用されます。ユーザーが無効になると、ユーザーが生成したアプリケーションキーは自動的に取り消されます。
また、SAML 2.0 によるIdP と Datadog 組織の信頼関係の確立作業は、子組織作成の都度必要となります。こちらはMulti Organization 機能のドキュメントにも明記されており、その他にもログイン方法としてSSO のみを有効にしているDatadog 組織での注意事項も記載されていますので、併せてご参照ください。
SAML セットアップは、親オーガニゼーションから子オーガニゼーションへ継承 されません。各子オーガニゼーションで個別に SAML が構成される必要があります。
やってみた
事前準備
前述の記事に記載の流れに従い、IAM Identity Center のカスタマーマネージドアプリケーションにDatadog アプリケーションカタログを使用してアプリケーションを追加します。
アプリケーションの表示名はIAM Identity Center のアクセスポータルで使用されるので、Datadog の複数組織を管理することを考えるとDatadog 組織名やグルーピングのための識別子のような名前を付与しておくと便利そうです。
JIT プロビジョニングによるDatadog ログイン
JIT プロビジョニングを使用するにあたって追加で設定が必要な箇所は以下2つです。
- Datadog 組織のOrganization Settings 内のJIT プロビジョニングに関する設定
- SAML 2.0 の属性マッピングに関する設定
Datadog 組織のOrganization Settings 内のJIT プロビジョニングに関する設定
[Organization Settings] - [Login Methods] - [SAML] より、以下の部分を設定します。
Assign Role to auto-created usersは、JIT プロビジョニングで作成されたユーザーに割り当てるロールの指定です。デフォルトロールだけではなくカスタムロールも割り当て可能ですが、今回はDatadog Admin Roleを指定します。
Domains for Just-in-Time provisioningでは、JIT プロビジョニングの対象とするドメインを指定します。画面表示されている内容(以下和訳)に従います。
含めたいプロバイダーのドメインを追加し、アクセス権を持つべきでないユーザーに対してDatadogへのアサーションが行われないよう、IdPを適切に設定してください。ドメインに「@」記号は含めないでください。
例：yourcompany.com のすべてのユーザーに対して、Datadog で個別にユーザーアカウントを作成することなくアクセスを許可したい場合に使用します。
SAML 2.0 の属性マッピングに関する設定
まず、今回作成した直後のDatadog アプリケーションの設定を見てみます。
アプリケーションカタログからDatadog を選択しているため、以下のように既に属性マッピングが設定されています。ただ、ユーザー属性のSubjectに関しては、Datadog がサポートしている属性と異なっています。
Datadog がサポートしている属性はドキュメントで以下のように記載されています。
属性は SAML アサーションに含まれる場合があります。Datadog は
AttributeStatement内の 3 つの属性を参照します。
- eduPersonPrincipalName: 指定されている場合、eduPersonPrincipalName はユーザーの Datadog ユーザー名に対応している必要があります。ユーザー名は通常、ユーザーのメールアドレスです。
- sn: この属性は任意で、ユーザーの姓を設定する必要があります。
- givenName: この属性は任意で、ユーザーの名を設定する必要があります。
私が検証した際は、デフォルトの属性マッピングのままではJIT プロビジョニングがうまく機能せず、ログインできませんでした。
このため、以下のようにeduPersonPrincipalName属性を追加したところ、問題なく動作することを確認できました。
フォーマットとしてuriを指定しているのは、ドキュメントに以下のように明記されているためです。
Datadog は、属性が URI NameFormat
urn:oasis:names:tc:SAML:2.0:attrname-format:uriまたは基本 NameFormaturn:oasis:names:tc:SAML:2.0:attrname-format:basicを使用することを想定しています。各属性に使用される名前は、IdP が使用する NameFormat に依存します。
使用したIAM Identity Center のユーザー情報は以下のとおりです。
Datadog のユーザーページで確認できるユーザー名は、「名 + 姓」の構成になっていることが分かります。
利用可能なIAM Identity Center の属性
デフォルトで指定されていた${user:email}、${user:familyName}、${user:givenName}以外に利用可能な属性については、以下のドキュメントに記載されています。
項目名がSupported IAM Identity Center attributes for Microsoft ADとなっていてあれ？って感じではあるのですが、実際に以下画面の詳細はこちらのリンク先が上記ドキュメントとなっています。
ドキュメントでは以下の属性が対象になっていますが、どれがIAM Identity Center 上のどの属性に対応しているのかが正確には読み取れません。
Supported attributes in IAM Identity Center for Active Directory ${user:AD_GUID}${user:AD_SID}${user:email}${user:familyName}${user:givenName}${user:middleName}${user:name}${user:preferredUsername}${user:subject}
前述したIAM Identity Center のユーザー情報画面とどのように対応しているのか確認してみます。なお、ユーザー情報についてはCLI であれば以下のように取得可能です。
$ aws identitystore describe-user \
--identity-store-id d-xxxxxxxxxx \
--user-id 1234567890123-1234-1234-123456789012 \
--no-cli-pager
{
"IdentityStoreId": "d-xxxxxxxxxx",
"UserId": "1234567890123-1234-1234-123456789012",
"UserName": "naoki.nishimura",
"Name": {
"FamilyName": "Nishimura",
"GivenName": "直樹"
},
"DisplayName": "naonishi",
"Emails": [
{
"Value": "naonishi@example.com",
"Type": "work",
"Primary": true
}
],
"UserStatus": "ENABLED",
"CreatedAt": "2026-01-30T06:02:38.781000+00:00",
"CreatedBy": "XXXXXXXXXXXXXXXXXXXX:naoki.nishimura",
"UpdatedAt": "2026-01-30T06:20:04.161000+00:00",
"UpdatedBy": "XXXXXXXXXXXXXXXXXXXX:i-1234567890abcdefg"
}
実際に属性マッピングに設定して対応する値を確認した結果は以下のとおりでした。
| 属性 | 対応する値(マネジメントコンソール上) | 対応する値(CLI) | 備考 |
|---|---|---|---|
${user:AD_GUID} |
ユーザー ID | UserId | ユーザー作成後に変更不可 |
${user:subject} |
ユーザー名 | UserName | ユーザー作成後に変更不可、重複不可 |
${user:preferredUsername} |
表示名 | DisplayName | |
${user:name} |
表示名 | DisplayName | ${user:preferredUsername}と同値 |
${user:email} |
メールアドレス | Emails[0].Value | Datadog がサポートする属性eduPersonPrincipalNameに対応 |
${user:givenName} |
名 | Name.GivenName | Datadog がサポートする属性givenNameに対応 |
${user:familyName} |
姓 | Name.FamilyName | Datadog がサポートする属性snに対応 |
${user:AD_SID} |
- | - | 対応する値無し(属性マッピングで使用するとDatadog へのログイン時にエラーが発生) |
${user:middleName} |
- | - | 対応する値無し(属性マッピングで使用するとDatadog へのログイン時にエラーが発生) |
SAML Group Mapping の設定
SAML Group Mapping 機能を使用すると、IdPの属性を使用してDatadog 内のチームおよびロールを自動でマッピングすることができます。
グループマッピング用に使用する属性は、複数ユーザーに共通して設定可能な値になるかと思います。今回はIAM Identity Center をIdP として利用している兼ね合いで、指定可能な属性が前述の表に記載の内容に限られます。その中でも表示名(DisplayName)属性だけが、任意で指定可能かつユーザーに対して一意に設定する必要が無い属性に見えます。
というわけで、以下のように表示名をグループマッピング用の属性として使用してみます。今回は表示名をObservabilityチームと指定します。
IAM Identity Center の画面では以下のように表示名でフィルタすることも可能なので、表示名がグループ名のように使われていることに目をつぶれば運用上も便利そうではあります。実際にIAM Identity Center 上のグループと表示名に設定する値を一致させても良いかもしれません。
設定した表示名をteamというユーザー属性にマッピングするように、属性マッピングを設定します。
それでは、SAML Group Mapping を設定していきます。
チームのマッピング設定
チームについては以下のように事前に作成されているものとします。
[SAML Group Mapping] - [Team Mappings]タブから設定します。初期状態ではチームマッピングの機能自体が無効化されているはずですので、Team Settingsボタンから有効化します。
Team 機能のセッティング画面が表示されるので、Team Provisioning SourcesをUI and APIからAll Sourcesに変更してSaveします。Default Permissionsについてはチームのメンバー変更などの権限を管理する箇所になるので、今回は特に変更しません。
New Mappingを押下して以下のように設定します。先ほどIAM Identity Center の属性マッピングで追加したteam属性と、ユーザーの表示名をKey/Value に指定しています。
設定後は以下の状態になります。
ロールのマッピング設定
[SAML Group Mapping] - [Role Mappings]タブからNew Mappingを押下して以下のように設定します。今回マッピングするロールはDatadog Read Only Roleにしました。
ロールマッピングも無効状態になっているので、有効化します。
上記と同様の内容の確認ポップアップが出るので、Enable Mappingsを押下します。
設定後は以下の状態になります。
SAML Group Mapping が有効な状態でのログイン
SAML によるSSO で再度ログインしてみます。以下のとおり、チームとロールが設定したマッピングどおりになりました。
前述した注意書きのとおり、Datadog Read Only Roleでログインしてしまうとロールマッピングは無効化できません。
追加検証
ロールのマッピング設定を誤った場合
繰り返しになりますが、ロールマッピングには以下の注意書きがありました。
SAML を使用してログインし、Datadog ロールにマップされる値を持たないユーザーは、すべてのロールが削除され、ログインできなくなります。
つまり、ロールマッピングが有効な状態で、マッピングに使用したKey/Value の値をIdP 側もしくはDatadog 側で設定変更してしまうと、マッピングができなくなってログインできなくなります。実際にこの挙動を見てみます。
SSO ログインではない別の管理ユーザーを用いて、今回はDatadog 側でValue を変更してみます。
SAML によるSSO で再度ログインしてみると、以下のとおり確かにログインできなくなりました。
SSO ログインではないユーザーで確認すると、ロールの記載が消えていることが分かります。
ロールマッピングを無効化した場合
先ほど変更したValue を元に戻して再度ログインできることを確認します。
SSO ログインではない別の管理ユーザーを用いて、ロールマッピング自体を無効化してみます。
SAML によるSSO で再度ログインしてみるとログインできましたが、ロールとしてはDatadog Read Only Roleが割り当てられていました。
[Organization Settings] - [Login Methods] - [SAML] で設定したAssign Role to auto-created usersは、あくまでJIT プロビジョニングでユーザーが作成される際に割り当てられるロールなので、その後にロールマッピング等によってロールが変更された場合は、変更後のロールが適用されるという挙動のようです。
まとめ
実際にObservability チームとして複数名で複数のDatadog 組織を管理するケースを想定しながら検証してみました。Microsoft Entra ID は使っているけど管理箇所が異なるので調整や責任分界の解釈で難航しそう、Datadog のためだけにOkta を追加導入するのはコスト的にも難しそうといった場合に、AWS IAM Identity Center を活用するという手段もあります。
Datadog を割引して利用可能なCPPO 契約では、AWS アカウントも契約することになるので、そのままAWS の機能を利用してIdP を構築すれば追加の契約やコストが不要というメリットもあります（以下再掲）。
IAM Identity Center はSAML 2.0 のIdP として無料で利用可能ですが、当該用途で使用する場合はIAM Identity Center をAWS Organizations 管理アカウントのインスタンスで使用する必要があることにご注意ください。
本記事がどなたかのお役に立てれば幸いです。
