企業でWindowsを利用している方の場合、多くのケースにおいてActive Directoryを使っていると思います。そして、Active Directoryを使えば、どこにアクセスするときでもWindows起動時に、1度だけユーザー名とパスワードを入力すればよい、ということは既に経験されていることと思います。
ところが、最近はクラウドのサービスが出てきて、あちこちでユーザー名とパスワードを入れなければならないケースが増えています。なんで、Active Directoryを使っているのに、何回もユーザー名とパスワードを入力しなければならないのか？
今日は、そんなお話しをしたいと思います。
■ ■ ■
私がまだ大学生だったころ、ニュージーランドからの留学生で「アンドリュー」という友達がいました。アンドリューと私はある理由からスキー場のシーズン券を購入し、毎日スキーを楽しんでいました。アンドリューは特別スキーがうまいわけでもないのだけど、どういうわけか、すべての動作がいつも早い。どうして、そんなに機敏な動作なのだろうと観察していると、私はあることに気がついたのです。私はリスト乗り場で顔写真入りのシーズン券を係員に見せてリフトに乗っているのに、アンドリューはまったくシーズン券を係員に見せていないのです。
どうして、シーズン券を持っていないのにリフトに自由に乗ることができるかといえば、アンドリューは典型的なアングロサクソン系の顔立ち。明らかに周りの人とは異なるので、係員のおじさんはアンドリューの「顔」を見て、アンドリューという人であること、そしてリフトに乗れる人であることを判断していたのです。
私は毎回、毎回、シーズン券を見せて「正規」の手続きをしていたのですが、これが面倒くさい。詳細は割愛しますが、今の私たちの置かれている立場で言えば、ユーザー名とパスワードを毎回入力するようなものです。ユーザー名とパスワードを毎回入力するのは面倒くさいから、かつてのアンドリューのようにスムーズにアクセスできないものか？ということで登場したのがID連携(=フェデレーション)と呼ばれる技術です。
ID連携は、「顔写真入りのシーズン券を見せる」という行為を毎回行うのは面倒だから、「一度、顔写真入りのシーズン券を見せたら、次からは顔だけ見せてくれればよい」という具合に、アクセスを簡略化してしまうものです。そして、「顔だけ見せればOK」というスキー場を増やしていけば、どこのスキー場に行ってもシーズン券を見せる手間はいらないですね。こうした手間を省く技術がID連携(このケースでは、スキー場の連携ですね)になります。
これがコンピューターの場合だったら、どうなるか？Active Directoryでユーザー名とパスワードを入力したら、どこのクラウドにアクセスするときもActive Directoryで既にサインインしたことがわかる情報だけ送ってもらえればOKとするのです。そして、Active Directoryと連携するクラウドを増やしていけば、どこのクラウドにアクセスするときもユーザー名とパスワードを入力する手間はいらないですね。これがActive DirectoryとクラウドのID連携になります。
では、Active Directoryがあれば、どこでもユーザー名とパスワードを省いてクラウドにアクセスできるようになるかというと、残念ながら現在のところ、それはできません。Active Directoryでユーザー名とパスワードを入力してサインインすると、Active Directoryの中だけで有効な情報(＝Active Directoryでは、これをKerberosチケットと呼ぶ)しか生成されないからです。
しかも、クラウドの各種サービスにアクセスするときは、先ほどのリフト乗り場における「顔パス」のように「顔」に当たる情報を提示しなければなりません。この情報はクラウドのサービスごとに異なり、たとえば、Office365だったらImmutable IDと呼ばれるID番号をクラウドに提示しなければなりません。(現実世界だったら、「顔」という万国共通のID(？)情報があるのですが、コンピューターの世界では統一されたものってないのです。それには理由があるのですが、ここでは難しい話を抜きにしたいので、別の機会にしましょう)
このように、どこのクラウドサービスを利用するかによって、提示すべき情報は異なるのに、Active Directoryで生成されるチケットにはActive Directoryのためだけに必要な情報しか記載されていない。
whoamiコマンドでKerberosチケットの中身をのぞいた様子。ADのために必要な情報しか入っていない。
このような問題を解決するために使われるのがActive Directoryフェデレーションサービス、通称ADFSと呼ばれるサービスです。ADFSはActive Directoryにサインインした後に生成されるチケットをもとにクラウドで利用可能なチケット(=トークンといいます)を生成するサービスです。ADFSがあれば、ユーザー名/パスワードの代わりとなる情報(トークン)をそれぞれのクラウドに合わせて作ってくれるので、様々なクラウドのサービスへのアクセスが、アンドリューの「顔パス」のごとく、簡単になるのです。
参考までに、上の図では、クラウドにトークンを利用してアクセスするときの一連の流れを書いてみました。
この流れの中で、ユーザー名とパスワードを入力しているのは1．のサインインを行うところだけで、
クラウドのサービスにアクセスするためにユーザー名とパスワードを入力することはありません。
それから、こちらの画面はトークンの中身をのぞいてみた様子です。このトークンにはメールアドレスが入っていますが、他にもADFSで定義した情報だったら、なんでも自由に入れられます。先ほど、Office365にアクセスするにはImmutable IDというID情報が必要だという話がありましたが、このトークンの中にImmutable IDを入れておけばOffice365へのアクセスも「顔パス」になります。
ここまでの話をまとめましょう。
ID連携(フェデレーション)とは、複数のユーザー名とパスワードを入力しなければならないという面倒くさい作業を1回で終わらせてくれる連携機能であることを紹介しました。さらに、ID連携ではトークンと呼ばれる情報を提示する際に、クラウドで必要とされる情報をトークンにくっつけて提示することができることを紹介しました。
そして、ADFSというサーバーはActive Directoryでは作成できない、クラウドにアクセスするために必要なトークンを発行してくれるサービスだということでした。
以上の事から、ADも、クラウドも、一度のユーザー名/パスワードの操作でどちらにもアクセスできるようにしたいと思ったら、ADFSを使います、ということがお分かりいただけたと思います。
(ADFSが唯一の選択肢ではないのですが、その話はまた別の機会に)
■ ■ ■
ID連携は非常に複雑な技術です。今日の話は、話を分かりやすくするために多少デフォルメして説明しています。
認証と認可がごっちゃになっている、ID連携とシングルサインオンはイコールではない、などなど、突っ込みどころ満載だと思いますが、
細かいことは抜きにして、まずは大まかな概要とメリット、この2つを理解してもらえれば、うれしいです。
最後になりますが、
ADFSとは？フェデレーションとは？を実践で役立てるべく、ハンズオンで学習したいという方は、私が登壇しておりますトレーニングコースがございますので、そちらも検討してみてください。
