AD FS deep dive - claim rule set

1

AD FS 2.0 Deep Dive～要求規則を極める～

マイクロソフト株式会社エバンジェリスト

安納順一（あんのうじゅんいち）http://blogs.technet.com/junichia/

twitter @junichia

2012.01.21

2

本日の内容• AD FS がどのようにセキュリティトークンを

発行するのかを理解しましょう（要求規則とクレームパイプライン）

• 複雑なクレームを含んだセキュリティトークンの発行方法を理解しましょう

面倒な話ばかりするから覚悟なさい！あ、あと終わらないかも ...

3

目次

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

4

AD FS の基礎知識AD FS 2.0 Deep Dive

さくっと理解しましょう～

5

よくあるシステムモデル

AD DSAD LDS

WEB アプリ

DBサーバー

ブラウザー

① 認

証

②利

用

ユーザーの役割や属性

Active Directory ドメイン

• WEB アプリにアクセスするには AD 認証が必要• WEB アプリが独自にユーザーの情報を管理している

役割ごとのアクセス権

統合認証

6

AD FS を使ったシステムモデル

AD DSAD LDS

WEB アプリ

DBサーバー

ブラウザー

① 認証


• WEB アプリにアクセスするにはセキュリティトークンが必要• DB サーバーで管理する個人情報を最小限にできる• クライアントや WEB はドメイン参加の必要が無い（ SSO しなけれ

ば）• WEB と AD の通信は発生しない（トークンはブラウザ経由で渡され

る）

AD FS

②ト

ーク

ン

③トー

クン


7

AD FS を使ったシステムモデル

AD DSAD LDS

WEB アプリ

DBサーバー

ブラウザー

① 認証


• WEB アプリにアクセスするにはセキュリティトークンが必要• DB サーバーで管理する個人情報を最小限にできる• クライアントや WEB はドメイン参加の必要が無い（ SSO しなけれ

ば）• WEB と AD の通信は発生しない（トークンはブラウザ経由で渡され

る）

AD FS

②ト

ーク

ン

③トー

クン


アプリはクラウドでも OK

8

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

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

クレーム 1

クレーム 2

クレーム n

署名

発行元による署名

9

クレームとは

• クレームストア（ AD DS/LDS/SQL ）から収集したユーザーの属性

• アプリケーションの要求に応じて AD FS 側で生成ルールを定義

• アクセス承認に使用される

ユーザー ID

資格情報（認証結果）

メールアドレス

役職

氏名、姓、名

所属部門

性別

住所

趣味 / 趣向

所属企業

言語

専門分野

会員番号

10

AD FS の役割

• AD DS/AD LDS で認証されたユーザーに対して、セキュリティトークンを発行する（ SAML 1.1, SAML 2.0 ）

• セキュリティトークンの発行ルールを集中管理する

• セキュリティトークンのソースとなるストアは以下の通り• AD DS• AD LDS• SQL Server※ クラスライブラリを作成して独自のストアを定義可能

AD FS

Token

AD DS/LDS

SQL Server

11

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

12

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

日本語対応する英語

要求 Claim, クレーム

規則 Rule, ルール

要求の種類 Claim Type, クレームタイプ

要求記述 Claim Description, クレームディスクリプション

要求プロバイダー Claims Provider, クレームプロバイダー

証明書利用者 Relying Party, リライングパーティ

発行承認規則 Issuance Authorization Rules

受付変換規則 Acceptance Transform Rules

発行変換規則 Issuance Transform Rules

13

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

– パススルー– 変換– フィルター

入力

他のプロバイダースルー

変換

フィルター

AD DSAD LDS

LDAP

出力

SQL Serverその他

要求規則

14

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

AD FS

Token

AD DS/LDS

SQL Server

拡大すると

① 受付ける ③ 発行する② 承認する

クレームプロバイダー側リライングパーティー側

発行変換規則

受け付け変換規則

発行承認規則

クレームパイプライン

15

なぜ分かれているのか？

AD FS

Token

AD DS/LDS

SQL Server

① 受付ける ③ 発行する② 承認する

クレームプロバイダー側

発行変換規則


発行承認規則

AD FS

Token

企業A

企業 B

リライングパーティー側

別組織からのトークンを検証する

アプリ用にトークンを整形 / 変換して送出する

• CP と RP が別組織である場合に対応するため

16

クレームパイプラインの詳細

クレームプロバイダー側リライングパーティー側

証明書利用者(RP)

発行変換規則

inp

ut

ou

tpu

t


inp

ut 発行

承認規則

inp

ut

ou

tpu

tCP 側のクレームストア

トークン

要求規則 (Claim Rule)

② 承認する

RP 側のクレームストア

③ 発行する① 受付ける

評価 ou

tpu

t

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 で実装する。

覚えなくていいです！

18

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

19

AD FS 2.0 管理コンソールの基礎

クレームのもととなる属性情報の格納庫を定義する。既定では、所属している　 Active Directory が定義されている。

「証明書利用者」とは「 RP/SP」のこと。自分がIdP/CP 側の STS である場合には、ここに RP/SP を定義することで信頼関係を構築できる。既定では何も定義されていない。

「要求プロバイダー」とは「 IdP/CP」のこと。自分が RP/SP 側の STS である場合には、ここに IdP/CP となるサーバーを定義する。既定では自身が所属している Active Directory ドメインが定義されている（「要求プロバイダーであること」が規定値となっている）。

この AD FS 2.0 （ STS ）で扱うことができるクレームが定義されている。逆に言えばここに定義されていないクレームを使うことはできない。先方から要求されているクレームは個々に定義する。

20

受け付け変換規則• 「要求プロバイダー信頼」で設定する• 「証明書利用者信頼」に渡すためのクレームをセットする

大原則ここで定義されたクレームのみが、パイプラインに沿って「証明書利用信頼」に渡される

① 受付ける

21

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

もし消してしまったら以下を参照して復旧してください。

http://blogs.technet.com/b/junichia/archive/2012/01/19/3476217.aspx

22

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

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

② 承認する

23

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

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

③ 発行する

24

2 種類の定義方法• 要求規則テンプレートを使用

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

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

• SQL Server• その他（テキストファイルなど）

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

25

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

ことができない

あくまでも ADFS 内の「名前」。この STS 内部でだけ通用する。

ワールドワイドで一意なクレームの名前（だから URI で書かれている）。

これを使ってクレームが識別される。

このクレームを外部から受信可能か否か、外部に送信可能か否かを定義

26

クレームタイプは世界で一意

AD FS

Token

AD DS/LDS

SQL Server

AD FS

Token

企業A

企業 B

http://schemas.tf.com/claims/companyname = マイクロソフト

http://schemas.tf.com/claims/age = 43

http://schemas.tf.com/claims/kanaName = あんのう

• クレームタイプとは世界共通のクレームの識別名• プロパティ名のようなもの• URI 形式で示す

• どのようなクレームタイプを使用するかは両者で事前にネゴが必要• 通常は RP 側が定義し、メタデータとして提示する

• “ 適当な命名規約”や”クレームタイプの流用”は後々混乱の元！

同じクレームタイプを使用しないと評価のしようがない！

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 認証方法

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 認証タイムスタンプ

29

（参考）既定の 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 属性を使用する場合には「カスタム規則」を使用

30

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

31

シナリオ

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

• セキュリティトークンには「氏名」「役職」「部署」「メール」を含める

ldap 属性クレームタイプ

氏名 displayname 名前

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

部署 department 部署

役職 title 役割

規定で用意されないため「要求記述」に定義する必要がある

要求規則（クレームルール）の定義例

32

作業概要

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






役職 title 役割

33

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

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

34

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





役職 title 役割

35

これは消さない！

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

36

4 つのクレームを追加

37

③「発行承認規則」で「エバンジェリスト」以外を抑止

「すべてのユーザーにアクセスを許可」を削除

38

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


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

トークン発行を許可する

39

④「発行変換規則」で 4 つのクレームを定義ldap 属性クレームタイプ




役職 title 役割「証明書利用者信頼」に登録

されている RP 一覧

40

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

る。

42

実行結果例

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

OK

NG

43

ちなみに Windows Phone から

44

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

現象例• 「発行承認規則」で [ 入力方向の要求に基づいてユーザーを許可または拒否 ]

ルールを使用し、クレーム名 [ 役職 ] に「部長」と書かれているユーザーのみに許可したいが、全てのアクセスが拒否されてしまう

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

発行変換規則

inpu

t

outp

ut


inpu

t

outp

ut

発行承認規則

inpu

t

outp

ut

OK/NG

ここでクレームを評価する以前に、クレームが発行されていない場合、「空」の値が入っているものとして評価されてしまう

45

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

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

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

ムを取得している

こいつを閉じないと… . 同じクレー

ムが表示される

46

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

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

原因• クレームルールに複数のルールを定

義しており、当該ルール以前に電子メールアドレスクレームを発行している場合、それを取り消すことはできない。

対処• 当該ルール以前のルールから電子

メールアドレスの発行ルールを削除する

上で発行してしまうと…

あとからフィルターすることは

できない

47

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

48

原則 ① 要求規則は上から処理される

上の規則の出力結果が下規則の入力となる

要求規則

49

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

要求規則 1

要求規則 2

要求規則セットIn

pu

t C

laim

Set

Outp

ut C

laim

Set

クレーム

条件発行

トークン

要求規則 n

50

原則 ③ Output Claim Set に蓄積されたデータがセキュリティトークンとなる

要求規則 1

要求規則 2

要求規則セット

Inp

ut

Cla

im S

et

Ou

tpu

t Cla

im S

et

title = “ 部長”


role=“Manager”

=> issue (type = “title”, value = “ 部長 ");

[type == “title”, Value == “ 部長” ]=> issue (type = "Role", value = “Manager");

titlerole

一度 Output Claim Set に出力されたクレームは削除できない※ 発行ステートメント（ issue/add ）によって調整する

超重要

カスタムルールを覚えましょう！

51

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

52

カスタムルールとは？

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

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

53

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

54

条件部

発行部

カスタムルールの定義

55

カスタムルールの構造

入力方向のクレーム / 属性をチェックし、すべての条件が True の場合に「発行部」が実行される。条件部が無い場合には無条件で True とみなされる。

=>True

False

発行するトークンタイプと、そこに格納する属性 /値を指定する。必須

条件部条件文 1

条件文 2&&

&&

オプション

発行部

発行文

条件部

発行部

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

56

書式の基本 ①

=> 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」に「値」を入れて発行する

57

書式の基本 ②

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」は発行されない

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);

• 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 というクレームが発行されている

クレームを発行したのは “ AD AUTHORITY” である

条件部

発行部

”Active directory” というクレームストアから属性を取ってくる

持ってくる属性は「 logonCount」で、AD を検索する条件は windowsaccountname = {0}

{0} の値は条件部で渡された WindowsAccountName の値

WindowsAccountName クレーム

59

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

行頭（これより前に文字が無いこと）を示す

後に続く文字の大文字小文字を区別しない

特殊な文字の前には「 \ （バックスラッシュ）」を付加

行末（これより後ろに文字が無いこと）を示す

正規表現の利用

60

正規表現の利用

[Type == “A”, Value =~ "^[0-9]{3}$"] => issue(Type = “B”, Value = “SENIOR”);

• （例 2 ）クレーム「 A」の値が 3 ケタの数字ならば、クレーム「 B」に「 SENIOR」を入れて発行する

^[0-9]{3}$

正規表現言語要素http://msdn.microsoft.com/ja-jp/library/az24scfc.aspx

行頭（これより前に文字が無いこと）を示す

0 から 9 の文字列が 3 ケタである

行末（これより後ろに文字が無いこと）を示す

61

ファンクションの活用

• count：指定されたクレームが持つ値の数をカウントする

• RegExReplace：文字列を置き換える

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}"));

62

発行ステートメントによる処理の違い

要求規則 1

要求規則 2

要求規則セット

Inp

ut

Cla

im S

et

Outp

ut C

laim

Set

クレーム


role=“Manager”

• issue ：クレームを発行する（ output claim set に発行する）• add ： input claim set に直接発行する

→ クレーム発行のためのテンポラリー領域的な使い方

=> add (type = “title”, value = “ 部長 ");

[type == “title”, Value == “ 部長” ]=> issue (type = "Role", value = “Manager");

add ステートメントは output ク

レームを発行しない

input 領域にのみ発行

63

カスタムルールの定義例

64

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

• 以下のクレームを送信するldap 属性クレームタイプ




役職 title 役割

ログオン回数 logonCount ログオン回数

ステータスーステータス

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



65

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

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

66

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

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

67

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

68

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

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

69

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");

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");

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");

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

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

userstatus クレームを発行する

70

完成形

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

71

まとめ

72

まとめ

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

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

う

ちゃんとした

AD FS deep dive - claim rule set

Technology

Transcript of AD FS deep dive - claim rule set