windows phone アプリ開発者のための ad fs 2.0 セットアップ手順

1

Windows Phone Windows Phone 開発者のための開発者のためのADAD FS 2.0FS 2.0 セットアップ手順セットアップ手順

Windows Phone Windows Phone 開発者のための開発者のためのADAD FS 2.0FS 2.0 セットアップ手順セットアップ手順

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

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

twitter @junichia

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

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

twitter @junichia

第第 1.0 1.0 版版2011.11.292011.11.29

第第 1.0 1.0 版版2011.11.292011.11.29

Active Directory

2

目次

1. AD FS のセットアップ2. AD FS に RP を登録する3. 要求規則（クレームルール）について4. 要求規則（クレームルール）の定義例5. カスタムルールについて6. カスタムルールの定義例

3

１． AD FS のセットアップ

4

AD FS 2.0 のダウンロードActive Directory Federation Services 2.0 RTW - 日本語

2008 用

2008 R2 用

① AD FS 2.0 のインストール

5

AD FS 2.0 のインストール (1)

• AdfsSetup.exe を実行

6

AD FS 2.0 のインストール (2)

前提条件は自動的に満たしてくれる前提条件は自動的に満たしてくれる

再起動

7

AD FS 用サービスアカウントの作成

• AD FS が使用するサービスアカウント• サーバーファーム（複数の AD FS サービス）で共有するため

ドメインユーザーアカウントとして作成する– スタンドアロンの場合には Network Service アカウントが使用される

• 管理者権限は（必ずしも）必要ない– 管理者権限（ servicePrincipalName の書き込み権限）が無い場合 SPN の自動登

録に失敗する（後述）

作成例

8

IIS で自己署名証明書を作成

サブジェクト（主体）がサーバーのFQDN であること

を確認

サブジェクト（主体）がサーバーのFQDN であること

を確認

9

構成ウィザードの起動

こいつをクリックこいつをクリック

10

AD FS の構成 (1)

11

AD FS の構成 (2)

事前に作成した自己署名証明書を選択（証明書が 1 つしか無ければ自動的に表示され

る）

事前に作成した自己署名証明書を選択（証明書が 1 つしか無ければ自動的に表示され

る）

事前に作成しておいたサービスアカウン

トを指定する

事前に作成しておいたサービスアカウン

トを指定する

（注意）サービスアカウントの入力が求められるのは「サーバーファーム」を選択した場合

12

AD FS の構成 (3)

13

AD FS の構成 (4)

サービスアカウントに指定したユーザーが管理者権限を持っていない場合

に発生する

サービスアカウントに指定したユーザーが管理者権限を持っていない場合

に発生する

14

SPN を手動で登録する

C:\>setspn -a host/adfssrv < ドメイン名 >\< サービスアカウント名 >

( 例 ) setspn -a host/adfssrv tf\adfssvc

P5 で作成したサービスアカウントを使用して、コマンドプロンプトから以下を実行するここは固

定ここは固

定

以上！超簡単！超簡単！

15

AD FS 2.0 をアンインストールするには

1. 証明書共有コンテナを削除（ PowerShell を使用）

ADSI Edit を起動し、「既定の名前付きコンテキスト」に接続し、 CertificateSharingContainer の値と一致するコンテナを削除する。

2. AD FS 2.0 （ KB974408 ）を削除3. WIF ランライム（ KB974405 ）を削除4. WID または SQL Server の当該インスタンス（もしくはデータベースの

み）を削除5. IIS 上のアプリケーションとアプリケーションプール、ファイル群を削除6. SPN を削除

サービスアカウントの servicePrincipalName 属性から「 host\adfssrv 」を削除

（参考） http://blogs.technet.com/b/junichia/archive/2010/07/28/3347209.aspx

PS C:\>Add-PsSnapin Microsoft.Adfs.Powershell PS C:\>Get-ADFSProperties |Select-Object CertificateSharingContainerCertificateSharingContainer --------------------------- CN=0586a130-89fa-40e8-8896-18ece4d171e7,CN=ADFS, CN=Microsoft, CN=Program Data, DC=T3304, DC=com

C:\setspn -d host/adfssrv <AD FS サーバーのホスト名 >

再構成だけしたい場合は↑↓を実施

16

２． AD FS に　　証明書利用者信頼（ RP ）を登録する

ここでは、 Windows Phone にセキュリティトークンが発行できるようにするためのダミー RP （ Relying Party ）を登録します

17

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

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

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

「証明書利用者」とは「 RP （ Relying Party ）」のこと。既定では何も定義されていない。「証明書利用者」とは「 RP （ Relying Party ）」のこと。既定では何も定義されていない。

「要求プロバイダー」とは「クレームプロバイダー（クレームの提供者）」のこと。既定では自身が所属している Active Directory ドメインが定義されている。

「要求プロバイダー」とは「クレームプロバイダー（クレームの提供者）」のこと。既定では自身が所属している Active Directory ドメインが定義されている。

この AD FS 2.0 （ STS ）で扱うことができるクレームが定義されている。逆に言えばここに定義されていないクレームを使うことはできない。

この AD FS 2.0 （ STS ）で扱うことができるクレームが定義されている。逆に言えばここに定義されていないクレームを使うことはできない。

18

RP の登録

19

適当に適当に

20

何もせずに次へ

21

適当なサイトをでっち上げて入

力

適当なサイトをでっち上げて入

力

22

何もせずに次へ

26

3 ．要求規則（クレームルール）について

ここから先は大人になってから

27

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

日本語対応する英語

要求 Claim, クレーム

規則 Rule, ルール

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

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

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

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

発行承認規則 Issuance Authorization Rules

受付変換規則 Acceptance Transform Rules

発行変換規則 Issuance Transform Rules

28

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

ができない（カスタムルールでは独自に作成可能）

あくまでも識別名としての「名前」。この STS内部だけで通用する。

あくまでも識別名としての「名前」。この STS内部だけで通用する。

ワールドワイドで一意なクレームの名前（だから URI で書かれている）。これを使ってクレームが識別される。

ワールドワイドで一意なクレームの名前（だから URI で書かれている）。これを使ってクレームが識別される。

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

か否かを定義

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

か否かを定義

29

（参考）既定のクレームタイプ

英語表記日本語表記

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

30

英語表記日本語表記

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

つづき

31

要求規則 (Claim Rule)• 入力された情報をルール ( 規則 ) に沿って処理し出力する• 処理されたクレームは既定のパイプラインを通る

メンバーシップ

入力方向の要求

カスタムクレーム

他の要求プロバイダー

LDAP 属性

スルー

変換

フィルター

AD DSAD LDS

LDAP出力

SQL Serverその他

要求規則

クレームパイプラインと要求規則（クレームルール）

32

要求規則セット (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 で実装する。


33

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)

② 承認する② 承認する


34

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

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

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

① 受付ける① 受付けるクレームパイプラインと要求規則（クレームルール）

35

発行承認規則• 「証明書利用者信頼」で設定する• 「発行変換規則」に移行させるかどうかを判断• クレームは発行しない

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

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

② 承認する② 承認する


36

発行変換規則• 「証明書利用者信頼」で設定する• 以下を最終決定する

• ユーザーにセキュリティトークンを発行するかどうか• RP/SP にどんなクレームを送信するか

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

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

③ 発行する③ 発行するクレームパイプラインと要求規則（クレームルール）

37

クレームルールを定義するには？• 要求規則テンプレートを使用

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

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

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

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

and くどいようですが…


38

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


39

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

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

40

シナリオ

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

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

ldap 属性クレームタイプ

氏名 displayname 名前

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

部署 department 部署

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

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


41

作業概要

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


42

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

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

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


43

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


44

「 LDAP 属性を要求として送信」を選択「 LDAP 属性を要求として送信」を選択

Active Directory の属性「 title 」を「役割」に放り込む

Active Directory の属性「 title 」を「役割」に放り込む


45

さらに規則を追加するさらに規則を追加する

「入力方向の要求に基づいてユーザーを許可または拒否」を選択「入力方向の要求に基づいてユーザーを許可または拒否」を選択


46

クレーム「役割」が「エバンジェリスト」ならば…クレーム「役割」が「エバンジェリスト」ならば…

条件に合致したユーザーのみを「許可」条件に合致したユーザーのみを「許可」


47

要求規則の処理プロセスについて

要求規則要求規則 11要求規則要求規則 11


要求規則セット

Inp

ut

Cla

im S

et

Ou

tpu

t Cla

im S

et

クレーム

条件発行

トークン

要求規則要求規則 nn要求規則要求規則 nn

前のルールの結果が次のルールに引き継がれる


48

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




役職 title 役割


49

LDAP 属性を要求して送信LDAP 属性を要求して送信

複数の ldap 属性を一度に定義可能複数の ldap 属性を一度に定義可能


50

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

51

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

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

発発行行変変換換規規則則

inpu

t

outp

ut

受受けけ付付けけ変変換換規規則則

inpu

t

outp

ut

発発行行承承認認規規則則

inpu

t

outp

ut

OK/NG

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

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


52

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

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

対処•当該ルール以前のルールから電子メールアドレスの発行ルールを削除する

上で発行してしまう

と…

上で発行してしまう

と…それ以降でフィルターすること

はできない

それ以降でフィルターすること

はできない


53

カスタムルールについて

54

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

55

条件部

発行部

カスタムルールの定義

56

カスタムルールの構造

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

=>True

False

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

条件部条件文 1

条件文 2&&&&

オプション

発行部

発行文

条件部

発行部

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


57

書式の基本 ①

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


58

書式の基本 ②

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


59

書式の基本 ③ ～ 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 クレーム


60

カスタムルール活用のコツ ①

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

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

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

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

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


61

カスタムルール活用のコツ ②

[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 ケタである

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


62

カスタムルール活用のコツ ③ファンクションの活用•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}"));


63

発行ステートメントについて



要求規則セット

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 領域にのみ発行


64

カスタムルールの定義例

65

シナリオ• 役割が「エバンジェリスト」にのみトークンを発行する• ユーザーのアクティブ度（笑）をログオン回数から判定し、回数に応じた

Status 与える（アプリケーション側では Status に応じて表示するメニューを変える）

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




役職 title 役割

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

ステータスーステータス

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

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






66

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

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


67

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

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


68

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

69

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

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

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


70

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 クレームを発行する


71

完成形

ルールは上から実行される6 userstatus クレームを発行する < 要求規則の表示 >


windows phone アプリ開発者のための ad fs 2.0 セットアップ手順

Technology