Embed Size (px)
DESCRIPTION
[構築作業 後編] AD FS Deep Dive 8.クレームパイプラインとクレームルール 9.カスタムルールの設定 10.AD FS 2.0 の監査
Citation preview
1
AD FSAD FS 2.02.0 DEEP DIVEDEEP DIVEAD FS 2.0 をもっと使いこなすために
1. クレームパイプラインと要求規則（クレームルール）2. カスタムルールの定義3. AD FS 2.0 の監査
2
用語について
基本的に、日本語 UI に沿った用語を使用します。が…ちょっとアレなところもあるので、以下の対応票を参考にしてください。
日本語 対応する英語
要求 Claim, クレーム
規則 Rule, ルール
要求の種類 Claim Type, クレームタイプ
要求記述 Claim Description, クレームディスクリプション
要求 プロバイダー Claims Provider, クレーム プロバイダー
証明書利用者 Relying Party, リライング パーティ
発行承認規則 Issuance Authorization Rules
受付変換規則 Acceptance Transform Rules
発行変換規則 Issuance Transform Rules
3
クレームパイプラインと要求規則（クレームルール）AD FS 2.0 Deep Dive
4
要求規則 (Claim Rule)
• 入力された情報をルール ( 規則 ) に沿って処理し出力する• 処理されたクレームは既定のパイプラインを通る
メンバーシップ
入力方向の要求
カスタム クレーム
他の要求プロバイダー
LDAP 属性
スルー
変換
フィルター
AD DSAD LDS
LDAP出力
SQL Serverその他
要求規則
5
要求規則セット (Claim Rule Set) のタイプ
• 受け付け変換規則 - Acceptance Transform Rule Set要求プロバイダー ー (AD DS, SQL Server, LDAP) から受け入れるクレーム セット
• 発行承認規則 - Issuance Authorization Rule Set証明書利用者 (RP) にアクセス可能なユーザーを明確にするためのルール。許可されたユーザーは「発行変換規則」からクレームを受け取れるため、証明書利用者へのアクセスが可能になる。
• 発行変換規則 - Issuance Transform Rule Set「受け付け要求規則」から発行されたクレーム セットを入力とし、証明書利用者 (RP) に発行するクレームを生成する
• 委任承認規則 - Delegation Authorization Rule Set他のユーザーの代理として証明書利用者 (RP) にアクセスできるかどうかを判断するためのルール
• 偽装承認規則 - Impersonate Authorization Rule Setユーザーが他のユーザーを偽装してアクセスできるかどうかを判断するためのルール。 Windows PowerShell で実装する。
6
AD FS 2.0 ～クレーム パイプライン
要求プロバイダー信頼(Claims Provider Trusts) 証明書利用者信頼 (Relying Party Trust)
証明書利用者(RP)
① 受付ける① 受付ける ③ 発行する③ 発行する
発行発行変換変換規則規則
inp
ut
ou
tpu
t
受け受け付け付け変換変換規則規則
inp
ut
ou
tpu
t発行発行承認承認規則規則
inp
ut
ou
tpu
tクレームストア
OK/NG
switchswitch
トークン
要求規則 (Claim Rule)
② 承認する② 承認する
7
受け付け変換規則• 「要求プロバイダー信頼」で設定する• 「証明書利用者信頼」に渡すためのクレームをセットする
大原則①ここで定義されたクレームのみが、パイプラインに沿って「証明書利用信頼」に渡される
大原則①ここで定義されたクレームのみが、パイプラインに沿って「証明書利用信頼」に渡される
① 受付ける① 受付ける
8
発行承認規則• 「証明書利用者信頼」で設定する• 「発行変換規則」に移行させるかどうかを判断• クレームは発行しない
この設定では「受け付け変換規則」を通過したユーザー全てに、「発行変換規則」への進行を許可
この設定では「受け付け変換規則」を通過したユーザー全てに、「発行変換規則」への進行を許可
② 承認する② 承認する
9
発行変換規則• 「証明書利用者信頼」で設定する• 以下を最終決定する
• ユーザーにセキュリティトークンを発行するかどうか• RP/SP にどんなクレームを送信するか
規定では空（何も発行しない）ただし、「認証メソッド」と「認証日時」だけは送信される
規定では空（何も発行しない）ただし、「認証メソッド」と「認証日時」だけは送信される
③ 発行する③ 発行する
10
クレームルールを定義するには？• 要求規則テンプレートを使用
• 規定で用意されているルールを使用する場合• [LDAP 属性を要求として送信 ]• [ グループ メンバーシップを要求として送信 ]• [ 入力方向の要求を変換 ]• [ 入力方向の要求をパススルーまたはフィルター処理 ]• [ カスタム規則を使用して要求を送信 ]• [ 入力方向の要求に基づいてユーザーを許可または拒否 ]• [ すべてのユーザーを許可 ]
• カスタムルールを定義• 用意されていないルール（ロジック）を使用する場合• 用意されていない ldap 属性を使用する場合• AD DS/ldap 以外のクレームストアを使用する場合
• SQL Server• その他（テキストファイル など）
[ 要求記述 ] に記載されていないクレームタイプは使用できないので、事前に定義しておく必要がある[ 要求記述 ] に記載されていないクレームタイプは使用できないので、事前に定義しておく必要がある
and くどいようですが…
11
（参考）既定の LDAP 属性
LDAP 属性の名前（ lDAPdisplayName)
Company (company)
Department (department)
Display-Name (displayName)
E-Mail-Address (mail)
Employee-ID (employeeID)
Employee-Number (employeeNumber)
Employee-Type (employeeType)
Given-Name (givenName)
Is-Member-Of-DL (memberOf)
Organizational-Unit-Name (ou)
Organization-Name (o)
Proxy-Addresses (proxyAddress)
LDAP 属性の名前（ lDAPdisplayName)
State-Or-Province-Name (st)
Street-Address (street)
Surname (sn)
Telephone-Number (telephoneNumber)
Title (title)
Token-Groups (SID) (tokenGroups)
Token-Groups - ドメイン名を含む (tokenGroups)
Token-Groups - 完全修飾ドメイン名を含む (tokenGroups)
Token-Groups - 名前の指定なし (tokenGroups)
User-Principal-Name (userPrincipalName)
SAM-Account-Name(sAMAccountName)
これ以外の ldap 属性を使用する場合には「カスタム規則」を使用
12
クレームルールを定義する例1
• エバンジェリスト属性を持ったユーザーにのみトークンを発行する• 以下の ldap 属性をクレームとして送信する
ldap 属性 クレームタイプ
氏名 displayname 名前
メール email 電子メール アドレス
部署 department 部署
役職 title 役割規定で用意されないため「要求記述」に定義する必要がある
規定で用意されないため「要求記述」に定義する必要がある
作業手順①要求記述に「役割」を追加②「発行承認規則」で「エバンジェリスト」以外を抑止③「発行変換規則」で上記 4 つのクレームを定義する
作業手順①要求記述に「役割」を追加②「発行承認規則」で「エバンジェリスト」以外を抑止③「発行変換規則」で上記 4 つのクレームを定義する
13
クレームルールを定義する
① 要求記述の定義（「部署」を追加）
クレームタイプ を URI で設定する。世界で唯一にするため、自社ドメイン名を入れるとよい。
クレームタイプ を URI で設定する。世界で唯一にするため、自社ドメイン名を入れるとよい。
14
② 「発行承認規則」（「エバンジェリスト」以外を抑止）
「すべてのユーザーにアクセスを許可」を削除
15
「 LDAP 属性を要求として送信」を選択「 LDAP 属性を要求として送信」を選択
Active Directory の属性「 title 」を 「役割」に放り込む
Active Directory の属性「 title 」を 「役割」に放り込む
16
さらに規則を追加するさらに規則を追加する
「入力方向の要求に基づいてユーザーを許可または拒否」を選択「入力方向の要求に基づいてユーザーを許可または拒否」を選択
17
クレーム「役割」が「エバンジェリスト」ならば…クレーム「役割」が「エバンジェリスト」ならば…
条件に合致したユーザーのみを「許可」条件に合致したユーザーのみを「許可」
18
要求規則 の処理プロセスについて
要求規則要求規則 11要求規則要求規則 11
要求規則要求規則 22要求規則要求規則 22
要求規則セット
Inp
ut
Cla
im S
et
Ou
tpu
t Cla
im S
et
クレーム
条件 発行
トークン
要求規則 要求規則 nn要求規則 要求規則 nn
前のルールの結果が次のルールに引き継がれる
19
③ 「発行変換規則」で 4 つのクレームを定義ldap 属性 クレームタイプ
氏名 displayname 名前
メール email 電子メール アドレス
部署 department 部署
役職 title 役割
20
LDAP 属性を要求して送信LDAP 属性を要求して送信
複数の ldap 属性を一度に定義可能複数の ldap 属性を一度に定義可能
21
完成形
22
実行結果例
役割が「エバンジェリスト」でなければアクセス拒否
役割が「エバンジェリスト」でなければアクセス拒否
23
クレームルールの定義 ありがちなミス ①
現象•「発行承認規則」で [ 入力方向の要求に基づいてユーザーを許可または拒否 ] ルールを使用し、クレーム名 [ 役職 ] に「部長」と書かれているユーザーのみに許可したいが、全てのアクセスが拒否されてしまう
原因•[ 役職 ] クレームの中身がからっぽ。「受け付け承認規則」で [ 役職 ] クレームが定義されていない場合、「発行承認規則」でいきなり [ 役職 ] クレームによる条件判定を行おうとしても、クレームの中身が空のため判定は「 NG 」となる。事前に、[ 役職 ] クレームに値を入力するルールが定義されている必要がある。
発発行行変変換換規規則則
inpu
t
outp
ut
受受けけ付付けけ変変換換規規則則
inpu
t
outp
ut
発発行行承承認認規規則則
inpu
t
outp
ut
OK/NG
ここでクレームを評価する以前に、クレームが発行されていない場合、「空」の値が入っているものとして評価されてしまう
ここでクレームを評価する以前に、クレームが発行されていない場合、「空」の値が入っているものとして評価されてしまう
24
クレームルールの定義 ありがちなミス ①
現象•ルールを変えても送信されるクレームが変わらない
原因•デスクトップ上に別のブラウザやタブが起動しており、既にクレームを取得している
こいつを閉じないと… .こいつを閉じないと… . 同じクレー
ムが表示される
同じクレームが表示さ
れる
25
クレームルールの定義 ありがちなミス③
現象•「入力方向の要求をパススルーまたはフィルター処理」ルールを使用して、「特定の電子メール フィックスの値と一致する要求値だけをパス スルーする」を定義しているが、サフィックスが一致しないユーザーに対してもクレームが発行されてしまう。
原因•クレームルールに複数のルールを定義しており、当該ルール以前に電子メールアドレスクレームを発行している場合、それを取り消すことはできない。
対処•当該ルール以前のルールから電子メールアドレスの発行ルールを削除する
上で発行してしまう
と…
上で発行してしまう
と…それ以降でフィルターすること
はできない
それ以降でフィルターすること
はできない
26
カスタムルールの定義AD FS 2.0 Deep Dive
27
カスタムルールのサンプルを見るには
28
条件部
発行部
29
カスタムルールの構造
入力方向のクレーム /属性をチェックし、すべての条件が True の場合に「発行部」が実行される。条件部が無い場合には無条件で True とみなされる。
=>True
False
発行するトークンタイプと、そこに格納する属性 /値を指定する。必須
条件部条件文 1
条件文 2&&&&
オプション
発行部
発行文
条件部
発行部
「クレームが発行されない」≠ アクセスできない※クレームを持っていないユーザーにアクセスを許可するかどうかは アプリケーションの判断
30
書式の基本 ①
=> issue ( Type = “A”, Value = “<値>” );
[Type == “A"] => issue (Type = “B”, Value = “値 ");
• 無条件でクレーム「 A 」に「値」を入れて発行する
• クレーム「 A 」が”存在する”場合、クレーム「 B 」に「値」を入れて発行する
[Type == “A” , Value ==“値 1”] => issue (Type = “B”, Value = “値 2”);
• クレーム「 A 」が「値 1 」ならば、クレーム「 B 」に「値 2 」を入れて発行する
NOT Exists([Type == “A"]) => issue (Type = “A”, Value = “値 ");
• クレーム「 A 」が”存在しない”場合、クレーム「 A 」に「値」を入れて発行する
31
書式の基本 ②
c:[Type == “A” , Value ==“値 1”] => issue (Type = “B”, Value = c.Value);
• クレーム「 A 」が「値 1 」ならば、クレーム「 B 」にも「 A 」と同じ値を入れて発行する
c1:[Type == “A” , Value ==“値 1”] && c2:[Type == “B” , Value ==“値 2”] => issue (Type = “C”, Value = c1.Value + c2.Value);
• クレーム「 A 」が「値 1 」でクレーム「 B 」が「値 2 」ならば、クレーム「 C 」には 値 1 と値 2 を結合した値を入力して発行する
&& はいくつでもつなげることができる※ || （ or ）に相当する演算子は用意されていない
c:[Type == “A” , Value ==“値 1”] => issue (claim = c );
• クレーム「 A 」が「値 1 」ならば、クレーム「 A 」を発行する。それ以外の場合にはクレーム「 A 」は発行されない
32
書式の基本 ③ ～ Active Directory からの属性取得
• Active Directory で認証されたユーザーならば、 logonCount 属性を取得してクレーム「 A 」を発行する
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = “A”, query = “;logonCount,{0}", param = c.Value);
• c• Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/
windowsaccountname“
• Issuer == "AD AUTHORITY“
• store = "Active Directory“
• query = “;logonCount,{0}“
• param = c.Value
WindowsAccountName というクレームが発行されている
WindowsAccountName というクレームが発行されている
クレームを発行したのは “ AD AUTHORITY” であるクレームを発行したのは “ AD AUTHORITY” である
条件部
条件部
発行部
発行部
”Active directory” というクレームストアから属性を取ってくる
”Active directory” というクレームストアから属性を取ってくる
持ってくる属性は「 logonCount 」で、AD を検索する条件は windowsaccountname =
{0}
持ってくる属性は「 logonCount 」で、AD を検索する条件は windowsaccountname =
{0}
{0} の値は条件部で渡された WindowsAccountName の値{0} の値は条件部で渡された WindowsAccountName の値
WindowsAccountName クレームWindowsAccountName クレーム
33
カスタムルール活用のコツ ①
c:[Type == “A”, Value =~ “^(?i)junichia@tf\.com$” ] => issue(claim = c);c:[Type == “A”, Value =~ “^(?i)junichia@tf\.com$” ] => issue(claim = c);
正規表現の利用• （例 1 ）クレーム「 A 」の値が大文字小文字を問わず「 [email protected] 」
と完全一致ならばクレームを発行する
^(?i)junichia@tf\.com$
正規表現言語要素http://msdn.microsoft.com/ja-jp/library/az24scfc.aspx
行頭（これより前に文字が無いこと）を示す
後に続く文字の大文字小文字を区別しない
特殊な文字の前には「 \（バックスラッシュ）」を付加
行末（これより後ろに文字が無いこと）を示す
34
カスタムルール活用のコツ ②
[Type == “A”, Value =~ "^[0-9]{3}$"] => issue(Type = “B”, Value = “SENIOR”);[Type == “A”, Value =~ "^[0-9]{3}$"] => issue(Type = “B”, Value = “SENIOR”);
正規表現の利用• （例 2 ）クレーム「 A 」の値が 2 ケタの数字ならば、クレーム「 B 」に
「 JUNIOR 」を入れて発行する
^[0-9]{3}$
正規表現言語要素http://msdn.microsoft.com/ja-jp/library/az24scfc.aspx
行頭（これより前に文字が無いこと）を示す
0 から 9 の文字列が 3ケタである
行末（これより後ろに文字が無いこと）を示す
35
カスタムルール活用のコツ ③
ファンクションの活用•count：指定されたクレームが持つ値の数をカウントする
•RegExReplace：文字列を置き換える
count ([type == “http://schemas.xmlsoap.org/claims/Reports“] ) > 0 => issue(= "http://schemas.xmlsoap.org/claims/ismanager", value = "true");
count ([type == “http://schemas.xmlsoap.org/claims/Reports“] ) > 0 => issue(= "http://schemas.xmlsoap.org/claims/ismanager", value = "true");
c:[type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"] => issue(type = c.type, value = regexreplace (c.value, "(?<domain>[^\\]+)\\(?<user>.+)", "FABRIKAM\${user}"));
c:[type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"] => issue(type = c.type, value = regexreplace (c.value, "(?<domain>[^\\]+)\\(?<user>.+)", "FABRIKAM\${user}"));
36
発行ステートメントについて
要求規則要求規則 11要求規則要求規則 11
要求規則要求規則 22要求規則要求規則 22
要求規則セット
Inp
ut
Cla
im S
et
Outp
ut C
laim
Set
クレーム
title = “ 部長”
role=“Manager”
• issue ：クレームを発行する（ output claim set に発行する）• add ： input claim set に直接発行する
→ クレーム発行のためのテンポラリー領域的な使い方
=> addadd (type = “title”, value = “ 部長 ");=> addadd (type = “title”, value = “ 部長 ");
[type == “title”, Value == “ 部長” ]=> issueissue (type = "Role", value = “Manager");
[type == “title”, Value == “ 部長” ]=> issueissue (type = "Role", value = “Manager");
add ステートメントは output ク
レームを発行しない
input 領域にのみ発行
input 領域にのみ発行
37
カスタムルールを定義する例2
• 役割が「エバンジェリスト」にのみトークンを発行する• ユーザーのアクティブ度（笑）をログオン回数から判定し、回数に応じた Status 与える（アプリケーション側では Status に応じて表示するメニューを変える）
• 以下のクレームを送信するldap 属性 クレームタイプ
氏名 displayname 名前
メール email 電子メール アドレス
部署 department 部署
役職 title 役割
ログオン回数 logonCount ログオン回数
ステータス ー ステータス
作業手順①要求記述に「ログオン回数」と「ステータス」を追加②「発行変換規則」で「ログオン回数」と「ステータス」を定義
作業手順①要求記述に「ログオン回数」と「ステータス」を追加②「発行変換規則」で「ログオン回数」と「ステータス」を定義
規定で用意されないため「要求記述」に定義する必要がある
規定で用意されないため「要求記述」に定義する必要がある
規定で用意されないため「要求記述」に定義する必要がある
規定で用意されないため「要求記述」に定義する必要がある
38
カスタムルールを定義する
要求記述の定義（「ログオン回数」）
クレームタイプ を URI で設定する。クレームタイプ を URI で設定する。
39
カスタムルールを定義する
要求記述の定義（「ステータス」）
クレームタイプ を URI で設定する。クレームタイプ を URI で設定する。
40
カスタムルールを定義する
「ログオン回数」と「ステータス」を定義
41
logonCount 属性を「ログオン回数」にセット
Active Directory から logonCount 属性を取り出し、クレームタイプ logoncount に入れている
Active Directory から logonCount 属性を取り出し、クレームタイプ logoncount に入れている
42
logoncount をもとにステータスを判定するには
c:[Type == “http://schemas.tf.com/identity/claims/logoncount”, Value =~ “^[0-9]{1}\”] => add (Type = "http://schemas.tf.com/identity/claims/userstatus", Value = "SILVER");c:[Type == “http://schemas.tf.com/identity/claims/logoncount”, Value =~ “^[0-9]{1}\”] => add (Type = "http://schemas.tf.com/identity/claims/userstatus", Value = "SILVER");
logonCount < 10 ならば ステータスは シルバー
c:[Type == “http://schemas.tf.com/identity/claims/logoncount”, Value =~ “^[0-9]{2}\”] => add (Type = "http://schemas.tf.com/identity/claims/userstatus", Value = “GOLD");c:[Type == “http://schemas.tf.com/identity/claims/logoncount”, Value =~ “^[0-9]{2}\”] => add (Type = "http://schemas.tf.com/identity/claims/userstatus", Value = “GOLD");
logonCount => 10 and logonCount < 100 ならば ステータスは ゴールド
c:[Type == “http://schemas.tf.com/identity/claims/logoncount”, Value =~ “^[0-9]{3}\”] => add (Type = "http://schemas.tf.com/identity/claims/userstatus", Value = “PLATINUM");c:[Type == “http://schemas.tf.com/identity/claims/logoncount”, Value =~ “^[0-9]{3}\”] => add (Type = "http://schemas.tf.com/identity/claims/userstatus", Value = “PLATINUM");
logonCount => 10 and logonCount < 100 ならば ステータスは ゴールド
=> Issue (Type = "http://schemas.tf.com/identity/claims/userstatus“ ) ; => Issue (Type = "http://schemas.tf.com/identity/claims/userstatus“ ) ;
userstatus クレームを発行する
43
完成形
ルールは上から実行される6 userstatus クレームを発行する < 要求規則の表示>
44
AD FS 2.0 DEEP DIVE
AD FS 2.0 の監査とトレース
45
トレースログを表示するには
[ イベント ビューアー ] - [ アプリケーション と サービスログ ] - [AD FS 2.0] を右クリックして [ 表示 ]-[分析およびデバッグログの表示 ] をチェック
46
トレースログを有効にする
47
まとめまとめ
48
AD FS 2.0 をうまく使うには
• ビジネスの方向性を見据えた設計を• AD FS 2.0 はオープンなアーキテクチャ• 企業間、組織間、異種プラットフォーム間の相互運用も射程内にある
• SaaS の選定も慎重に（クレームベースの認証が可能か？）
• LOB のアーキテクチャに口出ししましょう• 認証 /ロール管理を今後どうするか？• 企業全体での ID 管理の仕組みは？
• AD FS 2.0 のアーキテクチャにも注目を！• Microsoft Online Service との連携• AppFabric Access Control Service との連携• 他社テクノロジーとの連携
AD FS 2.0 は LOB のアーキテクチャを一新するテクノロジーです
AD FS 2.0 は LOB のアーキテクチャを一新するテクノロジーです
49
STS は AD FS だけじゃない
• AppFabric Access Control Service （ ACS ）との連携
STS
STS
信頼信頼信頼信頼
信頼信頼信頼信頼
トークントークン
トー
クン
トー
クン
アクセス
アクセス
ア ク セ ス
ア ク セ スAD DS AD FS
ACS
50
（参考）新しい ACS は夢が広がる
IdP/CP RP/SP
クラウド
オンプレミス
REST
WIF
AD FS 2.0
ACS V2
AD DS
REST
WIF
AD FS 2.0
51
© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
