AD FS deep dive - claim rule set

9,712 views

Published on

Published in: Technology
0 Comments
11 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,712
On SlideShare
0
From Embeds
0
Number of Embeds
3,278
Actions
Shares
0
Downloads
152
Comments
0
Likes
11
Embeds 0
No embeds

No notes for slide

AD FS deep dive - claim rule set

  1. 1. AD FS 2.0 Deep Dive~ 要求規則を極める ~ 2012.01.21 マイクロソフト株式会社 エバンジェリスト 安納 順一(あんのう じゅんいち) http://blogs.technet.com/junichia/ twitter @junichia 1
  2. 2. 本日の内容• AD FS がどのようにセキュリティトークンを発 行するのかを理解しましょう (要求規則とクレームパイプライン)• 複雑なクレームを含んだセキュリティトークン の発行方法を理解しましょう 2
  3. 3. 目次1. AD FS の基礎知識2. クレームパイプラインとクレームルール(要求規則)3. クレームルールを定義するには4. クレームルールの定義 例5. クレームルールの処理プロセス6. カスタムルール7. カスラムルールの定義 例 3
  4. 4. AD FS 2.0 Deep DiveAD FS の基礎知識 さくっと理解しましょう~ 4
  5. 5. よくあるシステムモデル • WEB アプリにアクセスするには AD 認証が必要 • WEB アプリが独自にユーザーの情報を管理している Active Directory ドメイン ユーザーの 役割や属性 統合認証 役割ごとの アクセス権 AD DS WEB DB AD LDS アプリ サーバー ブラウザー 5
  6. 6. AD FS を使ったシステムモデル • WEB アプリにアクセスするにはセキュリティトークンが必要 • DB サーバーで管理する個人情報を最小限にできる • クライアントやWEBはドメイン参加の必要が無い(SSOしなければ) • WEBとADの通信は発生しない(トークンはブラウザ経由で渡される)ユーザーの役割や属性 役割ごとの アクセス権 AD DS AD FS WEB DB AD LDS アプリ サーバー ブラウザー 6
  7. 7. AD FS を使ったシステムモデル • WEB アプリにアクセスするにはセキュリティトークンが必要 • DB サーバーで管理する個人情報を最小限にできる • クライアントやWEBはドメイン参加の必要が無い(SSOしなければ) • WEBとADの通信は発生しない(トークンはブラウザ経由で渡される)ユーザーの アプリはクラウドでもOK役割や属性 役割ごとの アクセス権 AD DS AD FS WEB DB AD LDS アプリ サーバー ブラウザー 7
  8. 8. セキュリティ トークン/アサーション• パッケージ化されたクレーム• 発行者(オーソリティ)の署名によって信頼性を担保• 発行者とは事前に信頼関係を結んでおく セキュリティトークン/ アサーション 8
  9. 9. クレーム とは • クレームストア(AD DS/LDS/SQL)から収集したユーザー の属性 • アプリケーションの要求に応じて AD FS 側で生成ルール を定義 • アクセス承認に使用される 9
  10. 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. 11. AD FS 2.0 Deep Diveクレームパイプラインと要求規則(クレームルール) 11
  12. 12. 用語について基本的に、日本語 UI に沿った用語を使用します。が…ちょっとアレなところもあるので、以下の対応票を参考にしてください。 日本語 対応する英語 要求 Claim, クレーム 規則 Rule, ルール 要求の種類 Claim Type, クレームタイプ 要求記述 Claim Description, クレームディスクリプション 要求 プロバイダー Claims Provider, クレーム プロバイダー 証明書利用者 Relying Party, リライング パーティ 発行承認規則 Issuance Authorization Rules 受付変換規則 Acceptance Transform Rules 発行変換規則 Issuance Transform Rules 12
  13. 13. 要求規則 (Claim Rule) • 入力された情報を処理するためのルール (規則) • 要求規則の種類は大きく分けて3つ – パススルー – 変換 – フィルター 要求規則 他のプロバイ ダー スルー AD DS AD LDS 入力 変換 出力 LDAP SQL Server フィルター その他 13
  14. 14. セキュリティトークンの発行処理 AD DS/LDS AD FS Token SQL Server 拡大すると クレームプロバイダー側 リライングパーティー側 ① 受付ける ② 承認する ③ 発行する 受け 発行 発行 付け 承認 変換 変換 規則 規則 規則 クレームパイプライン 14
  15. 15. なぜ分かれているのか? • CP と RP が別組織である場合に対応するため 企業A 企業BAD DS/LDS AD FS AD FS Token TokenSQL Server アプリ用にトークン 別組織からのトー を整形/変換して送出 クンを検証する する クレームプロバイダー側 リライングパーティー側 ① 受付ける ② 承認する ③ 発行する 受け 発行 発行 付け 承認 変換 変換 規則 規則 規則 15
  16. 16. クレーム パイプラインの詳細 証明書利用者 (RP) CP側のクレームストア RP側のクレームストア ① 受付ける ② 承認する ③ 発行する 評価 受け 発行 発行 output output output input input 付け input 承認 変換 トークン 変換 規則 規則 規則 クレームプロバイダー側 リライングパーティー側 要求規則 (Claim Rule) 16
  17. 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
  18. 18. クレームルール(要求規則)を定義するには 18
  19. 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. ① 受付ける 受け付け変換規則• 「要求プロバイダー信頼」で設定する• 「証明書利用者信頼」に渡すためのクレームをセットする大原則ここで定義されたクレームのみが、パイプラインに沿って「証明書利用信頼」に渡される 20
  21. 21. 注意!既定のクレームセットを消さないこと! もし消してしまったら以下を参照して復旧してください。 http://blogs.technet.com/b/junichia/archive/2012/01/19/3476217.aspx 21
  22. 22. ② 承認する 発行承認規則• 「証明書利用者信頼」で設定する• 「発行変換規則」を実行するかどうかを判断• セキュリティトークンは発行しない この設定では「受け付け変換規則」 を通過したユーザー全てに、「発行 変換規則」への進行を許可 22
  23. 23. ③ 発行する 発行変換規則• 「証明書利用者信頼」で設定する• ユーザーに発行するセキュリティトークンのルールを定義する 規定では空(何も発行しない) ただし、「認証メソッド」と「認 証日時」だけは送信される 23
  24. 24. 2種類の定義方法• 要求規則テンプレートを使用 • 規定で用意されているルールを使用する場合 • [LDAP 属性を要求として送信] • [グループ メンバーシップを要求として送信] • [入力方向の要求を変換] • [入力方向の要求をパススルーまたはフィルター処理] • [カスタム規則を使用して要求を送信] • [入力方向の要求に基づいてユーザーを許可または拒否] • [すべてのユーザーを許可]• カスタムルールを定義 • 用意されていないルール(ロジック)を使用する場合 • 用意されていない ldap 属性を使用する場合 • AD DS/ldap 以外のクレームストアを使用する場合 • SQL Server • その他(テキストファイル など) [要求記述]に記載されていないクレームタイプは使用できないので、 事前に定義しておく必要がある 24
  25. 25. 要求記述について • システム間で送受信するクレームタイプが定義されている • ここに定義されていないクレームは、要求規則テンプレートで使用するこ とができないあくまでもADFS内の「名 ワールドワイドで一意なクレームの名前 このクレームを外部から受信可前」。このSTS内部でだけ (だから URI で書かれている)。 能か否か、外部に送信可能か否通用する。 これを使ってクレームが識別される。 かを定義 25
  26. 26. クレームタイプは世界で一意 • クレームタイプとは世界共通のクレームの識別名 • プロパティ名のようなもの • URI 形式で示す • どのようなクレームタイプを使用するかは両者で事前にネゴが必要 • 通常はRP側が定義し、メタデータとして提示する • “適当な命名規約”や”クレームタイプの流用”は後々混乱の元! 企業A 企業BAD DS/LDS AD FS AD FS Token TokenSQL Server 同じクレームタイプを使用しない と評価のしようがない! http://schemas.tf.com/claims/companyname = マイクロソフ ト http://schemas.tf.com/claims/age = 43 http://schemas.tf.com/claims/kanaName = あんのう 26
  27. 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. 28. 英語表記 日本語表記Deny Only Group SID 拒否のみグループ SIDDeny only primary SID 拒否のみプライマリ SIDDeny only primary group SID 拒否のみプライマリ グループ SIDGroup SID グループ SIDPrimary Group SID プライマリ グループ SIDPrimary SID プライマリ SIDWindows account name Windows カウント名Authentication Instant 認証タイム スタンプ 28
  29. 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-NameProxy-Addresses (proxyAddress) (userPrincipalName) SAM-Account-Name(sAMAccountName) 29
  30. 30. 要求規則(クレームルール)の定義 例1. 要求記述の定義2. 発行承認規則の定義3. 発行変換規則の定義4. クレームルールの定義にありがちなミス 30
  31. 31. 要求規則(クレームルール)の定義 例シナリオ • 役割がエバンジェリストであるユーザーにのみ セキュリティトークンを発行する • セキュリティトークンには「氏名」「役職」「部 署」「メール」を含める ldap 属性 クレームタイプ 氏名 displayname 名前 メール email 電子メール アドレス 部署 department 部署 規定で用意されない 役職 title 役割 ため「要求記述」に 定義する必要がある 31
  32. 32. 要求規則(クレームルール)の定義 例作業概要① 要求記述に「部署」を追加② 「受け付け変換規則」に4つのクレームタイプを定義③ 「発行承認規則」で「エバンジェリスト」以外を抑止④ 「発行変換規則」で4つのクレームを定義する ldap 属性 クレームタイプ 氏名 displayname 名前 メール email 電子メール アドレス 部署 department 部署 役職 title 役割 32
  33. 33. ① 要求記述に「部署」を追加 クレームタイプ を URI で設定する。 世界で唯一にするため、自社ドメイ ン名を入れるとよい。 33
  34. 34. ② 「受け付け変換規則」に4つのクレームを定義 ldap 属性 クレームタイプ 氏名 displayname 名前 メール email 電子メール アドレス 部署 department 部署 役職 title 役割 34
  35. 35. これは消さな い! Active Directory から属性を 拾ってクレームに格納する 35
  36. 36. 4つのクレームを追加 36
  37. 37. ③「発行承認規則」で「エバンジェリスト」以外を抑止 「すべてのユーザーにアク セスを許可」を削除 37
  38. 38. 要求規則(クレームルール)の定義 例 CP から受け取ったクレームタイプを判 定するクレームタイプ「部署」に「エバンジェリスト」が入っていればトークン発行を許可する 38
  39. 39. ④「発行変換規則」で4つのクレームを定義 ldap 属性 クレームタイプ 氏名 displayname 名前 メール email 電子メール アドレス 部署 department 部署 「証明書利用者信頼」に登録 役職 title 役割 されているRP一覧 39
  40. 40. 同様に「メール」「部署」「役割」についても記述す る。 40
  41. 41. 41
  42. 42. 実行結果例 OK NG役割が「エバンジェリスト」でなければアクセス拒否 42
  43. 43. ちなみに Windows Phone から 43
  44. 44. クレームルールの定義 ありがちなミス ①現象例• 「発行承認規則」で[入力方向の要求に基づいてユーザーを許可または拒否] ルールを使用し、クレーム名[役職] に「部長」と書かれているユーザーのみに 許可したいが、全てのアクセスが拒否されてしまう原因• [役職] クレームの中身がからっぽ。 「受け付け変換規則」で [役職] クレームが定義されていない場合、「発行承 認規則」でいきなり[役職]クレームによる条件判定を行おうとしても、クレー ムの中身が空のため判定は「NG」となる。事前に、[役職]クレームに値を入力 するルールが定義されている必要がある。 ここでクレームを評価する以前に、クレーム が発行されていない場合、「空」の値が入っ ているものとして評価されてしまう 受け 発行 発行 output output output input input input 付け 承認 変換 変換 規則 OK/ 規則 規則 NG 44
  45. 45. クレームルールの定義 ありがちなミス ②現象• ルールを変えても送信されるクレームが変わらない原因• デスクトップ上に別のブラウザやタブが起動しており、既にクレーム を取得している こいつを閉 じないと…. 同じクレー ムが表示さ れる 45
  46. 46. クレームルールの定義 ありがちなミス③現象• 「入力方向の要求をパススルーまたはフィルター処理」ルールを使用して、 「特定の電子メール サフィックスの値と一致する要求値だけをパス スルーす る」を定義しているが、サフィックスが一致しないユーザーに対してもクレー ムが発行されてしまう。原因• クレームルールに複数のルールを定 義しており、当該ルール以前に電子 メールアドレスクレームを発行して いる場合、それを取り消すことはで 上で発行し きない。 てしまうと… あとからフィル対処 ターすることは• 当該ルール以前のルールから電子 できない メールアドレスの発行ルールを削除 する 46
  47. 47. クレームルールの処理プロセス 47
  48. 48. 原則 ① 要求規則は上から処理される上の規則の出力結果が下規則の入力となる 要求規則 48
  49. 49. 原則 ② 前の規則の出力結果が次の規則の入力となる クレーム 要求規則セット 要求規則1 Output Claim Set Input Claim Set 条件 発行 要求規則2 要求規則 n トークン 49
  50. 50. 原則 ③ Output Claim Set に蓄積されたデータがセキュリティトークンとなる 超重要 一度 Output Claim Set に出力されたクレームは削除できない ※発行ステートメント(issue/add)によって調整する 要求規則セット Output Claim Set 要求規則1Input Claim Set title = => issue (type = “title”, value = “部長"); “部長” 要求規則2 title = role=“M [type == “title”, Value == “部長”] anager” “部長” => issue (type = "Role", value = “Manager"); カスタムルールを覚えましょう! title role 50
  51. 51. カスタムルールここを習得できれば怖いものなし!難易度高し! 51
  52. 52. カスタムルールとは?「要求規則言語」を直接記載することで、規定のルールテンプレートでは提供されていない複雑な発行処理を行うことができる (例) • 規定で用意されていない ldap 属性を取得したい • 計算結果から判定したい • 正規表現を使用して文字列を判定したい • 出力したくないクレームがある 52
  53. 53. カスタムルールの定義カスタムルールのサンプルを見るには 53
  54. 54. カスタムルールの定義 条件部発行部 54
  55. 55. カスタムルールの構造 条件部 発行部 条件文 1 True 条件文 2 => && 発行文 && False条件部 入力方向のクレーム/属性をチェックし、オプション すべての条件が True の場合に「発行部」が実行される。 条件部が無い場合には無条件で True とみなされる。発行部 発行するトークンタイプと、 必須 そこに格納する属性/値を指定する。 「クレームが発行されない」 ≠ アクセスできない ※クレームを持っていないユーザーにアクセスを許可するかどうかは アプリケーションの判断 55
  56. 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. 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. 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. 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. 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. 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. 62. 発行ステートメントによる処理の違い • issue :クレームを発行する(output claim set に発行する) • add :input claim set に直接発行する → クレーム発行のためのテンポラリー領域的な使い方 add ステートメント クレーム は output クレーム 要求規則セット を発行しない 要求規則1 => add (type = “title”, value = “部長"); Output Claim SetInput Claim Set 要求規則2 title = [type == “title”, Value == “部長”] role=“M “部長” anager” => issue (type = "Role", value = “Manager"); 62
  63. 63. カスタムルールの定義 例 63
  64. 64. シナリオ • 役割が「エバンジェリスト」にのみトークンを発行する • ユーザーのアクティブ度をログオン回数から判定し、回数に応じた Status 与 える(アプリケーション側では Status に応じて表示するメニューを変える) • 以下のクレームを送信する ldap 属性 クレームタイプ 氏名 displayname 名前 メール email 電子メール アドレス 部署 department 部署 規定で用意されない 役職 title 役割 ため「要求記述」に ログオン回数 logonCount ログオン回数 定義する必要がある ステータス ー ステータス 作業手順 ① 要求記述に「ログオン回数」と「ステータス」を追加 ② 「発行変換規則」で「ログオン回数」と「ステータス」を定義 64
  65. 65. 要求記述に「ログオン回数」を定義 クレームタイプ を URI で設定す る。 65
  66. 66. 要求記述に「ステータス」を定義 クレームタイプ を URI で設定す る。 66
  67. 67. カスタムルールに「ログオン回数」と「ステータス」を定義 67
  68. 68. AD の logonCount 属性を「ログオン回数」にセット Active Directory から logonCount 属性を取り出し、クレームタイプ logoncount に入れている 68
  69. 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. 70. 完成形 6 userstatusクレームを発行する <要求規則の表 示> 70
  71. 71. まとめ 71
  72. 72. まとめ ちゃんとし た• Active Directory を構築しましょう • ユーザーアカウントの一元管理 • ユーザーロールの一元管理 • アカウントの有効期限 • パスワードの複雑性• 認可の管理は IT Pro の腕にかかっています • AD FS を習得しましょう • クレームルールはビジネスロジックです • アプリケーションの対応も同時に進めましょう 72
  73. 73. 73

×