クラウド テクノロジーが急速に進歩し、サービスとしてのインフラストラクチャ (IaaS) とサービスとしてのプラットフォーム (PaaS) が多くのプロジェクトに不可欠な時代において、多様なクラウド サービスのシームレスな統合に対する需要は否定できません。この分野の主要企業である Microsoft は、ユーザー フレンドリーな Microsoft Entra ID サービスの開発に多大な時間を投資しました。ただし、ベンダーからの綿密な指示にもかかわらず、スペシャリストが Slack、Salesforce、Datadog などのプラットフォームとの統合を構成する際に問題に遭遇することがよくあります。特定の質問に対する答えを提供するには、ドキュメントは不十分です。
Social Discovery Group チームも同様にこれらの課題に直面しました。この記事では、それらの課題に対処して解決する方法についての洞察を提供します。
Social Discovery Group は、50 を超える出会い系プラットフォームのポートフォリオで、さまざまなテクノロジーとクラウド サービスを利用して、そのセキュリティと信頼性を保証しています。当社には、さまざまなクラウド間のピアツーピア接続など、さまざまなシステムの統合と構成に関する豊富な経験があります。
Microsoft Entra ID は、ID およびアクセス管理のためのクラウド ソリューションであり、クラウド上で動作するディレクトリおよび認証サービスとして機能します。 Microsoft Entra ID は、さまざまな Microsoft サービスおよび Microsoft 以外のサービスの認証および承認サービスを提供します。この記事では、Slack、MongoAtlas、ElasticCloud、Salesforce、Datadog のクラウド システムの統合について説明します。
正確なガイドが存在しないため、私たちは途中で生じたすべての悩みを詳細に記した独自のガイドを作成することにしました。それでは、Azure の「エンタープライズ アプリケーション」セクションに移動しましょう。
新しい企業アプリケーションを作成する必要があります (これは数回のクリックで実行できます)。次に、作成したアプリケーションにアクセスし、シングル サインオン (SAML) を構成します。上から下に変更を加えます。
「メンバー」ロールを作成します (または別の名前を選択します)。次に、Microsoft Entra ID でテスト ユーザーを作成し、アプリケーションに追加します。次に、Slack の管理センターに移動します。次の手順に従ってください: Slack 管理 - 認証 - SAML 構成 - 構成
次のステップは SAML を構成することです。 「表示名」の設定に注意することをお勧めします。さらに、設定で「ログイン時にプロファイルを更新する」のチェックを外し、メールアドレスと表示名の変更を禁止します。
ログイン ボタンのテキストをカスタマイズし、ユーザーが SSO 以外の方法でログインすることを禁止するオプションもあります。この後、Microsoft アカウントを使用して Slack にサインインできるようになります。追加のフィールドまたは設定が必要な場合は、Azure AD プロビジョニングを通じて行うことができます。
新しい属性を追加するには、[ユーザー属性] に移動し、[新しいマッピングの追加] を選択します。 Slack に表示したいソース属性を選択し、対応する Slack 属性に関連付けます。
必要な属性を追加して設定を保存した後、オンデマンドのプロビジョニングに進み、機能をテストします。肯定的な結果が得られると、次のものが得られます。
次に、Slack に移動し、完全なユーザー プロファイルに表示する属性と、それらを取得する場所を指定する必要があります。 「プロファイル」に移動し、表示する情報と情報の取得元を選択します。この場合、SCIM は Azure AD に対応します。
次に、シームレスな統合を体験するために、必要なユーザーを Active Directory から Slack に追加することをお勧めします。また、ユーザーを削除するときに発生する問題にも注意してください。ユーザーが (Slack 管理センター経由で) Slack から手動で削除された場合、権限が不十分なためユーザーを Slack に転送できないことを示すエラーが残ります。これは、Entra ID がスコープ内のユーザーに関する情報を保持し、ユーザーに一意の ID を割り当てるために発生します。 Slack でユーザーを削除して再度追加すると、Entra ID によって新規ユーザーとして認識され、更新中に権限の問題が発生します。
こちらのドキュメントを確認してください。
MongoAtlas の場合、プロセスは同様のパスをたどります。新しい企業アプリケーションを作成する必要もあります。簡単のため、検索フィールドに「MongoDB Atlas — SSO」と入力します。詳しい手順については、こちらをご覧ください。
次に、シングル サインオン設定に進み、次の情報を入力する必要があります。
「識別子」テキストフィールドに、次のテンプレートを使用して URL を入力します: https://www.okta.com/saml2/service-provider/<Customer_Unique>
[応答 URL] テキスト フィールドに、テンプレートを使用して URL を入力します。
https://auth.mongodb.com/sso/saml2/<顧客_固有>
[ログイン URL] テキスト フィールドに、テンプレートを使用して URL を入力します: https://cloud.mongodb.com/sso/<Customer_Unique>
[属性] セクションに注目し、以下のスクリーンショットに示すように構成することをお勧めします (「memberOf」を追加することが必須でした)。
次に、「SAML を使用したシングル サインオンの設定」ページで、「SAML 署名証明書」セクションに移動し、フェデレーション用の XML メタデータを見つけます。 「ダウンロード」を選択して証明書をダウンロードし、ローカルに保存します (フェデレーション メタデータ XML)。これは後ほど MongoDB Atlas で必要になります。
「MongoDB Atlas — SSO のセットアップ」セクションで、それぞれの URL をコピーします。次に、 MongoDB Atlas -> 組織 -> 設定 -> フェデレーション認証設定に移動します。
まず、Microsoft Entra ID 資格情報プロバイダーを Atlas に追加します。 Microsoft ポータルから前の手順で説明したそれぞれの URL (発行者 URI、ログイン URL、シングル サインオン URL) を入力し、アイデンティティ プロバイダーの署名証明書をアップロードし、以下のスクリーンショットに示すように残りの設定を構成します。
[次へ] をクリックし、メタデータ ファイルをローカルに保存します。後で Azure のシングル サインオン構成ページにアップロードする必要があります。
次に、MongoDB Atlas で生成された対応する TXT レコードなどを使用して、ドメインを追加、マッピング、検証します。その後、ドメインを資格情報プロバイダーにリンクし、最も興味深い部分であるロールの構成に進みます。
例として次のロールを作成しました。それぞれのロールには、プロジェクトに付与される特定の権限が与えられています。次に、これらのロールを Azure ロールにマップする必要があります。アプリケーションの「アプリ ロール」に移動し、MongoAtlas でこれらのロールに割り当てた名前と正確に一致する値を持つロールを作成して追加します。
その後、Microsoft Entra ID Enterprise Application のアプリケーションにユーザーを追加し、適切なロールを割り当てます。 MongoDB Atlas のフェデレーション管理セクションで [Azure SSO でサインイン] を有効にし、構成された設定が正しく機能することを確認します。
詳細な手順については、こちらのドキュメントを参照してください。
Elastic Cloud との統合に移りましょう。 Enterprise Application Entra ID でアプリケーションを作成する基本的な手順は、前の手順と同様です。そこでは、識別子またはログアウト URL を取得する場所に関する情報が見つかります。ただし、属性に関する問題が発生したため、動作中の構成のスクリーンショットを提供します。
リーダーとスーパーユーザーという 2 つのロールを作成しました。
ここで、必要な数のロールを作成できます。 Elasticsearch のロール設定はロール マッピングで構成され、次のようになります。
ここからが興味深い部分です。 Kibana と Elasticsearch の Azure SSO 構成を追加するという 2 つのことを行う必要があります。これを実現するには、次の手順に従います。
Elasticsearch Cloud デプロイメントの編集セクションに移動して、elasticsearch.yml 設定を更新します。次の行を追加します。
“ xpack:
security:
authc:
realms:
saml:
saml-azure-ad:
order: 2
attributes.principal: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
attributes.groups: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role"
attributes.name: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"
attributes.mail: "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
idp.metadata.path: "APP Federation metadata URL"
idp.entity_id: "Azure Entra ID Identifier"
sp.entity_id: "Kibana endpoint"
sp.acs: "Kibana endpoint/api/security/v1/saml"
sp.logout: "Kibana endpoint/logout" “
構成に合わせて赤で強調表示された値を追加および変更した後、「保存」をクリックします。 Elastic Cloud はすべての変更を検証し、クラスターの更新を開始します。このプロセスには数分かかる場合があります。
“ xpack.security.authc.providers:
saml.saml1:
order: 0
realm: saml-azure-ad
description: "Log in with Azure Entra ID"
basic.basic1:
order: 1 ”
前の 2 つの手順を完了すると、Kibana ログイン ページで別のログイン オプションが利用できるようになります。次に、Microsoft Entra ID Enterprise Application のアプリケーションにユーザーを追加し、必要なロールを割り当てます。
詳細については、こちらのドキュメントを参照してください。
Salesforce との統合は、以前のものよりも少し複雑でした。最初の手順は似ていますが、「プロビジョニング」セクションに注意する必要があります。アカウントの同期が行われる管理者の資格情報の指定に関しては微妙な違いがあり、属性マッピングを有効にする必要があります。
スクリーンショットの構成設定の例を次に示します。属性に関する重大な問題は発生しませんでしたが、使用したもののスクリーンショットも提供します。
Salesforce 自体には特別なニュアンスはなく、このガイドで概説されている次の手順を進めました。
Datadog との統合中に、いくつかの問題も発生しました。私たちをガイドした主なドキュメントは、ここにあります。トラブルシューティングの詳細については、このガイドを参照しました。
すべてがスムーズに始まり、最初は何の問題もないと思われました。いつものように、Microsoft Entra ID で新しいエンタープライズ アプリケーションを作成しました。
「SAML を使用したシングル サインオンのセットアップ」セクションでは、Datadog アカウント用に選択した場所に注意してください。私たちの場合、それはヨーロッパ地域でした。
前述したように、MongoAtlasDB の場合、ロール マッピング用の追加属性「memberOf」を追加します。
すべての設定を保存し、フェデレーション メタデータ XML をダウンロードします。このファイルを Datadog の SAML 設定にアップロードします。参考までに便利なリンクを貼っておきます。 Datadog SAML 設定 (場所が異なる場合は、「EU」を適切なドメイン ゾーンに置き換えます)。以下のスクリーンショットのようになります。
組織のログイン方法設定では、必要なものだけを保持します (私の場合、パスワード ログインと Google 認証を無効にしました)。 Microsoft Entra ID のアプリケーション登録で Azure にロールを追加します。
ここが最も興味深い部分です。 Datadog で [SAML グループ マッピング] -> [ロール マッピング] に移動し、キー、値、ロールを追加します。それは簡単なようです。以下のスクリーンショットを参照してください。
しかし、それは機能せず、「このユーザーには AuthNMappings がありません」というエラーが表示され続けます。
私たちは長い間、すべてのドキュメント、ログ、トラブルシューティング ページを確認して、何が間違っていたのかを理解しようと努めました。残念ながら、このことについてはどこにも言及されていませんでした。結局のところ、解決策は簡単です。以下のスクリーンショットに示されている構成に従うだけです。
「KEY」フィールドに、文字列 http://schemas.microsoft.com/ws/2008/06/identity/claims/role を入力します。
これを実行した後、すべてが正常に動作し始めました。
「これは、Microsoft Entra ID と統合したシステムのほんの一部です。ここで共有した洞察が役立つリソースとして機能し、統合プロセスを合理化し、貴重な時間を節約できることを願っています。結論として、Microsoft を使用する利点は次のとおりです。 Entra ID は、パスワードを複数回入力する必要のないシングル サインオン、追加のコンポーネントが不要、構成と管理の容易さ、グループ ポリシーとグループ、デバイスの登録、および高レベルのセキュリティを強調表示できます。