#はじめに
Azure AD は SAML 2.0 を話せるので、アプリケーション側が SAML 2.0 を話せるのであれば SAML 連携してシングル サインオン構成をとることができます。
実際に構成したことがある方もそうでない方も、各アプリケーション毎のチュートリアルとおりに設定すれば、構成自体は行えます。
しかし、実際にこの設定値は何の意味があるのだろう、この設定をすることでどういう動きになるんだろう、と考えたことはありますでしょうか。
今回は、Azure AD 上の 「SAML によるシングル サインオンのセットアップ」の画面で設定する主な設定項目の意味と、その動作について触れたいと思います。
#本題
まず、Microsoft の公開情報に、以下のように SAML 連携する際に Azure AD 側で設定が必要な項目の説明が記載されています。
SAML ベースのシングル サインオンについて理解する
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/manage-apps/configure-saml-single-sign-on
具体的なシングル サインオンに関する設定項目は下記のとおりです。
| [基本的な SAML 構成] の設定 | SP-Initiated | IdP-Initiated | 説明 |
|---|---|---|---|
| 識別子 (エンティティ ID) | 一部のアプリでは必須 | 一部のアプリでは必須 | アプリケーションを一意に識別します。 Azure AD から ID が SAML トークンの Audience パラメーターとしてアプリケーションに送信されます。 アプリケーションではこの ID を検証する必要があります。 また、この値はアプリケーションによって提供される SAML メタデータ内に Entity ID として表示されます。 "この値は、アプリケーションから送信された AuthnRequest (SAML 要求) の Issuer 要素として見つけることができます。 " |
| 応答 URL | 必須 | 必須 | アプリケーションが SAML トークンを受け取ることになっている場所を指定します。 応答 URL は Assertion Consumer Service (ACS) URL とも呼ばれています。 追加の応答 URL フィールドを使用して、複数の応答 URL を指定できます。 たとえば複数のサブドメインで、追加の応答 URL が必要となります。 またはテスト目的で、複数の応答 URL (ローカル ホストとパブリック URL) を一度に指定できます。 |
| サインオン URL | 必須 | 指定しません | この URL をユーザーが開くと、サービス プロバイダーは、ユーザーの認証とサインインを行う Azure AD にそのユーザーをリダイレクトします。 Azure AD はその URL を使用して Office 365 または Azure AD アクセス パネルからアプリケーションを起動します。 何も入力されていない場合、ユーザーが Office 365、Azure AD アクセス パネル、または Azure AD SSO URL からアプリケーションを起動したとき、Azure AD により IdP-Initiated のサインオンが実行されます。 |
| リレー状態 | 省略可能 | 省略可能 | 認証が完了した後にユーザーをリダイレクトする場所をアプリケーションに指示します。 通常、値はアプリケーションで有効な URL です。 ただし、一部のアプリケーションでは、このフィールドを異なる方法で使用します。 詳細については、アプリケーションのベンダーに問い合わせてください。 |
4 つある設定項目の中で、必須、省略可能、指定しません、とありますが、一番初めに SP-Initiated と IdP-Initiated について説明したいと思います。
詳細な動作については、過去の私の記事もしくは、私の SlideShare に説明がされていますので、そちらを参考にしてほしいのですが、非常にシンプルな言い方をすると、一番初めにユーザー(ブラウザー)が、アプリケーション (SP) にアクセスしに行くのが、SP-Initiated 、一方、一番初めに Azure AD (IdP) にアクセスしに行くのが、IdP-Initiated だと思ってください。
(物凄くいろんなものを端折ってますが、最初のとっかかりとしては、この覚え方で良いです)
-参考情報
SP-Initiated と IdP-Initiated の動作の違いを Fiddler を見ながら確認してみる
URL:https://qiita.com/Shinya-Yamaguchi/items/434fab8c39e806e69a88
Azure AD とアプリケーションを SAML 連携する際に陥る事例と対処方法について
URL:https://www.slideshare.net/yamarara/azure-ad-saml-169796007?fbclid=IwAR205Ibl2-E_JyX0bFEdcmmecQ6-bfHobtsmz4vZ0w_NEkT-PYzJPStbQ_M
実際に Azure AD 側で SP-Initiated と IdP-Initiated のアプリケーションによって設定する画面がどのように違うのか確認してみましょう。
まず、「Azure ポータル」→「Azure Active Directory」→「エンタープライズ アプリケーション」→「すべてのアプリケーション」の順に選択し、下記画面ショットにある「新しいアプリケーション」をクリックします。
SP-Initiated のアプリケーションである、Salesforce を選択します。
「追加」をクリックします。
「シングルサインオン」をクリックします。
「SAML」をクリックします。
すると、「識別子(エンティティ ID)」、「応答 URL」、「サインオン URL」が設定として必須であることが分かります。
一方、同じような手順で、IdP-Initiated をサポートしている AWS(Amazon Web Services) のシングルサインオンの設定画面を見てみます。
すると、「識別子(エンティティ ID」が必須であることが分かります。実際には、「応答 URL」も必須になります。
詳細画面を表示すると、「応答 URL」もアスタリスクのマークがついているの必須になります。
AWS 側で応答 URL が固定化されているので、予め設定が入っている状態になります。
では、それぞれの設定項目について順番に説明していきます。
#識別子 (エンティティ ID)
Microsoft の公開情報には以下のように記載されていましたね。
アプリケーションを一意に識別します。 Azure AD から ID が SAML トークンの Audience パラメーターとしてアプリケーションに送信されます。 アプリケーションではこの ID を検証する必要があります。 また、この値はアプリケーションによって提供される SAML メタデータ内に Entity ID として表示されます。 "この値は、アプリケーションから送信された AuthnRequest (SAML 要求) の Issuer 要素として見つけることができます。 "
一行目の最初の一文がある意味すべてなのですが、識別子は文字通りアプリケーションを一意に識別するために設定する値になります。
必ずしも URL である必要もなく、適当な文字列で Azure AD とアプリケーションの間でお互いを一意のものとして、識別 できれば問題ありません。
ただ、基本的にはこの識別子はアプリケーション側が要求、決めるものなので、アプリケーション側が要求してくる識別子に、Azure AD 側の設定を合わせると言った方がイメージがつけやすいかもしれません。
ちなみに、アプリケーション側と Azure AD 側で識別子の不一致が発生すると、シングル サインオンは成功せず、下記のようなエラーが出力されます。
上記エラーは、アプリケーション側が識別子として「https://saml.salesforce.com」 を要求しているのに、Azure AD 側にそのような値が設定されていない、存在しないので、シングル サインオンできませんと、Azure AD 側がエラーを返しています。
Azure AD 側の識別子の設定を「https://saml.salesforce.com」 にすれば、この事象は解消します。
#応答 URL
Microsoft の公開情報には以下のように記載されていましたね。
アプリケーションが SAML トークンを受け取ることになっている場所を指定します。 応答 URL は Assertion Consumer Service (ACS) URL とも呼ばれています。 追加の応答 URL フィールドを使用して、複数の応答 URL を指定できます。 たとえば複数のサブドメインで、追加の応答 URL が必要となります。 またはテスト目的で、複数の応答 URL (ローカル ホストとパブリック URL) を一度に指定できます。
ある意味一行目の一番最初の文がすべてで、Azure AD 側から払い出したトークンの受け取り先を指定すると思ってください。
分かりやすいのが、IdP-Initiated の場合のシングル サインオンの動作になります。
後述する SP-Initiated で必要なサインオン URL を IdP-Initiated では指定しません。
IdP-Initiated は初めにユーザーが IdP (Azure AD) 側にアクセスしに行きます。
その後 Azure AD 側で認証を済ませ、Azure AD が発行したトークン (SAML Response) をアプリケーションに返しますが、その返し先の URL が応答 URL に該当すると考えてください。
つまり、Azure AD 側からすると、どのアプリケーションに対して SAML Response を返せばいいのか、「応答 URL」が設定されていないと分からない、困っちゃうわけですね。
きちんと「応答 URL」が設定されていれば、Azure AD 側からすると、「ああ、このアプリケーション (URL) にトークンを渡せばいいのね」と理解できるようになる訳です。
ちなみに応答 URL の値が適切に設定されていないと、アプリケーション側でトークンの送り先間違ってないですか？(実際にはそこまで明確なエラーメッセージ表示されないと思いますが)という感じでエラーが返ってきます。
※下記は AWS と SAML 連携した場合の例です。
#サインオン URL
Microsoft の公開情報には以下のように記載されていましたね。
この URL をユーザーが開くと、サービス プロバイダーは、ユーザーの認証とサインインを行う Azure AD にそのユーザーをリダイレクトします。 Azure AD はその URL を使用して Office 365 または Azure AD アクセス パネルからアプリケーションを起動します。 何も入力されていない場合、ユーザーが Office 365、Azure AD アクセス パネル、または Azure AD SSO URL からアプリケーションを起動したとき、Azure AD により IdP-Initiated のサインオンが実行されます。
公開情報にも書いてあったとおり、基本的にはこの設定項目は「SP-Initiated」専用の設定項目だと思って差し支えありません。
「サインオン URL」が必須と書かれている時点で、「このアプリケーションは SP-Initiated をサポートしているだな」と理解できるようになったらしめたものです。
上述の参考資料にも記載されていますが、SP-Initiated のシングル サインオンはまず一番初めにアプリケーション (SP) にアクセスしに行きます。
図にするとこんな感じです。見てのとおり、 ユーザー (ブラウザー) が、 Azure AD ではなく、アプリケーション (SP) にアクセスしに行ってますね。
つまり、この「サインオン URL」というのは、シングル サインオンを開始するにあたって、シングル サインオンしたい特定のアプリケーションの URL を指定する必要がある、ということです。
当然、正しい URL を設定してあげないと、下記のとおりエラーが出ます。
※下記は Salesforce と SAML 連携した場合の例です。
#リレー状態
Microsoft の公開情報には以下のように記載されていましたね。
認証が完了した後にユーザーをリダイレクトする場所をアプリケーションに指示します。 通常、値はアプリケーションで有効な URL です。 ただし、一部のアプリケーションでは、このフィールドを異なる方法で使用します。 詳細については、アプリケーションのベンダーに問い合わせてください。
この設定項目は、SP-Initiated でも IdP-Initiated でも「省略可能」と記載されていたとおり、設定必須の項目ではありませんので、設定しなくてもシングル サインオンは構成することは可能です。
では、どのような場面でこの値を設定するのか。
公開情報にも記載されているとおり、認証が完了したあとのリダイレクト先を指定することができます。
リレー状態の値を設定しないと、シングル サインオン先のアプリケーションの遷移先はそのアプリケーションのトップページになります。
逆に「リレー状態」にシングル サインオンした後に遷移させたい URL があるのであれば、その URL を設定することで、トップページ以外の URL に遷移した状態でシングル サインオンが完了します。
具体的に画面で見てみると、下記は「リレー状態」に何も値を設定しない状態。トップページが表示されます。
※下記は Salesforce と SAML 連携した場合の例です。
次に「リレー状態」に下記のように、「カレンダー」の URL を設定した場合の動作を確認してみます。
すると、Salesforce のトップページから、下記画面ショットのとおり、Salesforce のカレンダーのページにリダイレクトされた状態でシングル サインオンされます。便利ですね。
ただ、ここで注意点として、「リレー状態」の設定は、アプリケーション側の仕様に依存するので、必ずしも想定とおりの動作になるとは限らない、ということと、アプリケーション単位で設定する項目になるので、本設定をすると、対象のアプリケーションを利用している全ユーザーが、設定した URL にリダイレクトされる、つまり、ユーザー単位では設定できない、という 2 点についてご留意ください。
#おわりに
今回は Azure AD とアプリケーションを SAML 連携する際に必要な設定項目について解説しました。
SP-Initiated と IdP-Initiated により設定項目が異なるということと、それぞれの値が適切に設定されていない場合の動作についても画面ショット付きで説明しました。
最初にお伝えしたとおり、チュートリアルとおりに設定すれば、シングル サインオンの環境は構成できますが、それぞれの設定項目の意味を理解することで、うまくいかなかった場合の初動が早くなると思いますし、SAML に関する理解も深まると思います。
少しでも本記事が皆様の参考になれば幸いです。