先日、職場または学校のアカウント（Azure Active Directory/Office365で管理されているアドレス）で新規にマイクロソフトアカウントをサインアップすることが出来なくなった、という話を紹介しました。
[MSA]職場または学校のアカウントで新規サインアップが不可に
http://idmlab.eidentity.jp/2016/09/msa.html
MPNやXBoxの開発関係など、まだAzure ADでのサインインをサポートしていないマイクロソフトのサービスが存在しているにも関わらず上記のような制限をかけたことについて、乱暴で性急な対応だ！という声も各国から上がっていますが、今回は逆にこれまでの様に複数のアカウントで識別子が共通になってしまっている状態だと何が起きえるのか？について考えてみたいと思います。
◆マイクロソフトアカウントでもAzure ADアカウントの両方でアクセスできるサービスを用意する
一番手っ取り早い方法として、Azure ADのOpenID Connectのv2 エンドポイントを使ったアプリケーションを開発してみます。詳細は省くのとかなり手抜きなコードなので色々とツッコミどころはありますが、こんなコードを書きました。
◆アクセスする
v2 エンドポイントを使ったアプリケーションにアクセスし、ログインID（メールアドレス）を入力すると、ログイン用のIDをマイクロソフトアカウントとAzure ADアカウントから選択する画面が出てきます。
◆Azure ADのアカウントでログインする
まずは、Azure ADのアカウントでログインします。職場または学校アカウントを選択すると、Azure ADのログイン画面へ遷移します。
結果、Azure ADからユーザ名をはじめとするID情報が取得できます。（id_tokenをほどいているだけですが）
preferred_usernameにログインIDが入っていることがわかります。
◆マイクロソフトアカウントでログインする
次にマイクロソフトアカウントでログインしてみます。先ほどのID選択画面で個人のアカウントを選択すると、マイクロソフトアカウントのログイン画面へ遷移します。
結果、同じくID情報が取得できます。
同じくpreferred_usernameにログインIDが入ってきています。
◆何を注意すべきなのか？
上記の例では、どちらのアイデンティティ・プロバイダでログインしても同じ値がpreferred_usernameに入ってきてしまっています。この状態でユーザをpreferred_usernameで識別してしまうと便利な反面、セキュリティ面で問題があると言えます。個人でID登録できるマイクロソフトアカウントと管理者が登録・管理を行うAzure ADではIDの管理レベルが全く異なるからです。上記のようなアプリケーションはB2BやB2Cのシナリオではそれほど珍しいものではありません。
アプリケーションが内部で自社のドメインのユーザからのアクセスならば管理メニューを出して、それ以外なら一般向けのメニューしか出さない、というようなロジックを書くこともあるためです。
通常は、自社ドメインのユーザは退職したら削除または無効化されログインできなくなるので、一見セキュリティ上問題はないように思われますが、退職前に自社ドメインのメールアドレスでマイクロソフトアカウントを作ってしまっていた場合、退職後も継続して管理メニューにアクセスできてしまうことになります。
今後は、マイクロソフトが新規にAzure ADやOffice365で使っているドメインのアカウントでマイクロソフトアカウントを作成することを禁止したので、すでにAzure ADやOffice365にドメインを追加している場合は、問題は減っていくとは思います。
ただ、
・現時点でAzure ADやOffice365に自社ドメインを追加していない
・すでに自社ドメインのアドレスでマイクロソフトアカウントを登録してしまっているユーザがいる
といった場合も多々あるはずなので、少なくとも「いくら信頼しているアイデンティティ・プロバイダとは言え、識別子だけで認可をすべきではない」ということを十分に認識してサービスの開発を行うべきだと言えるでしょう。
ちなみに、以前発生したOffice365のSAML SPの脆弱性も本質的には同じような問題に起因していましたね。
参考）
Office365のSAML脆弱性に見るマルチテナントSP実装時の注意点
http://idmlab.eidentity.jp/2016/05/office365samlsp.html
投稿
0 件のコメント:
コメントを投稿