[MSA]同一メールアドレスでマイクロソフトアカウントとAzure ADアカウントを利用するリスク

こんにちは、富士榮です。

先日、職場または学校のアカウント（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

[MSA]職場または学校のアカウントで新規サインアップが不可に

こんにちは、富士榮です。

ID & IT Management Conference 2016の準備などで多忙だったので、色々とスルーしていた間にあった重要な発表を少しづつキャッチアップしていきたいと思います。

以下が9月上旬～中旬で発表された割と重要な発表です。（私基準です）

1. マイクロソフトアカウント（MSA）へ職場または学校のアカウントで新規サインアップ不可に
2. Azure Active Directory Premium P2の提供開始
3. 新ポータルでAzure Active Directoryの管理が可能に
4. MicrosoftとPing Identityの提携によるレガシーアプリへのSSO拡大
5. Azure AD Connect 1.1.281.0のリリース

取り敢えず今回は1の「マイクロソフトアカウント（MSA)へ職場または学校のアカウントで新規サインアップ不可に」をお届けします。

9月15日に公式アナウンスが出てきました。（割と突然だったので私もびっくりしました）

　Cleaning up the #AzureAD and Microsoft account overlap
　https://blogs.technet.microsoft.com/enterprisemobility/2016/09/15/cleaning-up-the-azure-ad-and-microsoft-account-overlap/


早速内容を見ていきます。

◆これまでの課題

マイクロソフトのサービスを利用するには、職場また学校のアカウント、つまりOffice365やAzure Active Directory（Azure AD）で管理されているアカウント、もしくはマイクロソフトアカウント（従来のLive ID。MSA）を使ってログインする必要があります。

ただし、マイクロソフトアカウントはlive.comやoutlook.comなどマイクロソフトが用意しているドメイン以外に既存のメールアドレスを使ってサインアップすることも可能でした。

ここでOffice365やAzure ADのアカウントを使ってサインアップすると同じユーザ名のアカウントが職場または学校のアカウントおよびマイクロソフトアカウントの両方に出来上がることになり、マイクロソフトの提供するサービスへログインする際に以下のようなアカウント選択画面が表示されてしまいました。

これは一般利用者にとってわかりにくく、しばしば混乱を招いてきました。

◆今回のマイクロソフトによる対策のポイント

かなり乱暴な対策ではありますが、すでにOffice365やAzure ADで管理されているドメインのメールアドレスを使って、新規にマイクロソフトアカウントへサインアップすることが出来なくなりました。

これで新規ユーザは同じユーザ名でOffice365/Azure ADとマイクロソフトアカウントの両方にIDが作成されることは無くなりますので、ID選択画面が表示されることは無くなります。

では、既に作成済みのアカウントや、後からOffice365/Azure ADにドメイン追加されたアカウントの場合はどうなるんでしょうか？

結論、既存のマイクロソフトアカウントのIDを変更する、というのが答えです。

◆既存のマイクロソフトアカウントのIDを変更する

注意点を含む詳細はこちらのページで解説されていますので、確認して対応してください。

　https://support.microsoft.com/ja-jp/help/11545/microsoft-account-rename-your-personal-account

基本は既存のアカウントに新しいメールアドレスをエイリアスとして追加、プライマリ側と入れ替えた後、Office365/Azure ADと重複しているメールアドレスを削除するという方法です。

◆影響があるサービスがあるので注意

公式ページにも記載がありますが、職場のメールアドレスでサインアップしたマイクロソフトアカウントでないと利用できないマイクロソフトのサービスが一部あるので、職場のメールアドレスがOffice365/Azure ADで利用しているドメインと一致している環境においては、マイクロソフトアカウントのメールアドレスを切り替えるとそれらのサービスが使えなくなります。（新規にはサインアップすらできないので、当該環境において新規ユーザはそれらのサービスを使うことは出来なくなっています）

例えば、

・Windows Dev Center

・Microsoft Partner Network

などに影響があるようです。

また、既存のアカウントのメールアドレスを変更することによりデバイスのリセットなどをする必要がある場合もあるので、こちらも要注意です。

例えば、

・Windows Phone 8を使っている場合はデバイスのリセットが必要になります

・一部XBox開発ツールを使っている場合は別のIDになってしまいますので、実質アカウント作成し直しとなります

などが大きな影響といえます。

◆まとめ

MSALやv2エンドポイントなどAzure ADアカウントとマイクロソフトアカウントのコンバージが進む一方で、IDの重複問題が長年の懸案事項となっていたので、今回の対策は長い目で見れば非常に有益なことだと思います。

そもそも同じ識別子を持つ複数のIdPで同じサービスが利用できてしまうというのは、保証レベルの面などセキュリティ的にも重大な問題でした。例えば、個人の自己申告でサインアップできてしまうマイクロソフトアカウントを在職中に作成、退職後も継続的に利用しているケースにおいて、いくらAzure AD側で退職アカウントを削除したとしても、MSALを使ったコンバージ・アプリケーションへ職場のメールアドレスを使ったサインインが継続的に可能になってしまう、という課題です。

他方でMPNなど重要なサービスが職場メールアドレスのMSAでしかアクセスできないなど、過渡期に解決すべき課題もあるので、若干性急な気もした今回の対策ですが、早期に各サービス側での対応をすすめ、一日も早く綺麗な姿でサービスを提供できるようになってもらいたいものです。