AD FS deep dive - claim rule set

AD FS 2.0 Deep Dive
～要求規則を極める～
2012.01.21
マイクロソフト株式会社
エバンジェリスト
安納順一（あんのうじゅんいち）
http://blogs.technet.com/junichia/
twitter @junichia
1

本日の内容
• AD FS がどのようにセキュリティトークンを発
行するのかを理解しましょう
（要求規則とクレームパイプライン）
• 複雑なクレームを含んだセキュリティトークン
の発行方法を理解しましょう

2

目次

1. AD FS の基礎知識
2. クレームパイプラインとクレームルール（要求規則）
3. クレームルールを定義するには
4. クレームルールの定義例
5. クレームルールの処理プロセス
6. カスタムルール
7. カスラムルールの定義例

3

AD FS 2.0 Deep Dive

AD FS の基礎知識
さくっと理解しましょう～

4

よくあるシステムモデル
• WEB アプリにアクセスするには AD 認証が必要
• WEB アプリが独自にユーザーの情報を管理している

Active Directory ドメイン
ユーザーの
役割や属性
統合認証
役割ごとの
アクセス権
AD DS WEB DB
AD LDS アプリサーバー

ブラウザー
5

AD FS を使ったシステムモデル
• WEB アプリにアクセスするにはセキュリティトークンが必要
• DB サーバーで管理する個人情報を最小限にできる
• クライアントやWEBはドメイン参加の必要が無い（SSOしなければ）
• WEBとADの通信は発生しない（トークンはブラウザ経由で渡される）
ユーザーの
役割や属性

役割ごとの
アクセス権
AD DS AD FS WEB DB

ブラウザー
6

AD FS を使ったシステムモデル
• WEB アプリにアクセスするにはセキュリティトークンが必要
• DB サーバーで管理する個人情報を最小限にできる
• クライアントやWEBはドメイン参加の必要が無い（SSOしなければ）
• WEBとADの通信は発生しない（トークンはブラウザ経由で渡される）
ユーザーのアプリはクラウドでもOK
役割や属性

役割ごとの
アクセス権
AD DS AD FS WEB DB

ブラウザー
7

セキュリティトークン/アサーション
• パッケージ化されたクレーム
• 発行者（オーソリティ）の署名によって信頼性を担保
• 発行者とは事前に信頼関係を結んでおく

セキュリティトークン/
アサーション

8

クレームとは
• クレームストア（AD DS/LDS/SQL）から収集したユーザー
の属性
• アプリケーションの要求に応じて AD FS 側で生成ルール
を定義
• アクセス承認に使用される

9

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

AD FS 2.0 Deep Dive
クレームパイプラインと要求規則（クレームルール）

11

用語について
基本的に、日本語 UI に沿った用語を使用します。
が…ちょっとアレなところもあるので、以下の対応票を参考にしてください。

日本語対応する英語
要求 Claim, クレーム
規則 Rule, ルール
要求の種類 Claim Type, クレームタイプ
要求記述 Claim Description, クレームディスクリプション
要求プロバイダー Claims Provider, クレームプロバイダー
証明書利用者 Relying Party, リライングパーティ
発行承認規則 Issuance Authorization Rules
受付変換規則 Acceptance Transform Rules
発行変換規則 Issuance Transform Rules

12

要求規則 (Claim Rule)
• 入力された情報を処理するためのルール (規則)
• 要求規則の種類は大きく分けて3つ
– パススルー
– 変換
– フィルター

要求規則
他のプロバイ
ダースルー

AD DS
AD LDS
入力変換出力
LDAP

SQL Server フィルター
その他

13

セキュリティトークンの発行処理

AD DS/LDS
AD FS

Token
SQL Server
拡大すると

クレームプロバイダー側リライングパーティー側
① 受付ける ② 承認する ③ 発行する
受け
発行発行
付け
承認変換
変換
規則規則
規則

クレームパイプライン 14

なぜ分かれているのか？
• CP と RP が別組織である場合に対応するため

企業A 企業B
AD DS/LDS
AD FS AD FS

Token Token
SQL Server
アプリ用にトークン
別組織からのトー
を整形/変換して送出
クンを検証するする

受け
発行発行
付け
承認変換
変換
規則規則
規則

15

クレームパイプラインの詳細証明書利用者
(RP)
CP側のクレームストア RP側のクレームストア

評価
受け
発行発行
output

output
output
input
input

付け

input
承認変換トークン
変換
規則規則
規則

要求規則 (Claim Rule) 16

要求規則セット (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

クレームルール（要求規則）を定義するには

18

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

注意！既定のクレームセットを消さないこと！

もし消してしまったら以下を参照して復旧してください。
http://blogs.technet.com/b/junichia/archive/2012/01/19/3476217.aspx

21

② 承認する発行承認規則
• 「証明書利用者信頼」で設定する
• 「発行変換規則」を実行するかどうかを判断
• セキュリティトークンは発行しない

この設定では「受け付け変換規則」
を通過したユーザー全てに、「発行
変換規則」への進行を許可

22

③ 発行する発行変換規則
• 「証明書利用者信頼」で設定する
• ユーザーに発行するセキュリティトークンのルールを定義する

規定では空（何も発行しない）
ただし、「認証メソッド」と「認
証日時」だけは送信される

23

2種類の定義方法
• 要求規則テンプレートを使用
• 規定で用意されているルールを使用する場合
• [LDAP 属性を要求として送信]
• [グループメンバーシップを要求として送信]
• [入力方向の要求を変換]
• [入力方向の要求をパススルーまたはフィルター処理]
• [カスタム規則を使用して要求を送信]
• [入力方向の要求に基づいてユーザーを許可または拒否]
• [すべてのユーザーを許可]

• カスタムルールを定義
• 用意されていないルール（ロジック）を使用する場合
• 用意されていない ldap 属性を使用する場合
• AD DS/ldap 以外のクレームストアを使用する場合
• SQL Server
• その他（テキストファイルなど）

[要求記述]に記載されていないクレームタイプは使用できないので、
事前に定義しておく必要がある
24

要求記述について
• システム間で送受信するクレームタイプが定義されている
• ここに定義されていないクレームは、要求規則テンプレートで使用するこ
とができない

あくまでもADFS内の「名ワールドワイドで一意なクレームの名前このクレームを外部から受信可
前」。このSTS内部でだけ（だから URI で書かれている）。能か否か、外部に送信可能か否
通用する。これを使ってクレームが識別される。かを定義

25

クレームタイプは世界で一意
• クレームタイプとは世界共通のクレームの識別名
• プロパティ名のようなもの
• 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

（参考）既定のクレームタイプの表示名
英語表記日本語表記
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

英語表記日本語表記
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

（参考）既定の 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

要求規則（クレームルール）の定義例
1. 要求記述の定義
2. 発行承認規則の定義
3. 発行変換規則の定義
4. クレームルールの定義にありがちなミス

30


シナリオ

• 役割がエバンジェリストであるユーザーにのみ
セキュリティトークンを発行する

• セキュリティトークンには「氏名」「役職」「部
署」「メール」を含める
ldap 属性クレームタイプ

氏名 displayname 名前

メール email 電子メールアドレス

部署 department 部署規定で用意されない
役職 title 役割ため「要求記述」に
定義する必要がある

31


作業概要

① 要求記述に「部署」を追加
② 「受け付け変換規則」に4つのクレームタイプを定義
③ 「発行承認規則」で「エバンジェリスト」以外を抑止
④ 「発行変換規則」で4つのクレームを定義する



部署 department 部署

役職 title 役割

32

① 要求記述に「部署」を追加

クレームタイプを URI で設定する。
世界で唯一にするため、自社ドメイ
ン名を入れるとよい。

33

② 「受け付け変換規則」に4つのクレームを定義




役職 title 役割

34

これは消さな
い！

Active Directory から属性を
拾ってクレームに格納する

35

4つのクレームを追加

36

③「発行承認規則」で「エバンジェリスト」以外を抑止
「すべてのユーザーにアク
セスを許可」を削除

37


CP から受け取ったクレームタイプを判
定する

クレームタイプ「部署」に「エバ
ンジェリスト」が入っていれば

トークン発行を許可する

38

④「発行変換規則」で4つのクレームを定義



「証明書利用者信頼」に登録
役職 title 役割されているRP一覧

39

同様に「メール」
「部署」「役割」
についても記述す
る。

40

実行結果例

OK

NG

役割が「エバンジェリスト」
でなければアクセス拒否

42

ちなみに Windows Phone から

43

クレームルールの定義ありがちなミス ①

現象例
• 「発行承認規則」で[入力方向の要求に基づいてユーザーを許可または拒否]
ルールを使用し、クレーム名[役職] に「部長」と書かれているユーザーのみに
許可したいが、全てのアクセスが拒否されてしまう

原因
• [役職] クレームの中身がからっぽ。
「受け付け変換規則」で [役職] クレームが定義されていない場合、「発行承
認規則」でいきなり[役職]クレームによる条件判定を行おうとしても、クレー
ムの中身が空のため判定は「NG」となる。事前に、[役職]クレームに値を入力
するルールが定義されている必要がある。
ここでクレームを評価する以前に、クレーム
が発行されていない場合、「空」の値が入っ
ているものとして評価されてしまう
受け
発行発行
output

output
output
input
input

input
付け
承認変換
変換
規則 OK/ 規則
規則 NG

44

クレームルールの定義ありがちなミス ②

現象
• ルールを変えても送信されるクレームが変わらない

原因
• デスクトップ上に別のブラウザやタブが起動しており、既にクレーム
を取得している

こいつを閉
じないと…. 同じクレー
ムが表示さ
れる

45

クレームルールの定義ありがちなミス③

現象
• 「入力方向の要求をパススルーまたはフィルター処理」ルールを使用して、
「特定の電子メールサフィックスの値と一致する要求値だけをパススルーす
る」を定義しているが、サフィックスが一致しないユーザーに対してもクレー
ムが発行されてしまう。

原因
• クレームルールに複数のルールを定
義しており、当該ルール以前に電子
メールアドレスクレームを発行して
いる場合、それを取り消すことはで上で発行し
きない。てしまうと…
あとからフィル
対処ターすることは
• 当該ルール以前のルールから電子できない
メールアドレスの発行ルールを削除
する

46

クレームルールの処理プロセス

47

原則 ① 要求規則は上から処理される
上の規則の出力結果が下規則の入力となる

要求規則

48

原則 ② 前の規則の出力結果が次の規則の入力となる

クレーム
要求規則セット

要求規則1

Output Claim Set
Input Claim Set

条件発行

要求規則2

要求規則 n

トークン

49

原則 ③ 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

カスタムルール
ここを習得できれば怖いものなし！
難易度高し！

51

カスタムルールとは？
「要求規則言語」を直接記載することで、規定のルールテンプレート
では提供されていない複雑な発行処理を行うことができる

（例）
• 規定で用意されていない ldap 属性を取得したい
• 計算結果から判定したい
• 正規表現を使用して文字列を判定したい
• 出力したくないクレームがある

52

カスタムルールの定義

カスタムルールのサンプルを見るには

53

カスタムルールの定義

条件部

発行部

54

カスタムルールの構造

条件部発行部
条件文 1 True

条件文 2
=>
&& 発行文
&& False

条件部入力方向のクレーム/属性をチェックし、
オプションすべての条件が True の場合に「発行部」が実行される。

条件部が無い場合には無条件で True とみなされる。
発行部発行するトークンタイプと、
必須そこに格納する属性/値を指定する。

「クレームが発行されない」 ≠ アクセスできない
※クレームを持っていないユーザーにアクセスを許可するかどうかは
アプリケーションの判断
55

書式の基本 ①
• 無条件でクレーム「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

書式の基本 ②
• クレーム「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

書式の基本 ③ ～ 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

正規表現の利用
• （例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

正規表現の利用

• （例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

ファンクションの活用
• 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

発行ステートメントによる処理の違い
• 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

カスタムルールの定義例

63

シナリオ
• 役割が「エバンジェリスト」にのみトークンを発行する
• ユーザーのアクティブ度をログオン回数から判定し、回数に応じた Status 与
える（アプリケーション側では Status に応じて表示するメニューを変える）
• 以下のクレームを送信する




規定で用意されない
役職 title 役割ため「要求記述」に
ログオン回数 logonCount ログオン回数定義する必要がある
ステータスーステータス

作業手順
① 要求記述に「ログオン回数」と「ステータス」を追加
② 「発行変換規則」で「ログオン回数」と「ステータス」を定義

64

要求記述に「ログオン回数」を定義

クレームタイプを URI で設定す
る。

65

要求記述に「ステータス」を定義

クレームタイプを URI で設定す
る。

66

カスタムルールに「ログオン回数」と「ステータス」を定義

67

AD の logonCount 属性を「ログオン回数」にセット

Active Directory から logonCount
属性を取り出し、クレームタイプ
logoncount に入れている

68

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 ならばステータスはゴールド

=> add (Type = "http://schemas.tf.com/identity/claims/userstatus", Value = “GOLD");

logonCount => 10 and logonCount < 100 ならばステータスはゴールド

=> add (Type = "http://schemas.tf.com/identity/claims/userstatus", Value = “PLATINUM");

userstatus クレームを発行する

=> Issue (Type = "http://schemas.tf.com/identity/claims/userstatus“ ) ;
69

完成形

6 userstatusクレームを発行する <要求規則の表
示>

70

まとめ
ちゃんとし
た
• Active Directory を構築しましょう
• ユーザーアカウントの一元管理
• ユーザーロールの一元管理
• アカウントの有効期限
• パスワードの複雑性

• 認可の管理は IT Pro の腕にかかっています
• AD FS を習得しましょう
• クレームルールはビジネスロジックです
• アプリケーションの対応も同時に進めましょう

72

AD FS deep dive - claim rule set

More Related Content

What's hot (20)

Similar to AD FS deep dive - claim rule set (20)

More from junichi anno (20)

AD FS deep dive - claim rule set