前回、ADFSサーバーを設置してフェデレーション信頼を設定することで、
シングルサインオンが可能な範囲を広げられるという話をしました。
では、なぜADFSサーバーを利用することでシングルサインオンできる範囲を広げられるのか、
また、なぜActive Directoryではシングルサインオンできる範囲に限度があるのか、
ということについて紹介したいと思います。
(今日はわかりやすさ優先ですので、厳密には正しくない表現が含まれています)
■トークンとは
トークンとは、ユーザー名とパスワードを入力するなどして行った認証の結果、
「あなたは認証に成功しましたよ」ということを示すデータです。
日常生活でも、電車に乗るときには「切符」というトークンがあるでしょうし、
遊園地に行けば、「入場券」というトークンがありますね。
切符や入場券はひとつの目的のためにしか使わないトークンなので、
「お金を払った人です」ということがわかれば、それで十分なのですが、
コンピュータの世界で使うトークンの場合、必ずしもそうはいかないのです。
(次から具体的に見てみましょう)
■Active Directoryのトークンについて
Active Directoryでは、Kerberosという認証の仕組みを利用します。
Active DirectoryのKerberos認証では、正しいユーザー名とパスワードを入力して
認証を済ませると、TGTと呼ばれるトークンをもらうことができます。
TGTには、「Active Directoryで認証を済ませた●●というユーザーですよ」
という情報が入っています。
具体的にどのような情報が入っているか、見てみましょう。
マイクロソフトのWebサイトよりダウンロードして使えるtokensz.exeというツールを使って
「tokensz /compute_tokensize /dump_groups」というコマンドを実行してみました。
上の画面では、User、Groups、Privsと書いてある項目をそれぞれ見つけることができると思います。
・Userはユーザーの情報 (SIDと呼ばれるIDで記録されている)
・Groupsはユーザーが所属するグループの情報 (こちらもSIDで記録されています)
・Privsはユーザーが実行できる権限 (Se～という文字列で表されています)
以上がActive Directoryで発行されるトークンに含まれている情報です。
Active Directoryで発行されるトークンには必ずこれらの情報が含まれているのですが、
しかし言い方を換えると、トークンに含まれる情報はカスタマイズできないのです。
実はこのことが、シングルサインオンできる範囲を拡張するのに大きな障害となっているのです。
例えば、
Active Directoryではユーザーやグループの情報をSIDという情報で識別しますが、
SIDという情報はActive Directoryでしか使いません。
そのため、Active Directoryが、Active Directory以外の他のシステムと連携しようとしても、
「SIDなんて情報を渡されても、そんなもの知らないよ」となってしまうのです。
つまり、Active DirectoryのトークンはActive Directoryのためだけに作られたものであり、
他のシステムとの連携というのは、もともと考えになかったのだと思います。
■ADFSサーバーのトークン
ADFSサーバーの場合、認証を行うサーバーとトークンを発行するサーバーが別々になっています。
・認証にはActive Directoryを使う
・トークンの発行にはADFSサーバーを使う
という仕組みを採用しています。
そのため、Active Directoryとは異なるタイプのトークンが発行できることがわかると思います。
さらに、ADFSサーバーはトークンを発行するときに、どのような内容を含めるか定義できます。
それでは、実際に発行されたトークンを見てみましょう。
ADFSサーバーで発行されたトークンの内容をそのまま表示するサンプルASP.NETアプリケーションを
使ってブラウザーからアクセスした様子がこちら。
Claim Typeという欄にトークンに含まれる項目、
Claim Valueという欄にトークンに含まれる項目の値
が含まれています。
このようにトークンに含まれる情報は、ADFSサーバーで決められています。
ADFSサーバーの設定画面はこちら。
Active Directoryから取得した「電子メールアドレス」の情報と「役職」の情報を
トークンに入れなさいと設定してあります。
このように、
トークンの中に入れる情報を自由に定義できれば、
Active Directoryだけでなく、他のシステムとの連携(そしてシングルサインオン)が
自由に設定できるようになるのです。
もちろん、トークンそのものの規格の問題などもあり、
世界中のどのシステムともシングルサインオンができるわけではありませんが、
少なくともActive Directoryの持つシングルサインオンの課題を
ADFSサーバーはクリアしてくれていることがお分かりいただけたかと思います。
■次のステージへ
1回のログオン操作で様々なシステムにアクセスできるシングルサインオン。
かつて、Active Directoryが導入された背景には
「社内の様々なサーバーにアクセスするためにシングルサインオンできるようにする」
というのがあったかと思います。
時は流れ、クラウドを意識しなければならない時代になり、
私たちは再びオンプレミス(Active Directory)とクラウドの間での
シングルサインオンをどうやって実現するか？という課題に直面しています。
「アクセスするサイトごとにパスワードを変える」なんていう方法もありますが、そんなやり方よりも
どこへアクセスする場合であってもシングルサインオンが実現できる環境を整えることこそが、
ユーザーの利便性とセキュリティの両方を高度に実現できる方法だと思うのです。
