Azure AD とエンタープライズ アプリケーションを SAML 連携する際のトラブルシュートのやり方について

#はじめに

Azure AD にアプリケーションを登録し、SAML 連携することで、Azure AD ユーザーから SAML 連携したアプリケーションにシングル サインオンできるようになります。
また、ギャラリー内のエンタープライズ アプリケーションの場合は、下記 Microsoft 公開情報に、チュートリアルとして Azure AD 側、アプリケーション側それぞれの設定方法が画面ショット付きで記載されております。

-参考情報
SaaS アプリケーションと Azure Active Directory の統合に関するチュートリアル
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/tutorial-list

しかしながら実際にチュートリアルとおりに設定してもエラーが出てしまい、シングル サインオンに失敗してしまう、というお問い合わせは多くいただきます。
今回は、 Salesforce を例によくある例と、Fiddler を使ったトラブルシュートのやり方をご紹介します。

前提

今回は、下記チュートリアルを使い、 Salesforce をエンタープライズ アプリケーションから登録し、一連の設定を行っている状況です。

-参考情報
チュートリアル:Azure Active Directory と Salesforce の統合
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/salesforce-tutorial

#やってみる

ほぼすべてのチュートリアルに記載されていますが、シングル サインオンの構成をひととおり行ったあとは、エンタープライズ アプリケーションの「Test」を行うように記載されています。実際にやってみましょう。

1. Azure ポータルにサインインします。
2. 左ペインより Azure Active Directory をクリックします。
3. 概要画面より、エンタープライズ アプリケーションをクリックします。
4. すべてのアプリケーションより、「Salesforce」をクリックします。
5. 概要画面より、「シングル サインオン」をクリックします。
   SAML ベースのサインオン画面より、下記画面ショットにある「このアプリケーションをTest」をクリックします。
   

現在のユーザーとしてサインインをクリックします。

アカウントを選択する画面で、現在のユーザーを選択します。

すると下記画面ショットのとおり、エラーが出力されました。
初めてこのエラー画面を見ると正直面食らってしまうかもしれません。実際私もそうでした。
まずやるべきことは、エラーコードで検索してみましょう。

すると、下記 Microsoft 公開情報にエラーコードに該当するエラー内容が記載されていることが分かります。

-参考情報

フェデレーション シングル サインオン用に構成されたギャラリー アプリケーションへのサインインに関する問題
アプリケーションが正しく構成されていない
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/application-sign-in-problem-federated-sso-gallery#misconfigured-application

エラー AADSTS650056:アプリケーションが正しく構成されていないこの場合は、次のいずれかの原因が考えられます。クライアントは、クライアントのアプリケーション登録の要求されたアクセス許可に "AAD グラフ" のアクセス許可を記載していません。あるいは、管理者がテナントで同意していません。あるいは、要求のアプリケーション識別子を見て、構成したクライアント アプリケーション識別子に一致することを確認してください。構成を修正するか、テナントの代わりに同意するように管理者に連絡してください。

考えられる原因
SAML 要求でアプリケーションから Azure AD に送信された Issuer 属性が、Azure AD でアプリケーションに対して構成された識別子の値に一致していません。

色々書いてありますが、端的に書いてしまうと、アプリケーション側から要求されている Issuer 属性(識別子) と Azure AD 側で設定している識別子が一致していないためにエラーになっていると記載されています。

もう少しこのあたりの動きを見てみましょう。
下記 Microsoft の公開情報に記載されていますが、アプリケーション側が発行する Issuer (アプリケーション側が発行する一意の ID) と Azure AD 側のシングル サインオンで設定している識別子は必ず一致させる必要があります。

-参考情報
発行者
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/develop/single-sign-on-saml-protocol#issuer

AuthnRequest の Issuer 要素は、Azure AD でのクラウド サービスの ServicePrincipalNames のいずれかと厳密に一致する必要があります。 通常、これはアプリケーション登録時に指定される App ID URI に設定されます。

下記が Issuer 要素が記載された SAML Request の中身の例です。

<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">https://www.contoso.com</Issuer>

では、実際に、アプリケーション側がどのような Issuer 要素を要求しているかどうかを確認してみましょう。
Salesforce の場合は、「設定」→「ID」→「シングル サインオン設定」の順にクリックすると、シングル サインオン構成の画面の右下に「エンティティ ID」を確認できます。これがアプリケーション側が発行する Issuer ID になります。

Salesforce の場合は上記のとおりエンティティ ID を簡単に確認できますが、Fiddler を使って HTTPS 通信をキャプチャすることで、実際にアプリケーション側が要求している Issuer ID を確認することができます。
(アプリケーションによっては、Issuer 要求をアプリケーション側の設定画面からは確認できない場合もあります。)

Fiddler の入手と取得方法は下記記事を参考にしてください。

HTTPS パケット キャプチャ ツール Fiddler のインストールから使用開始まで。
URL:https://qiita.com/Shinya-Yamaguchi/items/37347ec532824c2dccad

Fiddler を起動し、「Captuer Traffice」を有効にした状態で、SAML ベースのサインオン画面より、下記画面ショットにある「このアプリケーションをTest」から「現在のユーザーとしてサインイン」をクリックします。

サインインするアカウントを選択します。

エラーを再現します。

取得した Fiddler の中で確認するパケットは「SAML Request」になります。
SAML Request が Azure AD に対して渡す AuthnReauest(認証要求) になります。
Azure AD は SAML Request の内容に応じて、アプリケーション側に SAML Response を返すというのが基本的な SAML プロトコルの通信フローになります。

Fiddler の中で SAML Request を見つけたら右クリックし、「Send to TexWizard」をクリックします。

ポップアップ表示されたデコードされた SAML Request の中で transform を「From DeflatedSAML」を選択すると、下記のとおり、XML フォーマットで SAML Request の中身を見ることができます。

下記が整形した SAML Request の中身です。

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://shyamag018.my.salesforce.com" Destination="https://login.microsoftonline.com/a96567f1-ec44-4e81-b298-8bad9430c5b3/saml2" ID="_2CAAAAW0LZluVME8wMnYwMDAwMDA4T0k2AAAA3Ekdd4ZdAtspQXrWJZPU3_x0H5rfpVdwQVL0W2MfUR7kZJzGPuwfvOVUoJdEUYqPOJxukvHrUDj6hh1rv5r7ULBW1M-9q_k1TjFiZFEmOT58cHfoyctpqPRXRCVIvMlZcQZhQRctNJCPtKYlA5GHrVsoH4rfG-fxic0N1cAvo0DZRczdnQ2GTli1BmTtHaS68JSLADAnFiWnUs0uBkNZ1vCZwYWSFrLCDnaiV9wZrXkfguNqQ5j5GOOxnWJ95146_g" IssueInstant="2019-08-10T11:05:20.613Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://shyamag018.my.salesforce.com</saml:Issuer>
</samlp:AuthnRequest>

更に細分化して Issuer 要素だけが書かれた行が下記です。

 <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://shyamag018.my.salesforce.com</saml:Issuer>

Salesforce アプリケーションが要求している、Issuer 要素が「**https://shyamag018.my.salesforce.com**」であることが確認できました。

この値を Azure AD 側の識別子の値を一致させる必要がありますので、Azure AD 側の設定を見てみましょう。

基本的な SAML 構成の識別子の値を見てみると、「https://shyamag018.my.salesforce.com」 ではなく、「https://shyamag017.my.salesforce.com」 になっていることがわかります。値を変更しましょう。

「https://shyamag018.my.salesforce.com」 に変更し、「保存」をクリックします。

正常に保存されることを確認します。

この状態で再度「このアプリケーションをTest」をクリックして、接続テストをしてみましょう。

「現在のユーザーとしてサインイン」をクリックします。

サインインするアカウントを選択します。

今度は今までと違うエラーメッセージが出力されました。

このメッセージは見ていただくだけで分かる方もいらっしゃるかもしれませんが、念のためドキュメントを確認してみましょう。

ユーザーにロールが割り当てられていない
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/application-sign-in-problem-federated-sso-gallery#user-not-assigned-a-role

エラー AADSTS50105:サインイン ユーザー "[e-mail]" はアプリケーションのロールに割り当てられていません。
考えられる原因
このユーザーは、Azure AD 内のアプリケーションへのアクセスを許可されていません。

内容は実にシンプルで、エンタープライズ アプリケーションの「ユーザーとグループ」に対象のユーザー「[e-mail]」が割り当てられていないためです。

対象のユーザーを割り当てる手順は下記のとおりです。
「ユーザーとグループ」より画面上部の「＋ユーザーの追加」をクリックします。

ユーザーとグループより対象のユーザーを選択し、「選択」をクリックします。

ロールの選択より任意のロールを選択し、「選択」をクリックします。

ユーザーとロールを割り当てたら「割り当て」をクリックします。

割り当てが成功したことを確認します。

再度テスト画面より、「現在のユーザーとしてサインイン」をクリックします。

対象のユーザーを選択します。

無事当該のユーザーで対象の Salesforce にシングル サインオンすることができました。

#おわりに

冒頭にも触れましたが、チュートリアルとおりに設定してもエラーが出てしまい、シングル サインオンに失敗してしまう、というお問い合わせは多くいただきます。実際にお問い合わせをいただいている中で一番多いのがこの Issuer 要素(識別子の値) の不一致になります。

今回は、テスト接続の際に実際にエラーを発生させ、エラーの原因の特定と、 Fiddler を使ってアプリケーション側が要求する Issuer 要素の確認、 Azure AD 側の設定の確認、修正、シングル サインオンの成功までのトラブルシュートのやり方をご案内しました。

少しでも今回の記事が参考になれば幸いです。