次の方法で共有


【Azure for IT Pro】AD FS で独自に定義したクレームタイプを Windows Azure AppFabric ACS で受け取る

先日の投稿で紹介した資料には、Windows Azure AppFabric Access Contorol Service を使用して、外部のアイデンティティプロバイダーからセキュリティトークンを受け取る方法をステップバイステップで紹介しています。

資料:AD FS 2.0 と Windows Azuer AppFabric ACS V2 を使用した SSO の構築 第2.2版

まだまだ書き足りないことがあるので、BLOGを通じて少しずつ解説を加えていきます。ある程度たまったら資料をアップデートします。

さて。以前の投稿で「クレームタイプ(要求の種類)」の話をしました。クレームタイプによってクレームが識別されるので注意しましょう...というお話でした。クレームタイプの話をしたのは理由があります。

【IDM】AD FS や ACS を触るならば クレームタイプ(Claim Type、要求の種類)について理解しておくのが吉です

クレームタイプを理解しておくことの重要性を痛感するのは、身近な例では AD FS と Windows Azure AppFabric ACS の連携時です。つまり、以下のような環境ですね。

image

数字は、この環境におけるセキュリティトークンの流れを示したものです。

軽く解説しておきましょう。

① AD FS からセキュリティトークンが発行される
② ブラウザを経由して AppFabric ACS にセキュリティトークンが渡される
③ ACS が変換ルールを使ってセキュリティトークンを精査し、新しいセキュリティトークンを発行
④ 新セキュリティトークンがブラウザに返される
⑤ ブラウザは新セキュリティトークンをアプリケーションに渡す

このとき、皆さんに強く意識していただきたいのは、 です。

AD FS から発行されたセキュリティトークンは、ACS によって分解され、クレームの中身がチェックされます。このチェックに関するルールが、「クレームルール(Claim Rule)」と呼ばれるものです。以下の図はセキュリティトークンが ③ を通過するイメージを描いたものです。

image

AD FS によって発行されたセキュリティトークンは ACS に取り込まれたあと、以下のロジックでクレームルールが実行されます。

IF {

・セキュリティトークンを発行したアイデンティティプロバイダーは合っているか? and ・入力されたクレームタイプは正しいか? and ・クレームタイプに格納されている値は正しいか?

} Then {

・発行するクレームタイプ ・発行するクレームタイプに入力する値

}

このロジックを通過して発行されたクレームルールが、再度セキュリティトークンとしてACSによって署名され、ブラウザを経由してアプリケーションに渡されます。

....ということは....このルールに定義されていないクレームタイプは、アプリケーションに渡すことができません。

いくら、AD FS の設定画面でクレームの定義を行っても、ACS のルールに合致しなければACSを通過することができないわけですね。この問題に最も直面しやすいのは、AD FS で独自に「要求記述」を定義したときです。

AD FS と ACS の信頼関係を結ぶときには、AD FS のメタデータを ACS に読み込ませます。メタデータには AD FS で使用可能なクレームタイプが記述されており、ACS のクレームルール設定画面で「ルールの生成(Generate)」を実行すると、メタデータから読み込まれたクレームタイプが自動的にルールとして定義されます。

image

一度信頼関係を構築した後、新たに要求記述を定義したとしましょう。例えば、以下の「部署」「従業員番号」「会社名」「国」は後から定義したクレームタイプです。

image

AD FS 側のクレームルールで「国」を定義しても、ACS 側のクレームルールに「国」が記載されていなければ、ACS はクレームを受け取ることができません。

ではどうするかといえば、ACS のクレームルールに手動でクレームタイプを定義する必要があります。

以下は、ACS のクレームルール定義画面のうち、入力側のクレームルールを定義する部分です。見づらくてすいません。

image

① はクレームの発行元(Identity Provider)です。発行元が異なると真っ先にはじかれるので正しい発行元を指定してください。

② はクレームタイプです。もともとどこにも定義されていないので、自分で記述する必要があります。ここでは、以下のように記述しています。

https://schemas.tf.com/claims/co

もちろんこの値は、AD FS の要求記述に定義した値と同じものです。当然です。

ちなみに、最後に「/(スラッシュ)」を入れてしまうと、エラーが発生し、なぜか二度とルールを開けなくなるので気を付けてください!! https://schemas.tf.com/claims/co/

③ は②で指定したクレームタイプに入っているはずの値です。個々で指定した値に合致しなければ、IF文は True にならないので、新しいクレームは発行されません。今回は、Any を選択しているので「なんでもOK」という意味になります。

以下の画面は発行ルール部分です。これも見づらくてすんません。

image

④ では発行先のクレームタイプです。今回は入力と同じクレームタイプを指定しました。ちなみに、入ってきたものをそのまんまスルーする場合には、「Pass through input claims type」を選択してもOKです。

⑤ は発行先のクレームタイプに格納する値です。今回は入ってきた値をそのままスルーするので「Pass through input claim value」を選択しています。

以上の設定を行っておくと、以下のようにアプリケーション側で独自のクレームタイプを取得することができるようになります。

image

 

ACSに登録した AD FS のメタデータは後から入れ替えることもできるので、AD FS の新しいメタデータを再度ACSに取込み、ルールを再生成(Generate)してもOKです。

(参考) 【Azure for IT Pro】Azure AppFabric ACS で、入力クレームを無条件スルーするための設定

Comments

  • Anonymous
    December 27, 2013
    Pingback from ???Azure for IT Pro???AD FS ???????????????????????????????????????????????? Windows Azure AppFabric ACS ??????????????? : Erez Benari's Blog : The Official Microsoft IIS Site