皆さんこんにちは。国井です。
前回からスタートしたADFSトレーニングテキスト全文公開チャレンジ。
Advent Calendar風に毎日公開していこうかなと思っているのですが、
第2回は「第1章 ID連携の概要」から後半部分の「ID連携とは」をお届けします。
■ ■ ■
ADFS サーバーを利用して ID 連携を実装する場合、アクセスするアプリが自社内にあるのか、またはクラウドなどの領域外にあるのかによって認証・認可のステップは異なります。
自社内にあるアプリにアクセスする場合、Active Directory で認証を行った後、同じく自社内にある ADFS サーバーが認可を行った結果としてアプリのためのトークンを発行し、そのトークンを持って直接アプリにアクセスします。そして、アプリはトークンの内容に基づいて最終的なアクセスの可否を決定 (認可) します。
それに対して、領域外にあるアプリにアクセスする場合、異なる領域で利用可能なトークンを発行した上でアプリにアクセスする必要があります。そこで、ADFS サーバーでは、異なる領域のトークンを発行するサーバー(トークンを発行するサーバーを STS と呼びます。詳しくは後述します。) にアクセスするためのトークンを発行します。
以上のような動作によってアクセスの可否を決定するため、ADFS サーバーとアプリでの認可に加えて、STSでの認可も同時に行うことができます。
次のページから、領域外にあるアプリにアクセスする場合を例に、具体的にそれぞれのサーバーにアクセスする際の処理について解説します。
ADFS を利用して ID 連携機能を実装した場合、以下のような動作で認証と認可の処理を行います。
① アプリケーションにアクセスすると、セキュリティ トークンを要求される
クライアント コンピューターから ID 連携を利用したアプリケーション (APP サーバー) に接続すると、トークンが必要であることをクライアントに通知 (リダイレクト) します。
② 認可側の ADFS サーバーにアクセスし、認証先を指定される
トークンが必要であることを知ったクライアント コンピューターは①で得た情報をもとに認可側の ADFS サーバーに接続します。ここで、クライアント コンピューターが認証を行う先を紹介します。もし、複数の認証先が存在する場合には、クライアントコンピューターから選択することも可能です。
③ 認証側の ADFS サーバーにアクセス
②の結果、どこで認証を行うか決定したら、クライアントコンピューターは認証を行う場所にある ADFS サーバーに接続します。すると、トークンを取得するために事前に認証を行うよう、認証用のエンドポイント (Web ページ) にリダイレクトします。
④ 認証側の ADFS サーバーで認証を要求
クライアント コンピューターは ADFS サーバーの認証用ページにアクセスすると、認証を開始します。あらかじめ決められた認証方法に基づいて、認証を行います。
⑤ 認証 & 属性値の取得
クライアント コンピューターから④で入力した資格情報は認証側の ADFS サーバー経由で認証システムに送信され、正しい資格情報であることを確認します。ADFS では、認証システムに Active Directory を利用するため、Active Directory に対して資格情報の確認を行います。認証が成功すると、その結果をもとに、メールアドレスや姓名など、ユーザーの属性値を Active Directory から取得します。属性値の取得は Active Directory からだけでなく、SQL Server や LDAP ディレクトリから取得することも可能です。
⑥ 認証結果をもとに特定のクレームが含まれるトークンを発行
⑤で入手した属性値をもとに、ADFS サーバーはユーザーのためのトークンを発行します。
資格情報の確認 (認証) は Active Directory が行ったのに対して、トークンの発行は ADFS サーバーが行う、というように、認証とトークンの発行は別々のサーバー役割によって行われている点に注目してください。
⑦ 認可側の ADFS サーバーにアクセスし、トークンをもとに認可を行う
認証トークンが発行されると、クライアント コンピューターはトークンを持って、認可側の ADFS サーバーにアクセスします。すると、ADFS サーバーは認証トークンを確認し、アクセス可否を判断します。また、ADFS サーバーであらかじめ定義されたルールに基づき、認証トークン内のクレームは必要に応じて書き換えられ、認可トークンとして利用できるようにします。
⑧ 認可側の ADFS サーバーで発行されたトークンを利用してアクセス
認可トークンを受け取ったクライアント コンピューターは、認可トークンを持って、アプリケーションサーバーにアクセスします。すると、アクセスに必要な権限を持ったユーザーとみなし、アプリケーションへのアクセスを許可します。
以上のように、ADFS サーバーでは ID 連携の方式に基づく、認証と認可を行うことにより、異なる組織にあるアプリケーションにアクセスできるようになります。
このとき、認証側と認可側に ADFS サーバーをそれぞれ配置することで、ID 連携における、認証と認可を別々の場所で行うことができます。
前のページでは、ID 連携の動作詳細について確認しました。一連の動作の中で利用された資格情報とトークンについて、整理しましょう。
Windows 認証に使用した資格情報
手順④で行われた認証は Active Directory に対する認証です。この認証に成功すると、資格情報をもとにトークンを作成するための作業に入ります。
認証側 ADFS サーバーで発行されるトークン
Windows 認証を行った後、認証側 ADFS サーバーに対してトークンの要求を行います。ここで要求・発行されるトークンは、ID 連携で使われる、認証トークンになります。
認可側 ADFS サーバーで発行されるトークン
認証トークンを持って、認可側の ADFS サーバーにアクセスし、アクセスを認可された場合、新たなトークンが発行されます。このトークンは認可トークンになります。
前のページで 3 つの資格情報とトークンについて解説しましたが、そのうち、ADFS サーバーが発行するトークンとして認証トークンと認可トークンがありました。このように、ID 連携の中でトークンを発行するサービスを STS (Security Token Serivces) と呼びます。ADFS を利用している場合、ADFS サーバーがトークンを発行する機能を持っているため、ADFS サーバーは STS であると言えます。
また、ID 連携で認証と認可を行う場合、認証を行う側と認可を行う側に分かれて、それぞれ処理が行われていました。ADFS では、認証を行う側のシステム/ネットワーク全般を Claim Provider (CP)、認可を行う側のシステム/ネットワーク全般を Relying Party (RP) と呼びます。
なお、STS、CP、RP という名称については、ADFS における呼び方であり、ID 連携の規格のひとつである、SAML2.0 では異なる呼び方をします。詳しくは、「WS-Federation / SAML とは」のページを参照してください。
このテキストでは、ADFS における呼び方で名称を統一します。
RP 側の STS がCP側のSTSで発行した認証トークンの内容を解釈し、認可トークンを発行するとき、どのCP側のSTSから発行された認証トークンでも扱ってよいわけではありません。RPが信頼したCPから送られてきた認証トークンだけを扱うようにしなければ、悪意のある第三者が作成した認証トークンを疑いもせずにRPが処理してしまう可能性があるからです。
RPが適切なCPで発行された認証トークンだけを扱えるようにするために、STSでは信頼関係という設定を行います。信頼関係はSTSどうしで設定するもので、信頼関係を設定することで、決められたCPとRPの組み合わせで認証と認可を行うように定義できます。
クレーム ベース認証を行う際、利用可能な認証先が複数存在する場合、ユーザーはどこで認証を行うか選択することができると解説しました。このとき、利用可能な認証先の単位を「レルム (Realm)」と呼びます。複数のレルムの中から認証先をユーザーが選択すると、選ばれたレルムは CP として ID 連携の中で動作するようになります。
Active Directory ベースの認証と承認の仕組みを利用すると、承認の仕組みはアプリケーションの中で実装されます。アプリケーションの中で、誰にどのようなアクセス (権限) を割り当てるかを定義していたため、具体的な設定はアプリケーションによってまちまちでした。
一方、クレーム ベース認証 (ID 連携) を使ってアクセス制御 (認可) を行う場合、ADFS サーバーで認可トークンを発行するタイミングで行います。そのため、アプリケーションは認可のための仕組みを一切持つ必要がありません。つまり、アプリケーションと認可機能は独立して実装できます。
クレーム ベース認証を利用するアプリケーションは、認可を行わない代わりに、認可トークンを受信し、解釈できなければなりません。マイクロソフトでは Windows Identity Foundation (WIF) というコンポーネントを提供し、トークンの解釈とトークン内のクレームの識別を実現しています。WIF は ASP.NET または WCF アプリケーションと共に利用することができます。
WIF には実行環境を提供する WIF そのものと、WIF を利用した開発環境を提供する WIF SDK があります。WIF はアプリケーションがクレームを識別できるようにするためだけでなく、ADFS そのものの実行基盤にも活用されます。そのため、アプリケーションを実行するサーバーと、ADFS を実行するサーバーでそれぞれ必要となります。一方、WIF SDK はクレーム対応アプリケーションを開発する環境でインストールして利用します。
Visual Studio を利用して WIF アプリケーションを作成するには、Windows Identity Foundation SDK 3.5 以上が前提条件になりますので、事前にインストールしてください。
■ ■ ■
編集後記
このテキストを初めて作ったのは2012年頃で、まだID連携の必要性が世間で理解されていない頃でした。
当時は「ブラウザーにパスワードをキャッシュすればよいのに、わざわざサーバーをインストールする意味がわからない」などと言われたものです。
最後に今は亡きWIF(現.NET Framework内のコンポーネント)の説明を入れましたが、WIFが..というよりはADとクレームベースではアクセス制御の仕組みが違うんだよ、ということを知ってもらいたくて、あえて残しておきました。
明日もお楽しみに。
<続く>
