Home » SSO » SaaSをAzure ADでシングルサインオンを構成する流れをわかりやすくまとめてみた

SaaSをAzure ADでシングルサインオンを構成する流れをわかりやすくまとめてみた

7/23/2022

Azure AD SSO

 組織内でクラウドアプリケーションの導入が増え、 Azure AD で SSO することが増えました。感覚的には2021年比で数倍です。初めて設定した時は緊張しながら実施したものですが、数を積んでだいぶ慣れてきました。

依頼をもらって設定するのは、SAMLばかりです。そのSAMLをほかのメンバーでも対応できるようにしたいので、自分が説明するために流れをまとめてみました。アレコレ、端折ってますがご容赦を。


覚えておく

  • サービスプロバイダ(SP)：クラウドアプリケーション、SaaSのこと。
  • IDプロバイダ(IdP)：認証機能側。AzureADとか。


  • SP-Initiated：クラウドアプリケーションでログインしようとすると、IdPに飛んで、認可されたらクラウドアプリを開ける方法。入口はSP側にある。
  • IdP-Initiated：IdPでログインしている状態で、指定のURLを開くと、クラウドアプリケーションにログインできる方法。入口はIdP側にある。
    この２つは、両方とも使えるクラウドアプリケーションもあるけど、片方しか使えないクラウドアプリケーションもあります。


SPとIdP管理画面両方を開いて、行ったり来たりして設定します。SPによって設定手順が違うけど、流れはだいたい同じです。

計画しておく

もろもろ、ヒアリング・調整しておくとスムーズです。

  • 利用させるユーザーの範囲と、SSO対象のグループ
  • 利用するデバイス（WindowsPCだけ、スマートデバイス含むか）
  • 利用するSaaSの管理者（できれば複数）
利用するデバイスが条件付きアクセスを利用している場合は、その考慮も必要になってきますが、これはまた今度。


SPで、SAML設定用の情報をメモします

SPの管理画面から、Azure AD側に登録する情報をメモします。

  • 識別子（エンティティID)：
    クラウドアプリケーションと、自組織だとわかるような文字列（ドメインとか、何かの値とか）が入っていることが多いです。自組織だとわかる文字列が入っていないない場合もあります。また1つだけの場合、複数の場合もあります。
  • 応答URL:
    IdPがやり取りするためのURL。ACSという表記の場合も。
    自組織だとわかるような文字列（ドメインとか、何かの値とか）が入っていることが多いです。自組織だとわかる文字列が入っていないない場合もあります。また1つだけの場合、複数の場合もあります。
  • サインオンURL：
    SP-Initiatedの場合につかう専用のURL。IdP-Initiatedの場合はありません。
だいたい、この３つ（あるいは２つ）です。ほかにもあるけど、指定がなければメモ不要です。

Azure AD で、メモした情報を登録します

先ほどメモした情報を、それぞれ登録します。Azure AD のエンタープライズアプリケーションの、SAMLの構成画面でそれぞれ登録します。詳しい手順は割愛。




AzureADで、SPに登録する情報をメモします

上記のSAMLの構成画面から、SP側に登録する情報をメモします。

SAML証明書と、AzureADの各種URLである場合が多いです。

  • SAML　署名証明書：
    SPからみて、このIdPは信頼してもいいんだよな？というための証明書。
    証明書をダウンロードするだけの場合もあれば、証明書を一部変更するような場合もあります。また、証明書のかわりにフェデレーションメタデータURLの場合もあれば、フェデレーションメタデータXMLの場合もあります。
    どれを使うかはSPによって異なります。
  • ～～のセットアップ：
    SPが、Azure AD にリダイレクトする場合の各種URL。

SPで、メモした情報を登録します

先ほどメモした情報を、それぞれ登録します。SPの管理画面にもどって、それぞれ登録します。

証明書の場合はアップロード、URLやXMLはそれぞれ登録ですね。


SPで、ユーザーを作成します

続けて、SPでユーザーを作成します。
ユーザー作成や管理（ユーザープロビジョニング）を自動化できるクラウドアプリケーション場合は、手動で作成しなくてもOKです。


Azure AD で、SSO対象となるユーザーを設定します

ユーザー単位、グループ単位、すべてのユーザーなど、目的に応じて設定できます。
追加は後でもできるから、とりあえずテストアカウント分だけでテストが良いです。

入れ子になっているグループは使えませんので要注意。
ユーザーが対象ユーザーを管理する場合は、メールが可能なセキュリティグループか、Microsoft365グループを作ってもらうようにしています。これだとユーザー部門でメンバーの追加削除できるため、です（セキュリティグループは制限設けていることが多いハズ）



テストする！

テストしましょう。プライベートブラウズでテストします。


あとちょっとだけ

うまくいかないときは、エラーメッセージである程度めどがつきます。
  •  AADに見つかりません：識別子が間違えているかも。
  • アプリが割り当てられていません：SSO対象ユーザーに登録が足りてないかも

    ・・とかです。

クラウドアプリケーションのログイン名と、メールアドレス

  • Azure ADのUPNと、メールアドレスが同一なら考慮不要ですが、違いがある場合は属性とクレームの「一意のユーザーID」を、user.princripanameにするか、user.mailにするか考慮しましょう。
    クラウドアプリケーションによっては、user.mailと設定手順に記載があっても、組織のUPNとメール次第では変更する必要があります


困ったときはオフィシャルドキュメント以外も参考にする
 



-
ラベル: ,