Visual Studio Team Services(以下VSTS)には二種類の認証方法があります。MSアカウントとAzure ADです。MSアカウントは原則個人向け、Azure ADは会社などで使う場合に向いています。
どちらを選んでもVSTS自身の機能差はありませんが、Azure ADを選ぶと、Office 365との連携が便利になる場合が多いです。例えば、Teamsとの統合やAzure ADのグループをそのままVSTSのグループとして扱える、という点ですね。
Azure AD側で「xxPJ開発チーム」というグループを作って、VSTSのチームプロジェクトにできると管理が一元化されて便利です。
さて、そんなAzure ADですが、Office 365の認証基盤でもあるため、先にOffice 365を導入しているところも多いと思います。そうなると、VSTSもOffice 365のAzure ADで認証させたい、と思う方も多いと思います。
しかし、たいていの大きな会社ではOffice 365を管理している部門と、開発者は別というか、非常に遠い。そして、VSTSなんか入れてなんかあったら困る、という問題もあります。
特にこんな風に外部のパートナーさんに追加してほしい場合、Office 365のライセンスを発行するというのは費用面やアカウント管理としても面倒です。Office 365を使っていないとしても、Azure ADのP1やP2であればユーザーごとに結構な費用がかかります。
私も困っていたのですが、そんな時はこうすればいいんじゃないか、という話を教えてもらいました。
- 新規にAzure ADを用意する。Azure ADそのものは無償で作れます。
- そのAzure ADのテナントにVSTSを作る(まだ無償)
- Azure AD B2Bで新規に作ったVSTS用Azure ADに参加する。
- パートナーさんがいる場合も、パートナーさんのAzure ADのユーザーをB2Bで追加する。
重要なのは必ずB2Bで参加するという点で、VSTS用のAzure ADでユーザーを作らないということです。仮に作ってしまうと、パートナーさんが自分たちのAzure ADを作った、もしくは持っている場合、パートナーさんのユーザー管理や認証がややこしくなります。
Azure AD B2Bを使うとき、セキュリティ的な問題で多要素認証を使いたい場合、有料のBASIC, P1, P2が必要になります。しかし、そんなときでもあくまでもVSTS用のAzure ADサブスクリプションにかかるので、所属会社への費用は発生せず、お金的にも分離が可能ですね。
Team Foundation Serverの時代にWorkgroupでサーバーのユーザーで管理していた癖で、VSTS用のAzure ADにユーザーを登録したくなるかもしれませんが、絶対にやめたほうがいいでしょう。
仮にこれがSIの受託開発だった場合も大して変わりません。最終的にAzure ADおよび、VSTSの所有者をお客さんに変更すればそれが納品物、もしくは環境の移管ということになります。実際にそういうことをやられている方もいるようです。
プロジェクトの最終納品がVSTSのアカウントそのものになったw 金融機関なのになんといい時代なんだ！VSTSのアカウントはオーナー変更ができるこら便利だよ。
— miyake@PaaSがかり (@kazuyukimiyake) December 22, 2017
