Microsoft Entra ID/Azure AD + miro連携 Part2 SSOの心配ごと編

さて今回は Microsoft Entra ID (旧Azure Active Directory) と miro を連携していくシリーズの第2弾として、SSOを構成するときの心配ごとに関してです。お客様からよくお問い合わせいただく内容の解説とEntra ID側の設定でうまい具合になんとかする方法を解説していきたいと思います。

miro Enterprise サブスクリプションをお使いの方の多くは、会社のEメールアドレスとユーザーアカウントとして使用されていると思います。そしてSSOを有効化するときには、そのEメールアドレスのドメインを対象にSSOを有効化することになります。結果としてSSOを有効化したテナントでは、そのドメインのユーザー全員に対してSSOが強制化されます。
このとき！
「会社の中で他にテナントがあったら影響ないの？？」
「会社のメアドで個人で使ってる人には影響ないの？？」
って気になっちゃったりしませんか？

実は、影響があるんです。いや、あったりなかったりするんです。
次の項目で詳しくみていきましょう！

例えばSSOを強制化したテナント（図の上段）と、SSOを有効化していないテナント（図の下段）が会社の中にあったとします。
このとき、上段のテナントにいるユーザーは全員SSOが強制化されますが、下段のテナントにいるユーザーにはSSOが強制化されません。
ただし、両方にアカウントがあるユーザー（図の中のsteve @ mirojpse.com）は、よりセキュリティの高い設定が優先されるためSSOは強制化されます。

じゃあアカウント登録さえ気をつけてれば大丈夫！って思いますよね？
でもmiroの特性上、そういかないケースも考えられます。miroは気軽にコラボレーション相手をボードに招待して即コラボレーションを始められるソリューションなわけですが、この「招待」によって思わぬ影響があることがあるんです。
次の章で詳しく見ていきましょう！

右の図でアイアンゴーレムさんがスティーブさんとコラボしようと上段のテナントに招待します。
でもスティーブさんはすでに他のテナント（下段）のユーザーで、普段はユーザーIDとパスワードでログインしている人でした。
そしてアイアンゴーレムさんが招待した瞬間に上段のテナントにもアカウントが存在することになりますので、SSOが強制化されることになります。
しかしながら、このときEntra IDの管理者はスティーブさんがSSOの対象になったなんて気づいていませんので、Entra ID上ではmiroへのSSOをスティーブさんに割り当てていません。

結果としてスティーブさんはmiro自体にログインができなくなり、元々使っていた下段のテナントにもアクセスすることができなくなってしまいました。
とさ。

IDP（今回はEntra ID）の方でアプリケーション側にユーザーが追加されたことを気づいて自動でそのユーザーをSSO対象に割り当てるとか、、難しいですよね？ちょっと私は簡単な方法が思いつきません。
じゃあどうするか？
招待しない。これだとコラボレーションを始めるまでの時間がかかってしまってちょっと使いにくいですよね？
全社員をmiroにもIDPにも登録しておく。ぜひっ！！
そして、今回ご紹介するEntra ID側でうまい具合になんとかする方法になります。