More Related Content Similar to AD FS deep dive - claim rule set Similar to AD FS deep dive - claim rule set (20) More from junichi anno (20) 1. AD FS 2.0 Deep Dive
～ 要求規則を極める ～
2012.01.21
マイクロソフト株式会社
エバンジェリスト
安納 順一（あんのう じゅんいち）
http://blogs.technet.com/junichia/
twitter @junichia
1
2. 本日の内容
• AD FS がどのようにセキュリティトークンを発
行するのかを理解しましょう
（要求規則とクレームパイプライン）
• 複雑なクレームを含んだセキュリティトークン
の発行方法を理解しましょう
2
3. 目次
1. AD FS の基礎知識
2. クレームパイプラインとクレームルール（要求規則）
3. クレームルールを定義するには
4. クレームルールの定義 例
5. クレームルールの処理プロセス
6. カスタムルール
7. カスラムルールの定義 例
3
4. AD FS 2.0 Deep Dive
AD FS の基礎知識
さくっと理解しましょう～
4
5. よくあるシステムモデル
• WEB アプリにアクセスするには AD 認証が必要
• WEB アプリが独自にユーザーの情報を管理している
Active Directory ドメイン
ユーザーの
役割や属性
統合認証
役割ごとの
アクセス権
AD DS WEB DB
AD LDS アプリ サーバー
ブラウザー
5
6. AD FS を使ったシステムモデル
• WEB アプリにアクセスするにはセキュリティトークンが必要
• DB サーバーで管理する個人情報を最小限にできる
• クライアントやWEBはドメイン参加の必要が無い（SSOしなければ）
• WEBとADの通信は発生しない（トークンはブラウザ経由で渡される）
ユーザーの
役割や属性
役割ごとの
アクセス権
AD DS AD FS WEB DB
AD LDS アプリ サーバー
ブラウザー
6
7. AD FS を使ったシステムモデル
• WEB アプリにアクセスするにはセキュリティトークンが必要
• DB サーバーで管理する個人情報を最小限にできる
• クライアントやWEBはドメイン参加の必要が無い（SSOしなければ）
• WEBとADの通信は発生しない（トークンはブラウザ経由で渡される）
ユーザーの アプリはクラウドでもOK
役割や属性
役割ごとの
アクセス権
AD DS AD FS WEB DB
AD LDS アプリ サーバー
ブラウザー
7
9. クレーム とは
• クレームストア（AD DS/LDS/SQL）から収集したユーザー
の属性
• アプリケーションの要求に応じて AD FS 側で生成ルール
を定義
• アクセス承認に使用される
9
10. AD FS の役割
• AD DS/AD LDS で認証されたユーザーに対して、セキュリティ
トークンを発行する（SAML 1.1, SAML 2.0）
• セキュリティトークンの発行ルールを集中管理する
• セキュリティトークンのソースとなるストアは以下の通り
• AD DS
• AD LDS
• SQL Server
※クラスライブラリを作成して独自のストアを定義可能
AD DS/LDS
AD FS
Token
SQL Server
10
11. AD FS 2.0 Deep Dive
クレームパイプラインと要求規則（クレームルール）
11
12. 用語について
基本的に、日本語 UI に沿った用語を使用します。
が…ちょっとアレなところもあるので、以下の対応票を参考にしてください。
日本語 対応する英語
要求 Claim, クレーム
規則 Rule, ルール
要求の種類 Claim Type, クレームタイプ
要求記述 Claim Description, クレームディスクリプション
要求 プロバイダー Claims Provider, クレーム プロバイダー
証明書利用者 Relying Party, リライング パーティ
発行承認規則 Issuance Authorization Rules
受付変換規則 Acceptance Transform Rules
発行変換規則 Issuance Transform Rules
12
13. 要求規則 (Claim Rule)
• 入力された情報を処理するためのルール (規則)
• 要求規則の種類は大きく分けて3つ
– パススルー
– 変換
– フィルター
要求規則
他のプロバイ
ダー スルー
AD DS
AD LDS
入力 変換 出力
LDAP
SQL Server フィルター
その他
13
14. セキュリティトークンの発行処理
AD DS/LDS
AD FS
Token
SQL Server
拡大すると
クレームプロバイダー側 リライングパーティー側
① 受付ける ② 承認する ③ 発行する
受け
発行 発行
付け
承認 変換
変換
規則 規則
規則
クレームパイプライン 14
15. なぜ分かれているのか？
• CP と RP が別組織である場合に対応するため
企業A 企業B
AD DS/LDS
AD FS AD FS
Token Token
SQL Server
アプリ用にトークン
別組織からのトー
を整形/変換して送出
クンを検証する する
クレームプロバイダー側 リライングパーティー側
① 受付ける ② 承認する ③ 発行する
受け
発行 発行
付け
承認 変換
変換
規則 規則
規則
15
16. クレーム パイプラインの詳細 証明書利用者
(RP)
CP側のクレームストア RP側のクレームストア
① 受付ける ② 承認する ③ 発行する
評価
受け
発行 発行
output
output
output
input
input
付け
input
承認 変換 トークン
変換
規則 規則
規則
クレームプロバイダー側 リライングパーティー側
要求規則 (Claim Rule) 16
17. 要求規則セット (Claim Rule Set) のタイプ
覚えなくていいです！
• 受け付け変換規則 - Acceptance Transform Rule Set
要求プロバイダー ー (AD DS, SQL Server, LDAP) から
クレームを収集しセキュリティトークンを生成
• 発行承認規則 - Issuance Authorization Rule Set
証明書利用者 (RP) にアクセス可能なユーザーを評価にするための
ルール。ここでは評価するためのルールを定義する。出力されるのは
トークン発行OK/NG のみで、ここで定義したクレームは発行されない。
• 発行変換規則 - Issuance Transform Rule Set
「受け付け要求規則」から発行されたクレーム セットを入力とし、
証明書利用者 (RP) に発行するクレームを生成する
• 委任承認規則 - Delegation Authorization Rule Set
他のユーザーの代理として証明書利用者 (RP) にアクセスできるかどう
かを判断するためのルール
• 偽装承認規則 - Impersonate Authorization Rule Set
ユーザーが他のユーザーを偽装してアクセスできるかどうかを
判断するためのルール。Windows PowerShell で実装する。
17
19. AD FS 2.0 管理コンソールの基礎
この AD FS 2.0（STS）で扱うことができるクレーム
が定義されている。逆に言えばここに定義されてい
ないクレームを使うことはできない。先方から要求
されているクレームは個々に定義する。
「要求プロバイダー」とは「IdP/CP」のこと。自分
が RP/SP 側の STS である場合には、ここに IdP/CP
となるサーバーを定義する。既定では自身が所属し
ている Active Directory ドメインが定義されてい
る（「要求プロバイダーであること」が規定値と
なっている）。
「証明書利用者」とは「RP/SP」のこと。自分が
IdP/CP 側の STS である場合には、ここに RP/SP を
定義することで信頼関係を構築できる。既定では何
も定義されていない。
クレームのもととなる属性情報の格納庫を定義する。
既定では、所属している Active Directory が定義
されている。
19
20. ① 受付ける 受け付け変換規則
• 「要求プロバイダー信頼」で設定する
• 「証明書利用者信頼」に渡すためのクレームをセットする
大原則
ここで定義されたクレームのみが、
パイプラインに沿って「証明書利
用信頼」に渡される
20
22. ② 承認する 発行承認規則
• 「証明書利用者信頼」で設定する
• 「発行変換規則」を実行するかどうかを判断
• セキュリティトークンは発行しない
この設定では「受け付け変換規則」
を通過したユーザー全てに、「発行
変換規則」への進行を許可
22
23. ③ 発行する 発行変換規則
• 「証明書利用者信頼」で設定する
• ユーザーに発行するセキュリティトークンのルールを定義する
規定では空（何も発行しない）
ただし、「認証メソッド」と「認
証日時」だけは送信される
23
24. 2種類の定義方法
• 要求規則テンプレートを使用
• 規定で用意されているルールを使用する場合
• [LDAP 属性を要求として送信]
• [グループ メンバーシップを要求として送信]
• [入力方向の要求を変換]
• [入力方向の要求をパススルーまたはフィルター処理]
• [カスタム規則を使用して要求を送信]
• [入力方向の要求に基づいてユーザーを許可または拒否]
• [すべてのユーザーを許可]
• カスタムルールを定義
• 用意されていないルール（ロジック）を使用する場合
• 用意されていない ldap 属性を使用する場合
• AD DS/ldap 以外のクレームストアを使用する場合
• SQL Server
• その他（テキストファイル など）
[要求記述]に記載されていないクレームタイプは使用できないので、
事前に定義しておく必要がある
24
25. 要求記述について
• システム間で送受信するクレームタイプが定義されている
• ここに定義されていないクレームは、要求規則テンプレートで使用するこ
とができない
あくまでもADFS内の「名 ワールドワイドで一意なクレームの名前 このクレームを外部から受信可
前」。このSTS内部でだけ （だから URI で書かれている）。 能か否か、外部に送信可能か否
通用する。 これを使ってクレームが識別される。 かを定義
25
26. クレームタイプは世界で一意
• クレームタイプとは世界共通のクレームの識別名
• プロパティ名のようなもの
• URI 形式で示す
• どのようなクレームタイプを使用するかは両者で事前にネゴが必要
• 通常はRP側が定義し、メタデータとして提示する
• “適当な命名規約”や”クレームタイプの流用”は後々混乱の元！
企業A 企業B
AD DS/LDS
AD FS AD FS
Token Token
SQL Server
同じクレームタイプを使用しない
と評価のしようがない！
http://schemas.tf.com/claims/companyname = マイクロソフ
ト
http://schemas.tf.com/claims/age = 43
http://schemas.tf.com/claims/kanaName = あんのう
26
27. （参考）既定のクレーム タイプの表示名
英語表記 日本語表記
E-Mail Address 電子メール アドレス
Given Name 指定名
Name 名前
UPN UPN
Common Name 共通名
AD FS 1.x E-Mail Address AD FS 1.x 電子メール アドレス
Group グループ
AD FS 1.x UPN AD FS 1.x UPN
Role 役割
Surname 姓
PPID PPID
Name Identifier 名前 ID
Authentication Method 認証方法
27
28. 英語表記 日本語表記
Deny Only Group SID 拒否のみグループ SID
Deny only primary SID 拒否のみプライマリ SID
Deny only primary group SID 拒否のみプライマリ グループ SID
Group SID グループ SID
Primary Group SID プライマリ グループ SID
Primary SID プライマリ SID
Windows account name Windows カウント名
Authentication Instant 認証タイム スタンプ
28
29. （参考）既定の LDAP 属性
これ以外の ldap 属性を使用する場合には「カスタム規則」を使用
LDAP 属性の名前（lDAPdisplayName) LDAP 属性の名前（lDAPdisplayName)
Company (company) State-Or-Province-Name (st)
Department (department) Street-Address (street)
Display-Name (displayName) Surname (sn)
E-Mail-Address (mail) Telephone-Number (telephoneNumber)
Employee-ID (employeeID) Title (title)
Employee-Number (employeeNumber) Token-Groups (SID) (tokenGroups)
Employee-Type (employeeType) Token-Groups - ドメイン名を含む
(tokenGroups)
Given-Name (givenName)
Token-Groups - 完全修飾ドメイン名を含
Is-Member-Of-DL (memberOf) む(tokenGroups)
Organizational-Unit-Name (ou) Token-Groups - 名前の指定なし
Organization-Name (o) (tokenGroups)
User-Principal-Name
Proxy-Addresses (proxyAddress)
(userPrincipalName)
SAM-Account-Name(sAMAccountName)
29
31. 要求規則（クレームルール）の定義 例
シナリオ
• 役割がエバンジェリストであるユーザーにのみ
セキュリティトークンを発行する
• セキュリティトークンには「氏名」「役職」「部
署」「メール」を含める
ldap 属性 クレームタイプ
氏名 displayname 名前
メール email 電子メール アドレス
部署 department 部署 規定で用意されない
役職 title 役割 ため「要求記述」に
定義する必要がある
31
32. 要求規則（クレームルール）の定義 例
作業概要
① 要求記述に「部署」を追加
② 「受け付け変換規則」に4つのクレームタイプを定義
③ 「発行承認規則」で「エバンジェリスト」以外を抑止
④ 「発行変換規則」で4つのクレームを定義する
ldap 属性 クレームタイプ
氏名 displayname 名前
メール email 電子メール アドレス
部署 department 部署
役職 title 役割
32
33. ① 要求記述に「部署」を追加
クレームタイプ を URI で設定する。
世界で唯一にするため、自社ドメイ
ン名を入れるとよい。
33
35. これは消さな
い！
Active Directory から属性を
拾ってクレームに格納する
35
38. 要求規則（クレームルール）の定義 例
CP から受け取ったクレームタイプを判
定する
クレームタイプ「部署」に「エバ
ンジェリスト」が入っていれば
トークン発行を許可する
38
39. ④「発行変換規則」で4つのクレームを定義
ldap 属性 クレームタイプ
氏名 displayname 名前
メール email 電子メール アドレス
部署 department 部署
「証明書利用者信頼」に登録
役職 title 役割 されているRP一覧
39
42. 実行結果例
OK
NG
役割が「エバンジェリスト」
でなければアクセス拒否
42
44. クレームルールの定義 ありがちなミス ①
現象例
• 「発行承認規則」で[入力方向の要求に基づいてユーザーを許可または拒否]
ルールを使用し、クレーム名[役職] に「部長」と書かれているユーザーのみに
許可したいが、全てのアクセスが拒否されてしまう
原因
• [役職] クレームの中身がからっぽ。
「受け付け変換規則」で [役職] クレームが定義されていない場合、「発行承
認規則」でいきなり[役職]クレームによる条件判定を行おうとしても、クレー
ムの中身が空のため判定は「NG」となる。事前に、[役職]クレームに値を入力
するルールが定義されている必要がある。
ここでクレームを評価する以前に、クレーム
が発行されていない場合、「空」の値が入っ
ているものとして評価されてしまう
受け
発行 発行
output
output
output
input
input
input
付け
承認 変換
変換
規則 OK/ 規則
規則 NG
44
45. クレームルールの定義 ありがちなミス ②
現象
• ルールを変えても送信されるクレームが変わらない
原因
• デスクトップ上に別のブラウザやタブが起動しており、既にクレーム
を取得している
こいつを閉
じないと…. 同じクレー
ムが表示さ
れる
45
46. クレームルールの定義 ありがちなミス③
現象
• 「入力方向の要求をパススルーまたはフィルター処理」ルールを使用して、
「特定の電子メール サフィックスの値と一致する要求値だけをパス スルーす
る」を定義しているが、サフィックスが一致しないユーザーに対してもクレー
ムが発行されてしまう。
原因
• クレームルールに複数のルールを定
義しており、当該ルール以前に電子
メールアドレスクレームを発行して
いる場合、それを取り消すことはで 上で発行し
きない。 てしまうと…
あとからフィル
対処 ターすることは
• 当該ルール以前のルールから電子 できない
メールアドレスの発行ルールを削除
する
46
50. 原則 ③ Output Claim Set に蓄積されたデータがセキュリティ
トークンとなる 超重要
一度 Output Claim Set に出力されたクレームは削除できない
※発行ステートメント（issue/add）によって調整する
要求規則セット
Output Claim Set
要求規則1
Input Claim Set
title =
=> issue (type = “title”, value = “部長"); “部長”
要求規則2
title = role=“M
[type == “title”, Value == “部長”] anager”
“部長”
=> issue (type = "Role", value = “Manager");
カスタムルールを覚えましょう！ title
role 50
55. カスタムルールの構造
条件部 発行部
条件文 1 True
条件文 2
=>
&& 発行文
&& False
条件部 入力方向のクレーム/属性をチェックし、
オプション すべての条件が True の場合に「発行部」が実行される。
条件部が無い場合には無条件で True とみなされる。
発行部 発行するトークンタイプと、
必須 そこに格納する属性/値を指定する。
「クレームが発行されない」 ≠ アクセスできない
※クレームを持っていないユーザーにアクセスを許可するかどうかは
アプリケーションの判断
55
56. 書式の基本 ①
• 無条件でクレーム「A」に「値」を入れて発行する
=> issue ( Type = “A”, Value = “<値>” );
• クレーム「A」が”存在する”場合、クレーム「B」に「値」を入れて発行する
[Type == “A"]
=> issue (Type = “B”, Value = “値");
• クレーム「A」が”存在しない”場合、クレーム「A」に「値」を入れて発行す
る
NOT Exists([Type == “A"])
=> issue (Type = “A”, Value = “値");
• クレーム「A」が「値1」ならば、クレーム「B」に「値2」を入れて発行する
[Type == “A” , Value ==“値1”]
=> issue (Type = “B”, Value = “値2”);
56
57. 書式の基本 ②
• クレーム「A」が「値1」ならば、クレーム「A」を発行する。それ以外の場合
にはクレーム「A」は発行されない
c:[Type == “A” , Value ==“値1”]
=> issue (claim = c );
• クレーム「A」が「値1」ならば、クレーム「B」にも「A」と同じ値を入れて発
行する
c:[Type == “A” , Value ==“値1”]
=> issue (Type = “B”, Value = c.Value);
• クレーム「A」が「値1」でクレーム「B」が「値2」ならば、クレーム「C」に
は 値1と値2を結合した値を入力して発行する
c1:[Type == “A” , Value ==“値1”] &&
c2:[Type == “B” , Value ==“値2”]
=> issue (Type = “C”, Value = c1.Value + c2.Value);
&& はいくつでもつなげることができる
※ ||（or）に相当する演算子は用意されていない
57
58. 書式の基本 ③ ～ 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);
WindowsAccountName クレーム
• c
条 • Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/
件 windowsaccountname“ WindowsAccountNameというクレームが発行されている
部
クレームを発行したのは “AD AUTHORITY” である
• Issuer == "AD AUTHORITY“
”Active directory”というクレームストア
• store = "Active Directory“ から
発 属性を取ってくる
行 • query = “;logonCount,{0}“ 持ってくる属性は「logonCount」で、
ADを検索する条件は windowsaccountname = {0}
部
{0} の値は条件部で渡された
• param = c.Value WindowsAccountName の値
58
59. 正規表現の利用
• （例1）クレーム「A」の値が大文字小文字を問わず
「junichia@tf.com」と完全一致ならばクレームを発行する
c:[Type == “A”, Value =~ “^(?i)junichia@tf.com$” ]
=> issue(claim = c);
^(?i)junichia@tf.com$
行末（これより後
後に続く文字の大文字 ろに文字が無いこ
小文字を区別しない と）を示す
行頭（これ
より前に文 特殊な文字の前には
字が無いこ 「（バックスラッ
と）を示す シュ）」を付加
正規表現言語要素
http://msdn.microsoft.com/ja-jp/library/az24scfc.aspx
59
60. 正規表現の利用
• （例2）クレーム「A」の値が 3 ケタの数字ならば、クレーム「B」に
「SENIOR」を入れて発行する
[Type == “A”, Value =~ "^[0-9]{3}$"]
=> issue(Type = “B”, Value = “SENIOR”);
^[0-9]{3}$
行頭（これ
より前に文 0から9の文字 行末（これより後
字が無いこ 列が3ケタで ろに文字が無いこ
ある と）を示す
と）を示す
正規表現言語要素
http://msdn.microsoft.com/ja-jp/library/az24scfc.aspx
60
61. ファンクションの活用
• count：指定されたクレームが持つ値の数をカウントする
count ([type == “http://schemas.xmlsoap.org/claims/Reports“] ) > 0
=> issue(= "http://schemas.xmlsoap.org/claims/ismanager", value =
"true");
• RegExReplace：文字列を置き換える
c:[type ==
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"]
=> issue(type = c.type,
value = regexreplace (c.value, "(?<domain>[^]+)(?<user>.+)",
"FABRIKAM${user}"));
61
62. 発行ステートメントによる処理の違い
• issue ：クレームを発行する（output claim set に発行する）
• add ：input claim set に直接発行する
→ クレーム発行のためのテンポラリー領域的な使い方
add ステートメント
クレーム
は output クレーム
要求規則セット を発行しない
要求規則1
=> add (type = “title”, value = “部長");
Output Claim Set
Input Claim Set
要求規則2
title = [type == “title”, Value == “部長”] role=“M
“部長” anager”
=> issue (type = "Role", value = “Manager");
62
64. シナリオ
• 役割が「エバンジェリスト」にのみトークンを発行する
• ユーザーのアクティブ度をログオン回数から判定し、回数に応じた Status 与
える（アプリケーション側では Status に応じて表示するメニューを変える）
• 以下のクレームを送信する
ldap 属性 クレームタイプ
氏名 displayname 名前
メール email 電子メール アドレス
部署 department 部署
規定で用意されない
役職 title 役割 ため「要求記述」に
ログオン回数 logonCount ログオン回数 定義する必要がある
ステータス ー ステータス
作業手順
① 要求記述に「ログオン回数」と「ステータス」を追加
② 「発行変換規則」で「ログオン回数」と「ステータス」を定義
64
68. AD の logonCount 属性を「ログオン回数」にセット
Active Directory から logonCount
属性を取り出し、クレームタイプ
logoncount に入れている
68
69. logoncount をもとにステータスを判定するには
logonCount < 10 ならば ステータスは シルバー
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 and logonCount < 100 ならば ステータスは ゴールド
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");
userstatus クレームを発行する
=> Issue (Type = "http://schemas.tf.com/identity/claims/userstatus“ ) ;
69
70. 完成形
6 userstatusクレームを発行する <要求規則の表
示>
70
72. まとめ
ちゃんとし
た
• Active Directory を構築しましょう
• ユーザーアカウントの一元管理
• ユーザーロールの一元管理
• アカウントの有効期限
• パスワードの複雑性
• 認可の管理は IT Pro の腕にかかっています
• AD FS を習得しましょう
• クレームルールはビジネスロジックです
• アプリケーションの対応も同時に進めましょう
72
