皆さんこんにちは。国井です。
このブログでは様々なトピックを取り上げて、色々な方にアクセスしていただいたおかげで10年以上が経過しました。その間にもテクノロジーは進化し、わかりやすいところで言えばADFSサーバーからAzure ADへの変化があったわけです。
ところが私が過去に執筆したADFSに関する投稿は未だに一定のアクセス数があり、
今あるADFSサーバーに対峙している方もまだまだ多いのではないかと思います。
ニーズが少なくなったと考え、かつて開催していたADFSトレーニングはもう終了をやめてしまいましたが、もし必要な方がいたらと思い、今日はかつて提供していたADFSトレーニングのテキストを公開してみることにしました。
とはいえ300ページを超える大作なので、分割して提供していこうと思います。
※演習操作手順書については前提条件となる環境によって手順が異なるので、ここでは(一部)割愛してお届けします。
■ ■ ■
目次
第1章 ID 連携の概要
第 1 章では、デジタルアイデンティティの概要と ID 連携の必要性について解説します。ID 連携を実現するためにマイクロソフトが提供するソリューション、ADFS (Active Directory Federation Services) と Azure AD の概要について解説します。
コンピューター システムの世界では、人やモノなどを識別する情報として、ユーザー名やコンピューター名などの情報が存在します。このような、人やモノを識別する情報をデジタルアイデンティティ (ID) と呼んでいます。
デジタルアイデンティティには、人やモノを識別する情報に付随する情報が含まれます。例えば、ユーザー名の場合、ユーザー名に付随する情報として、部署名、役職、事業所、電話番号などの情報がありますが、これらの情報もデジタルアイデンティティに含まれます。
デジタル アイデンティティを正しく確認できることで、コンピューターシステムでは、一人ひとりに合わせた適切なサービスを提供できるのです。
私たちがコンピューター システム上に存在する、様々なアプリケーションを利用する際、特定の利用者だけにアプリケーションを利用できるように ID の確認を行います。それが認証と承認です。
認証とは「本人確認」のことであり、コンピューターシステムの世界では一般にユーザー名とパスワードを利用して本人確認を行います。認証というと、ユーザーの認証が有名ですが、実際にはコンピューターの認証やサービスの認証など、様々な ID を対象に認証を行うことができます。
認証を通じて「本人確認」を行うことにより、誰かになりすましたユーザーであるか？、どこかのコンピューターになりすましたコンピューターではないか？など、「なりすまし」を防止する効果があります。
Active Directory の場合、ドメインをひとつの管理単位として認証と承認を行っています。Active Directory の認証と承認では、Kerberos (ケルベロス) と呼ばれる認証・承認のシステムを採用し、認証に成功すると、認証成功のあかしとしてドメインコントローラーから TGT と呼ばれるチケットが発行されます。
Active Directory で行った認証の結果に基づいて、クラウドや業務提携を結ぶ別組織への認可を行う仕組みを提供するのが ADFS サーバーです。ADFS サーバーでは認可を行うために使用する ST チケットの代わりに、クラウド等で汎用的に利用可能な「トークン」と呼ばれるデータを利用します。
Active Directory ドメインコントローラーと ADFS サーバーは次のような方法で連携し、クラウドや業務提携を結ぶ別組織への認証・認可を実現します。
① ユーザーはドメインコントローラーで認証
通常のサインインと同じように、ユーザー名とパスワードを入力してドメインコントローラーで認証を行います。
② 認証結果に基づき、ADFS でユーザーにトークンを発行
Active Directory で行われた認証の結果に基づき、ADFS サーバーに対してトークンの要求を行います。ADFS サーバーは要求を行うユーザーに合わせて、名前やメールアドレスなどの情報 (クレーム) を含めたトークンを発行します。
また、トークンを発行するときには、あらかじめ条件を設定し、条件を満たさないユーザーからのトークン発行要求に対して、トークン発行そのものを拒否する認可機能を備えています。
③ トークンをアプリに提示して最終的なアクセス許可レベルを決定
トークンを取得したユーザーはアプリに対してトークンを提示し、アクセス許可を得ます。どのようなアクセス許可が割り当てられるかはトークンの中に含まれるクレームの情報に基づいてアプリが決定します。
以上のような流れで処理を行うことによって、次のようなメリットが得られます。
認証と認可を行う組織を別々にできる
ADFS サーバーを利用することによって、認証を行うサーバーと認可を行うサーバーを別々のサーバーにすることができます。つまり、認証サーバーと認可サーバーを異なる組織に配置して運用することが可能です。
クレーム情報をもとに認可が行える
ドメインの場合、ユーザーやグループを基準にアクセス許可を割り当てていました。ドメインで発行されるチケットにユーザーやグループの情報が含まれていたからです。しかし、ADFS サーバーを利用する場合、トークンに含まれる情報 (クレーム) は自由に決められます。そのため、アプリが求める情報をトークンに含まれるように構成したり、部署名や役職などをクレームに入れて部署名や役職名をもとにしたアクセス許可を設定したりすることができるようになります。このように ADFS サーバーを利用した認証・認可はクレーム情報をもとに処理されることから、「クレーム ベース認証」と呼ばれることがあります。
組織間でシングルサインオンが実装できる
クレーム ベース認証は認証と認可を行う組織を別々にできます。そのため、自分の組織で 1 度だけ認証を行い、その認証結果をもとに別の組織で認可を行う、組織間でのシングル サインオンが実装できるメリットがあります。
クレーム ベース認証では、ID 情報を認証側だけに持たせて運用する方法と、認証側・認可側の両方に持たせる方法があります。
クレームベース セキュリティ
クレーム ベースセキュリティの場合、認可サーバー側で ID 情報を持ちません。認可サーバーでは、トークンに含まれる ID 情報を使って、ID を識別します。ADFS サーバーを利用する多くのアプリケーションではクレーム ベース セキュリティの方法で、認証サーバーと認可サーバー間の連携を実現しています。
ID 連携
ID 連携の場合、認証サーバーと認可サーバーの両方でID 情報を持ちます。認証サーバーで認証した結果に基づいてトークンを渡すことで、認可サーバーにおける特定の ID で認証を済ませたとみなします。この方法で連携する場合、認証サーバーと認可サーバーで同じ ID 情報を持たなければならないため、Microsoft Forefront Identity Manager (FIM) などを利用して、ディレクトリ サービスに格納されている ID 情報を同期します。このとき、ID 情報を同期し、認可のサーバーに ID 情報を登録するプロセスを「プロビジョニング」と呼びます。
ADFS サーバーで発行されるトークンは 1 つ以上のクレームから構成されています。クレームとはユーザーなどの特徴を表す情報で、クレーム ベース認証では、名前、メールアドレス、電話番号などの様々な情報を扱うことができます。
クレーム ベース認証で扱われるユーザー情報は、認証サーバーに格納されている情報を活用することができます。例えば、Active Directory ドメインを認証サーバーとして利用していれば、Active Directoryユーザーのプロパティに登録されている属性情報をクレームとして利用できます。
1 つ以上のクレームから構成されるトークンは、ADFS から発行された後に改ざんされることのないよう、トークン全体に対してデジタル署名を施します。このとき、デジタル署名に使われる証明書を「トークン署名証明書」と呼びます。
前のページで ID 連携を利用することで、認証側で認証したユーザーと認可側で保有するユーザーを関連付けて、シングルサインオンを実現できることを解説しました。
では、2つのディレクトリに格納されているユーザーはどのように関連付けるのでしょうか？
ID 連携で 2つのディレクトリに格納されているユーザーを関連付けるときは、あらかじめキーとなるクレームを決めておき、そのクレームの値が同じであるかをチェックすることで、2 つのユーザーが同一のユーザーであると判断します。
クラウドで提供されるアプリで ID 連携を実装する場合、Google Apps や Salesforce では
NameIdentifier クレームに含まれるユーザー名 (メールアドレス形式) が 2つのディレクトリで同一であることをチェックします。
ID 連携のためのプロビジョニング
2つのディレクトリにある ID を連携させるためには、プロビジョニングを行い、2 つのディレクトリに同じ ID を持つ必要があります。Office 365 では、後述するディレクトリ同期ツールによって、2つのディレクトリでの同期を実現しますが、その他のアプリでは何かしらの方法で ID 同期を行う仕組みを持つ必要があります。
編集後記
ADFSトレーニングは2017年8月の開催を最後に開催していないのですが、会計で言うところの減価償却も終わっただろうし、有償で受講していただいた方にお届けしてから3年以上も経過するので、もう良いだろうと思い、公開することにしました。
Advent Calendarっぽく25回に分割してお届けしますので、ゆっくりと読み進めてもらえれば嬉しいです。
<続く>
