SEMINAR LIGHTNING TALK COLUMNS INTERVIEW 1 Cloud TechCenter インフラ担当者のためのクラウド情報サイト http://technet.microsoft.com/ja-jp/cloud/default.aspx 2 「クラウドの素朴な疑問」にお答えします bing で検索!「クラウドの素朴な疑問」 3 本日の予定 • 13:30 - 17:00 「ADFS 2.0 を使用して Windows Azure との SSO を実現しよう」安納 • 17:00 - 17:30 「クラウド時代の「ID管理」と「認証セキュリティ」」 野村総合研究所 基盤ソリューション事業本部 勝原氏 • 17:30 - 18:00 ライトニングトーク • 18:00 - 19:00 懇親会 4 AD FS 2.0 を使用して Windows Azure との SSO を実現しよう 第 1.0 版 2010.11.02 マイクロソフト株式会社 エバンジェリスト 安納 順一(あんのう じゅんいち) http://blogs.technet.com/junichia/ twitter @junichia 5 本日のテーマと内容 何かと難解な AD FS 2.0 の概念と操作方法を、 実際の構築手順を体験しながら理解しましょう AD FS 2.0 を使用して、Windows Azure 上に展開した アプリケー ション への シングルサインオン を構成します。 1. 2. 3. 4. AD FS 2.0 のインストールおよび環境設定 Windows Azure の環境設定 クレームを認識するアプリケーションの作成 アプリケーションをWindows Azure 上に展開 途中、操作をお手伝いいただくこともあります。 3.5時間~4時間を要しますが、根性でのりきりましょう! 6 Agenda [構築作業 前篇] インフラ編 1. AD FS 2.0 の基礎知識 2. これから作成する環境について 3. AD FS 2.0 のセットアップ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ WinSv 2008 R2 のセットアップ Active Directory のセットアップ SQL Server のセットアップ IIS のインストールと構成 NLB のインストールと設定 AD FS 2.0 用証明書の準備 IIS の SSL を有効化 AD FS 2.0 のインストール AD FS 2.0 初期構成の準備 AD FS 2.0 の初期構成 [構築作業 中編] アプリケーション編 5. クレーム対応アプリとは? 6. クレーム対応アプリの作成と展開 ~ オンプレミス編 ① ② ③ ④ 展開先 IIS の準備 開発環境の準備 アプリケーションの開発 IIS にアプリを展開 7. クレーム対応アプリの作成と展開 ~クラウド編 ① Windows Azure の準備 ② アプリケーションの開発 ③ Windows Azure にアプリケーション を展開 [構築作業 後編] AD FS Deep Dive 4. AD FS 2.0 管理コンソールにつ 8. クレームパイプラインとクレーム ルール いて 9. カスタムルールの設定 10. AD FS 2.0 の監査 7 AD FS 2.0 の役割と目的について復習しておきましょう AD FS 2.0 の基礎知識 8 ID を使用する環境 アプリケーション在るところ「ID」在り クラウド 企 業 間 9 予測される ID 管理の問題点 • 見えない利用者の ID 管理/認証/承認 • 異なる認証方式の相互運用 • ディレクトリサービスの設置が困難 クレームベース セキュリティ フェデレーション セキュリティ モデル 10 クレームベースセキュリティの例~入国審査 信頼 米国政府 日本国政府 発 行 パスポート • 発行国 • 氏名 • 有効期限 • 旅券番号 • 写真 • 出国印 出 国 ビザ • 滞在可能期間 入国申請書 • 滞在期間 • 滞在先 信頼 健保番号 /免許証番号 /住民票 本人 • 顔 • 指紋 空港 入 国 パスポート ・ ・ 11 クレームベース セキュリティ モデル クレーム プロバイダー 信頼 オーソリティ 日本国政府 サブジェクト 健保番号 /免許証番号 資格 /住民票 情報 パスポート • クレーム 発行国 • クレーム 氏名 • クレーム 有効期限 • クレーム 旅券番号 • クレーム 写真 • クレーム 出国印 ビザ • クレーム 滞在期間 出 国 入国申請書 • クレーム 滞在期間 • クレーム 滞在先 署名 米国政府 セキュリティ トークン 本人 • クレーム 顔 • クレーム 指紋 信頼 発 行 リライング パーティ 入 国 空港 リ ソ ー ス パスポート ・クレーム ・ 12 クレーム(主張)とは • アプリケーションに渡すユーザー自身の属性 • アクセス承認に使用される 13 セキュリティ トークン • パッケージ化されたクレーム • 発行者の署名によって信頼性を担保 • STS ( Security Token Service ) が生成する セキュリティトークン 14 クレームベース セキュリティを使用したID 連携 (フェデレーション)と SSO の実現 • 利用者は事前に 「認証機関」で認証を済ませている • 「サービスプロバイダー」側のアプリケーションは 「認証機関」が発行し たトークンをベースにアクセス権を決定する(再認証は行わない) 認証機関 サービスプロバイダー は 認証機関 を信頼している ②本人証明 Security Token サービスプロバイダー ③Token提示 Users Users ④ トーク ン解析/ア クセス権決 定 利用者 ④ID と ID を対応付ける 15 ID連携(フェデレーション)の基本構成 • 認証機関(IdP/CP)とサービスプロバイダー(RP/SP)は トークンを処理す るためのサービスを持っている(セキュリティトークンサービス) • トークンは「セキュリティ トークン サービス(STS)」によって発行される • トークンに格納するクレームは「クレームストア」に格納されている IdP/CP RP/SP は CP/IdP を信頼している RP/SP Security Token クレーム セキュリティ ストア トークン サービス IdP:Identity Provider CP:Claim Provider 利用者 セキュリティ トークン サービス RP:Relying Party SP:Service Provider 16 SSO を実現するための構成要素 AD DS 認証サーバー • ユーザーを認証する • AD FS 2.0 サービスを認証する AD FS 2.0 STS( セキュリティトークンサービス ) • AD認証されたユーザーに対してセキュリティトークンを 発行する • アプリケーションにセキュリティトークンを渡す AD DS/ldap SQL Server クレームストア • セキュリティトークンに組み込むユーザー属性が格納さ れている WIF WS-Federation/WS-Trust に対応したアプリケーション ※WIF は(現時点では)SAML 2.0 に対応していない 17 基本的な構成 • それぞれの企業にSTSを設置 • STS 間でフェデレーション信頼を構築 企業A IdP/CP 企業B RP/SP AD DS 信頼 AD DS AD FS 2.0 Application ② クレーム ストア Token クレームストア AD FS 2.0 WIF 発 行 IdP:Identity Provider CP:Claims Provider RP : Relying Party SP : Service Provider 18 基本的な構成~簡易版 • 同一企業内であれば STS は1台で構築可能 企業A IdP/CP 1台のサーバーで構築 RP/SP 信頼 AD DS WIF AD FS 2.0 ② Token クレームストア Application 発 行 19 アプリケーションがクラウドだったら… • クラウドアプリでも考え方は変わらない 企業A IdP/CP 1台のサーバーで構築 AD DS RP/SP WIF Application AD FS 2.0 ② Token クレームストア 発 行 20 AD FS 2.0 関連コンポーネントの配置と役割 intranet AD DS 構成DB DMZ cluster クレーム ストア 構成DB STS : Security Token Services R-PROXY : Reverse Proxy STS load balance load balance 認証 AD DS or SQL Server or ldap services AD FS PROXY AD FS Internet R-PROXY 21 これから作成する環境 22 システム構成図 システムの特徴 • AD FS 2台構成(NLB を使用) • 構成DBとして SQL Server を使用 Application 基本構成情報 • ドメイン名 :tf.com • 管理者 :administrator • 管理者パスワード:P@ssw0rd tfadfs NLB tf20101102-01 tf20101102-02 tf20101102-03 tf20101102-VS AD FS 2.0 AD FS 2.0 Application Application IIS IIS SQL 2008 R2 WIF SDK AD DS DNS IIS Azure SDK Azure Tools VS 2010 23 手順概要 済 済 済 済 済 解 説 構 築 1. Windows Server 2008 R2 のインストールと構成 2. Active Directory のインストールと構成 3. SQL Server のインストール 4. IIS のインストール 5. Windows Azure サブスクライブ 6. NLB のインストールと構成 7. AD FS 2.0 展開の準備 8. AD FS 2.0 のインストールと初期構成 9. アプリケーションの開発 10. Windows Azure 上にアプリケーションを展開 11. クレームルールのカスタマイズ 24 AD FS 2.0 のセットアップ ① ② ③ ④ WinSv 2008 R2 のセットアップ Active Directory のセットアップ SQL Server のセットアップ IIS のインストールと構成 ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ NLB のインストールと設定 AD FS 2.0 用 証明書の準備 IIS の SSL を有効化 AD FS 2.0 のインストール AD FS 2.0 初期構成の準備 AD FS 2.0 の初期構成 25 AD FS 2.0 のセットアップ ⑤NLB のインストールと設定 26 NLB の仕組み • • • • NLB : Network Load Balance OS 標準機能として提供 全てのポートをロードバランス対象にすることができる マルチホームの場合、対象となるアダプターを選択可能 アダプターが持っている元のアドレスは保持される host1 NIC NIC NLB NIC NLBクラスター NIC heartbeat heartbeat host2 名 前 解 決 NLB 27 NLB 機能の追加 [機能]-[ネットワーク負荷分散] ※NLB を使用するすべてのホストで実施する 28 NLBの設定(1台目のホスト)① [管理ツール]ー[ネットワーク負荷分散マネージャー] 負荷分散クラスターに追 加したいネットワークアダ プターを選択 29 NLBの設定(1台目のホスト)② 共有するアドレス を追加 30 NLBの設定(1台目のホスト)③ クライアントはこ の情報を使用し てアクセスする 再起動しましょう 31 NLBの設定(2台目のホスト) 追加したいホスト を指定 以降、1台目と同じ 32 DNS に NLBクラスターのホスト名を追加 tfadfs.tf.com 192.168.200.10 33 完成形 34 完成後のネットワーク構成 tfadfs.tf.com(192.168.200.10) tf20101102-01 (192.168.100.1) NLB heartbeat heartbeat tfadfs.tf.com 名 前 解 決 NLB tf20101102-02 (192.168.100.2) 35 AD FS 2.0 のセットアップ ⑥ AD FS 2.0 用 証明書の準備 36 AD FS 2.0 に必要な証明書 • サービス通信証明書(SSL に使用) • AD FS の通信を暗号化するために使用 • 既定では IIS の SSL 用証明書が使われる • サブジェクトがフェデレーションサービス名と一致していること ※サーバーファーム構成では注意が必要 • トークン署名証明書 • AD FS が発行するトークンの署名 • 公開メタデータの署名 • RPから送信されるアーティファクト解決要求の署名 • 初期構成時にSHA1を使用して自動生成される • トークン暗号化解除証明書 • AD FS が受け取ったトークンの暗号化を解除するために使用 • IIS の SSL 証明書が既定の暗号化解除証明書として使用される 今回は自己署名証明書を使用します 37 IIS を使用した自己署名証明書の作成 サブジェクト(主体) がホスト名 38 NLB 環境で ユーザーから見えるサーバーは こいつ tfadfs.tf.com(192.168.200.10) tf20101102-01 (192.168.100.1) NLB heartbeat heartbeat tfadfs.tf.com 名 前 解 決 NLB tf20101102-02 (192.168.100.2) 39 自己署名証明書を作成するツール .NET Framework SDK • makecert.exe ← サブジェクトを指定できる • pvk2pfx.exe .CER makecert .PVK pvk2pfx .PFX 40 自己署名証明書の作成 1. Visual Studio をインストールしたマシンにログオン 2. [スタート]-[すべてのプログラム]-[Microsoft Visual Studio 2010]-[Visual Studio Tools]-[Visual Studio コマンドプロンプト] を起動 3. 証明書(.cer)ファイルとプライベートキーファイル( .pvk)ファイルを作成 makecert -r -pe -n "CN=tfadfs.tf.com" -sky exchange “tfadfs.tf.com.cer" -sv “tfadfs.tf.com.pvk" 4. .pvk と .cer から .pfx ファイルを作成する pvk2pfx -pvk “tfadfs.tf.com.pvk“ -spc “tfadfs.tf.com.cer“ -pfx “tfadfs.tf.com.pfx“ -pi <パスワード> 41 AD FS 2.0 のセットアップ ⑧ IIS の SSL を有効化 42 NLBクラスタ用証明書はすべてのサーバーに 今回は 必要ない NLBクラスターの証明書 サーバー証明書 tf20101102-01 tfadfs.tf.com.pfx NLB tfadfs.tf.com tf20101102-01. tf.com.pfx サーバー証明書 tf20101102-02. 今回は tf.com.pfx tf20101102-02 必要ない 43 証明書(.pfx)をインポートする .pfx ファイル 44 [Default Web Site] の SSL を有効にする 45 接続テスト https://tfadfs.tf.com/ 46 自己署名証明書の取り込み 47 48 AD FS 2.0 のセットアップ ⑨ AD FS 2.0 のインストール 49 AD FS 2.0 はすべてのサーバーにインストール tf20101102-01 AdfsSetup.exe tfadfs.tf.com NLB AdfsSetup.exe tf20101102-02 50 AD FS 2.0 のダウンロード Active Directory Federation Services 2.0 RTW - 日本語 2008用 2008 R2 用 51 AD FS 2.0 のインストール① • AdfsSetup.exe を実行 52 AD FS 2.0 のインストール ② 前提条件は自動的 に満たしてくれる 再起動 53 AD FS 2.0 のセットアップ ⑩ AD FS 2.0 初期構成の準備 54 AD FS 2.0 初期構成前の準備 1. サーバー構成を決めておく • スタンドアロン • サーバーファーム 2. 構成データベースを決めておく • Windows Internal Database • SQL Server 3. サービスアカウントを作成しておく 55 サーバーファーム と スタンドアロン • スタンドアロン – AD FS サーバー 1台 – 構成DB は WID のみ (ADFS+WID)*1 • サーバーファーム – AD FS サーバー 複数台を前提とした構成 – ロードバランスが可能 – 構成DB は WID or SQL Server(クラスタ可能) (ADFS+WID)*1 (ADFS+WID)*n ADFS*n + SQL Server 56 AD FS 2.0 ~ サーバー ファームと構成 DB 低 1. スタンドアロン + WID プライマリ ADFS R/W 2. サーバー ファーム+ WID 可 用 性 • • 高 各サーバーが WID を持つ • 5 分に 1 回の更新チェック (各サーバー→プライマリ) 機能制限が発生 • SAML Token Replay Detection • SAML Artifact Resolution ADFS R/O セカンダリ ADFS ADFS ADFS R/O セカンダリ ADFS 3. サーバー ファーム+ SQL Server • • • fsconfig.exe コマンドによる構成 WID からの移行は不可 SQL Server は 1 セット • クラスター構成可能 SQL Server R/W WID:Windows Internal Database 57 構成データベースによる手順の違い 使用する構成データベースによって構成手順が異なる • Windows Internal Database(WID) → ウィザード / fsconfig コマンド • SQL Server → fsconfig コマンド 一度構成した後で移行することはできないので注意しましょう! WIDが使われる 58 (参考) Token Replay Attack とは http://msdn.microsoft.com/en-us/library/ee517257.aspx • 取得済のセキュリティ トークンを再利用して アクセス権を得ようとするアタック – キオスク端末等でブラウザーを閉じないと危険 – ブラウザーの [戻る] でトークン取得ポイントに戻れてしまう • WIF には Replay を検出する機能が実装されている • Replay 検出は規定でオフ • 有効にするには DetectReplayedTokens 値を true 59 (参考) SAML Artifact Resolution とは Artifact (アーティファクト) セキュリティトークン (SAML Assertion) のリファレンス • SSO を実現する トークン受け渡し手順 の 1 つ ① ブラウザーはトークンではなく、トークンの「Artifact」を STS から受け取り RP にリダイレクトする ② RP は受け取った Artifact を IdP に提示して正当性を評価 ③ 評価 OK ならば、RP は IdP から直接トークンを取得する • ユーザーとサーバー間の通信帯域が細い場合に有用 STS 3 2 1 サービス 60 AD FS 用サービスアカウントの作成 • • AD FS が使用するサービスアカウント サーバーファーム(複数のAD FS サービス)で共有するため ドメインユーザーアカウントとして作成する – スタンドアロンの場合には Network Service アカウントが使用される • 管理者権限は(必ずしも)必要ない – 管理者権限(servicePrincipalName の書き込み権限)が無い場合 SPN の自動登録に 失敗する(後述) 作成例 61 AD FS 2.0 のセットアップ ⑪ AD FS 2.0 の初期構成 62 AD FS 2.0 初期構成の流れ tf20101102-01 構成情報は SQL Server に 格納される 1台目 サーバーファームを構成 tfadfs.tf.com NLB 2台目以降 サーバーファームに追加 構成DB (SQL Server) tf20101102-02 63 インストール直後の管理コンソール ちょっとまった! 脊髄クリック注意!! 64 1台目のAD FS ~ 環境構成ウィザード編 ① 65 1台目のAD FS ~ 環境構成ウィザード編 ② 事前に取り込んでおい た証明書が表示される 事前に作成しておいた サービスアカウント (注意) サービスアカウントの入 力が求められるのは 「サーバーファーム」を 選択した場合 66 サービス名をチェック これがAD FS のエンドポイント の一部になります 67 1台目の AD FS ~ 環境構成ウィザード編 ③ サービスアカウントに指定した ユーザーが管理者権限を持っ ていない場合に発生する 68 SPN(Service Principal Name)とは? • サービスのインスタンスを正確に識別するための ID (乗っ取りを回避) • Kerberos でサービスの認証に使用される • 登録するには管理者権限が必要 • ドメイン内に同じ SPN は登録できない SPN チェック SPNを送付 kerberos チケットを発行 AD FS 2.0 サービス (adfssrv) サービス アカウント KDC SPN AD DS チケット送付 サービス認証 (参考)認証のためのサービスID http://msdn.microsoft.com/ja-jp/library/ms733130(VS.85).aspx 69 SPN を手動で登録する setspn -a host/adfssrv <ドメイン名>\<サービスアカウント名> (例) setspn -a host/adfssrv tf\adfssvc 70 AD FS 2.0 を構成するファイルと設定情報 Stand Alone SF (SQL) SF (WID) AD FS 本体ファイルおよび PowerShell コマンドレット ○ ○ ○ WIFランタイム ○ ○ ○ KB974405 ○ インスタンス名 :MICROSOFT##SSEE データベース名 :AdfsArtifactStore :AdfsConfiguration Windows Internal Database ○ SQL Server 証明書共有コンテナ SPN KB974408 ○ インスタンス名 :<指定した名前> データベース名 :AdfsArtifactStore :AdfsConfiguration ○ ○ ファイル:c:\inetpub\adfs アプリケーション :Default Web Site\adfs :Default Web Site\adfs\fs アプリケーションプール :ADFSAppPool ○ ○ CN=xxxx…xxxxx,CN=ADFS,CN=Microsoft,CN=Pr ogram Data,DC=<ドメイン名> ○ ○ HOST/Adfssrv IIS アプリケーション ○ 備考 71 AD FS 2.0 をアンインストールするには (参考)http://blogs.technet.com/b/junichia/archive/2010/07/28/3347209.aspx 1. 証明書共有コンテナを削除(PowerShell を使用) PS C:\>Add-PsSnapin Microsoft.Adfs.Powershell PS C:\>Get-ADFSProperties |Select-Object CertificateSharingContainer CertificateSharingContainer --------------------------CN=0586a130-89fa-40e8-8896-18ece4d171e7,CN=ADFS, CN=Microsoft, CN=Program Data, DC=T3304, DC=com 2. 3. 4. 5. 6. ADSI Edit を起動し、「既定の名前付きコンテキスト」に接続し、 CertificateSharingContainer の値と一致するコンテナを削除する。 AD FS 2.0(KB974408)を削除 再構成だけしたい場合は↑↓を実施 WIF ランライム(KB974405)を削除 WID または SQL Server の当該インスタンス(もしくはデータベースのみ) を削除 IIS 上のアプリケーションとアプリケーションプール、ファイル群を削除 SPN を削除 C:\setspn -d host/adfssrv <AD FS サーバーのホスト名> サービスアカウントの servicePrincipalName 属性から「host\adfssrv」を 削除 72 WID の管理方法 • SQL Server Management Studio Express を使用 • サーバー名は \\.\pipe\mssql$microsoft##ssee\sql\query AD FS 2.0 用 DB 73 1台目のAD FS ~ fsconfig コマンド編(SQL Server を使用) 書式 FSConfig.exe CreateSQLFarm /ServiceAccount <ドメイン名>\<サービスアカウント名> /ServiceAccountPassword <サービスアカウントのパスワード> /SQLConnectionString “ 既定の名前は AdfsConfiguration database=<構成DB名> ; server=<SQL Server のサーバー名>\<インスタンス名> ; integrated security=SSPI " 既定のインスタンス (MSSQLSERVER)なら /AutoCertRolloverEnabled ば指定しなくてもよい /CleanConfig 74 入力例 AD FS 2.0 のインストールディレクトリに移動 C:\> cd C:\Program Files\Active Directory Federation Services 2.0 CreateSQLFarm オプションを指定して実行 C:……\>FSConfig.exe CreateSQLFarm /ServiceAccount TF\adfssvc /ServiceAccountPassword P@ssw0rd /SQLConnectionString “ database=AdfsConfiguration ; server=TF20101102-03 ; integrated security=SSPI " /AutoCertRolloverEnabled /CleanConfig 75 対応を忘れずに! IIS上のアプリケーショ ンを削除していない場 合に出力される 76 2台目以降のAD FS ウィザードを使用する場合(WID の場合) 構成DBが WID の場合にはウィザードを使用することが可能 1台目のADFSサーバー 77 2台目以降のAD FS fsconfig コマンドを使用する場合(SQLSVの場合) 構成DBが SQL Server の場合には fsconfig コマンドを使用する SQL Server の場合にはウィザードを使用できない JoinSQLFarm オプションで実行 C:……\>FSConfig.exe JoinSQLFarm /ServiceAccount TF\adfssvc /ServiceAccountPassword P@ssw0rd /SQLConnectionString “ database=AdfsConfiguration ; server=TF20101102-03 ; integrated security=SSPI " 78 JoinSQLFarm 実行結果例 注意 79 AD FS 2.0 管理コンソールについて 80 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 が定義 されている。 81 82 83 AD FS 2.0 管理コンソールの基礎 要求記述 • システム間で送受信するクレームタイプが定義されている • ここに定義されていないクレームは、要求規則テンプレートで使用するこ とができない(カスタムルールでは独自に作成可能) あくまでも識別名とし ての「名前」。このSTS 内部だけで通用する。 ワールドワイドで一意なクレームの 名前(だから URI で書かれている)。 これを使ってクレームが識別される。 このクレームを外部から受信 可能か否か、外部に送信可 能か否かを定義 84 (参考)既定のクレーム タイプ 英語表記 日本語表記 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 認証方法 85 英語表記 日本語表記 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 認証タイム スタンプ 86 クレーム対応アプリケーションとは 87 「認証の分離」とその限界 多くのアプリケーションが「認証」を分離してきたが… アプリケーション こ れ ま で の 方 式 アプリケーション 88 「認証分離」の限界 • • • • 認証プロトコルの違い Identity 管理ポリシーの違い アプリケーション側の対応 Single Sign-On/Off への適用 Active Directory 情 報 OpenLDAP 情 報 プ ロ ト コ ル 情 報 プ ロ ト コ ル 強い絆 プ ロ ト コ ル 情 報 の 整 形 情 報 の 解 釈 アプリ1 強い絆 プ ロ ト コ ル 情 報 の 整 形 情 報 の 解 釈 アプリ2 89 解決への考察 • フェデレーション信頼による素結合 • STS によりアプリケーション側の処理を削減 • 情報はセキュリティトークンに格納して受け渡し プ ロ ト コ ル 情 報 の 整 形 プ ロ ト コ ル 情 報 の 解 釈 アプリ1 STS フェデレーション信頼 STS 情 報 情 報 プ ロ ト コ ル STS OpenLDAP プ ロ ト コ ル STS Active Directory 情 報 プ ロ ト コ ル 情 報 の 整 形 プ ロ ト コ ル 情 報 の 解 釈 アプリ2 90 AD FS 2.0 と WIF の役割 • AD FS 2.0 がユーザーのロールを管理 • アプリケーションは受け取ったロールを解釈するだけ WIF AD FS 2.0 信頼 STS プ ロ ト コ ル STS Active Directory 情 報 プ ロ ト コ ル 情 報 の 整 形 プ ロ ト コ ル 情 報 の 解 釈 アプリ1 WIF:Windows Identity Foundation 91 認証/ロール管理からの分離 アプリケーション こ れ ま で の 方 式 ク レ ー ム に 対 応 アプリケーション アプリケーション 92 WIF アプリケーションの構造 • WIF (Windows Identity Foundation) を使用して セキュリティー トークンからクレームを取り出す • WIF は WS-Federation/WS-Trust をサポート ロールは既にトークンに セットされているので 評価するだけでOK AD FS 2.0 ASP.NET Windows Identity Foundation .NET Framework 4 クレームの評価 ロール判定 各種処理 ブラウザー 93 クレームの構造と識別方法 Microsoft.IdentityModel.Claims http://msdn.microsoft.com/ja-jp/library/microsoft.identitymodel.claims.aspx これらの値で クレームを識別する Claims Claim ClaimType Claim Value Claim Issuer Claim OriginalIssuer ValueType subject 94 サポートされているプロトコルとトークン形式 AD FS 2.0 WIF • パッシブ SAML WebSSO – SAML 2.0 トークン • パッシブ WS-Federation – SAML 1.1 トークン • アクティブ WS-Trust (CardSpace 対応含む) – SAML 2.0 トークン – SAML 1.1 トークン 95 まずは オンプレミスの IIS に展開してみる クレーム対応アプリケーションの作成と展開 ~ オンプレミス 編 1. 2. 3. 4. 5. 展開先サーバーの準備 開発環境の準備 アプリケーションの開発 AD FS 2.0 との信頼関係確立 アプリケーションの展開 96 実施手順 1. 展開先サーバーの準備 ① アプリケーション展開先の IIS をセットアップ 済 a. IIS インストール b. WIF ランタイム c. WIF SDK ② 自己署名証明書の作成 ③ SSL を有効にする ④ アプリケーションプールを作成 2. 開発環境の準備 ① Visual Studio のインストール 済 ② Windows Identity Framework ランタイム のインストール 済 ③ Windows Identity Framework SDK のインストール 済 ④ WIF対応アプリケーション用テンプレートを複製 3. アプリケーションの開発 ① Visual Studio 起動 ② “Claims-Aware ASP.NET” テンプレートを選択 ③ AD FS 2.0 との信頼関係を確立 a. アプリケーション側の作業 ④ コーディング 4. アプリケーションの展開 ① IIS にアプリケーションを発行 ② AD FS 2.0 との信頼関係を確立 a. AD FS 2.0 側の作業 97 クレーム対応アプリケーションの作成と展開~ オンプレミス 編 展開先サーバーの準備 98 展開先サーバーの準備 ~ 自己署名証明書の作成 99 展開先サーバーの準備 ~ SSL を有効にする 100 展開先サーバーの準備 ~ アプリケーションプールの作成 101 クレーム対応アプリケーションの作成と展開~ オンプレミス 編 開発環境の準備 102 事前にインストールしておくもの Windows 7 + Visual Studio 2010 の場合 • Windows Azure Tools for Microsoft Visual Studio 1.2(2010年6月) – VSCloudService.exe – VSCloudService.VS100.ja-jp.msi (言語パック) ※Windows Azure SDK 1.2 も一緒にインストールされます • Windows Identity Foundation 3.5 ランタイム 日本語版(KB974495) – Windows6.1-KB974405-x64j.msu • Windows Identity Foundation 3.5 日本語版 – WindowsIdentityFoundation-SDK-3.5.msi • Windows Identity Foundation 4.0 英語版 – WindowsIdentityFoundation-SDK-4.0.msi • Microsoft CAPICOM 2.1.0.2 SDK ※自己署名証明書を作成する場合に必要 103 WIF対応アプリケーション用テンプレートを複製 %Program Files(x86)%\Windows Identity Foundation SDK\v4.0\Visual Studio Extensions\10.0 ├ ├ ├ └ csClaimsAwareASPNETSite.zip csClaimsAwareWCFSite.zip csSTSASPNETSite.zip csSTSWCFSite.zip コピー <マイドキュメント>\Visual Studio 2010\Templates\Project Templates\Visual C# WIF を使用するための テンプレートが追加される 104 クレーム対応アプリケーションの作成と展開~ オンプレミス 編 アプリケーションの開発 105 管理者として VS を実行 OR 106 “Claims-Aware ASP.NET” テンプレートを選択 [ファイル]-[新規作成]-[Webサイト] [Visual C#] を選択 IIS 7.5 では FPSE が使えないので とりあえずローカルに作成 あとでIISに発行する 107 Claims-Aware ASP.NET テンプレート の外観 108 Claims-Aware ASP.NET テンプレートの Web.config(抜粋) <add name="ClaimsPrincipalHttpModule" type="Microsoft.IdentityModel.Web.ClaimsPrincipalHttpMo dule, Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" preCondition="managedHandler“ /> 109 Claims-Aware ASP.NET テンプレートの default.aspx.cs(抜粋) IClaimsPrincipal claimsPrincipal = Page.User as IClaimsPrincipal; IClaimsIdentity claimsIdentity = ( IClaimsIdentity )claimsPrincipal.Identity; (略) foreach ( Claim claim in claimsIdentity.Claims ) { newRow = new TableRow(); newClaimTypeCell = new TableCell(); newClaimTypeCell.Text = claim.ClaimType; newClaimValueCell = new TableCell(); newClaimValueCell.Text = claim.Value; newRow.Cells.Add(newClaimTypeCell); newRow.Cells.Add(newClaimValueCell); } claimsTable.Rows.Add(newRow); 今回はこのコードを そのまま使います 110 customErrors mode=“0ff” デバッグしやすいように以下の対応をしておきましょう 111 クレーム対応アプリケーションの作成と展開~ オンプレミス 編 AD FS 2.0 との信頼関係確立 112 AD FS 2.0 との信頼関係について 「信頼」とは何か? 物理的には メタデータ/証明書/暗号化キーを事前に交換 お互いの「すり替わり」を防止 データの横取りを防止 IdP/CP Metadata URI 信頼 RP/SP Metadata URI 精神的には IdP 側 の Identity/Role 管理責任を信頼 RP 側の クレーム管理責任を信頼 113 「アプリケーション側」の設定 ① プロジェクトを右クリック - [STS 参照の追加] 「AD FS 2.0 のメタ データを取り込む」 114 「アプリケーション側」の設定 ② フェデレーションユーティリティ が起動する 展開後のアプリケーションのURL 115 「アプリケーション側」の設定 ③ 「既存のSTSを使う」に AD FS 2.0 のメタデータを指定する 指定するのはNLBクラスターのホスト名 https://tfadfs.tf.com/~ 「https://tfadfs.tf.com/」まで入力 してクリックすると自動的に補完 116 「アプリケーション側」の設定 ④ 今回は自己発行証明書 なので「チェックしない」 117 「アプリケーション側」の設定 ⑤ IIS のSSL証明書が使われる 118 「アプリケーション側」の設定 ⑥ AD FS 2.0 のメタデータに記載されている、「必須な」「使用可能な」 クレームタイプの一覧が表示される AD FS 2.0 で用意された FederationMetadata.xml(抜粋) AD FS 側の都合で変更 される可能性がある 119 「アプリケーション側」の設定 ⑦ AD FS 2.0 のメタデー タを定期的に取り込む かどうかを指定する 120 「アプリケーション側」の設定 ⑧ STS参照追加後のプロジェクト アプリ自身のメタデータが生成される AD FS 2.0 側に取り込む必要がある ※ AD FS 2.0 のメタデータではない 取り込んだ AD FS 2.0 用メタデータをもとに、 AD FS 2.0 と通信し認証/承認 するための 定義が大量に追記されている 121 クレーム対応アプリケーションの作成と展開~ オンプレミス 編 IIS にアプリケーションを展開 122 IIS にアプリケーションを発行 ① (注意) この操作ではファイルがコピーされるだけ。 別途IIS上でアプリケーションの設定が必要 123 IIS にアプリケーションを発行 ② ( IIS 側での操作) 発行したファイルをアプリケーションに変換する Visual Studioから複 製したファイル群 124 IIS にアプリケーションを発行 ③ 事前に作成しておいたアプリ ケーションプールを選択する アイコンに注目 125 アプリとの信頼関係の確立(AD FS 2.0 側) ① 証明書利用者信頼(RP/SP)の登録 [AD FS 2.0 管理コンソール] - [AD FS 2.0] - [信頼関係] - [証明書利用者信頼] を右クリックして [証明書利用者信頼の追加] を選択 126 アプリとの信頼関係の確立(AD FS 2.0 側) ② 発行したアプリケーションの FederationMetadata.xml ファイルのフルパ スを指定する 127 アプリとの信頼関係の確立(AD FS 2.0 側) ③ ホストしているサーバー名とアプリケーショ ン名が分かるようにしてあると吉 「発行承認規則」(後述)の初期値。 最初は制限を付けないほうが良い。 128 アプリとの信頼関係の確立(AD FS 2.0 側) ④ 129 実行してみる AD FS 2.0 側ではクレームの定義を何もしていないため、既 定のクレームのみが表示されている • 認証メソッド • 認証日時 130 エラーが出たら ① HTTP エラー 500.21 - Internal Server Error ハンドラ "PageHandlerFactory-Integrated" のモジュール リストにあるモジュール "ManagedPipelineHandler" が正しくありません。 可能性のある原因: ASP.NET がインストールされていないか、完全にインストールされていません。 構成に誤字があります。 不適切な必須条件評価が存在します。 不明な属性です <compilation debug="true" targetFramework="4.0"> <assemblies> </assemblies> </compilation> 対処法:ASP.NET 4.0 を登録する x86 C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i x64 C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i 131 エラーが出たら ② 対処法:作成したアプリケーションのアプリケーションプールの設定を変更する TRUE に設定 132 いままでの知識を総動員 クレーム対応アプリケーションの作成と展開 ~ クラウド 編 1. 2. 3. 4. Windows Azure の準備 Windows Azure 用アプリケーションの作成 Windows Azure に展開 AD FS 2.0 に登録 133 クレーム対応アプリケーションの作成と展開~ クラウド 編 WINDOWS AZURE の準備 1. 2. 3. サービスの新規作成 自己署名証明書の準備 証明書の登録 134 サービスの新規作成~ サービスの新規作成 135 サービスの新規作成 ~ 作成するサービスの選択 今回は「Hosted Services」を選択 136 サービスの新規作成 ~ Service Label を指定 サービスの識別名です。わかりやすい名前にしましょう。 137 サービスの新規作成 ~ 公開URL とデータセンターを指定 http://■ ■ ■ ■ ■ ■.cloudapp.net/ 138 サービスの新規作成 ~ サービスの初期状態 139 自己署名証明書の準備 ~ Windows Azure で使用する証明書とは 参考 http://blogs.technet.com/b/junichia/archive/2010/09/02/3353275.aspx • サブスクリプション証明書(.cer) – サービス管理 API(SMAPI)へのアクセスに使用 – X.509 V3(.CER)に対応し、最低 2048 bit キー を持っている • サービス証明書(.pfx) – サービスへの SSL 通信に使用 – thumbprint によってアプリケーションと対応付け いずれも自己署名証明書を利用可能 140 (参考)Windows Azure へのアクセス経路 • Upload Application • Manage Admin 証 明 書 Windows LiveID Subscription Service Management Portal Service Management API(SMAPI) Load Balancer End User Storage Account Hosted Service Tenant Compute Node Role Instance SAK Storage Node blob table queue Drives Controller Controller Fabric 141 (参考)SSL 通信と証明書管理 SSL REST 発行 SMAPI Compute Node GA SSL Root FA SSL Guest Storage Node SAK 格納 FA Hypervisor PKCS12 PKCS12 Controller 内部通信に使用される 外部ーFCとの通信に使用 Fabric Controller 発行 Microsoft CA 142 自己署名証明書の準備~ [FAQ] 証明書の主体について http://blogs.technet.com/b/junichia/archive/2010/09/03/3353536.aspx Windows Azure 上に展開されるアプリケーショ ンの FQDN は… xxxxxxxx.cloudapp.net マイクロソフト所有のドメイン… ということは… xxxxxxxx.cloudapp.net で 証明書を取得することはできない CNAME を使用して証明書を取得する必要がある ※今回は自己署名証明書を使用します 143 自己署名証明書の準備 ~ 証明書の登録場所 サブスクリプション アカウント import サービス tf.cloudapp.net import サブスクリプション 証明書(.cer) サービス証明書 (.pfx) サービス xxxx.cloudapp.net サービス yyyy.cloudapp.net 144 自己署名証明書の準備~ 自己署名証明書の作成 1. Visual Studio をインストールしたマシンにログオン 2. [スタート]-[すべてのプログラム]-[Microsoft Visual Studio 2010]-[Visual Studio Tools]-[Visual Studio コマンドプロンプト] を起動 3. 証明書(.cer)ファイルとプライベートキーファイル( .pvk)ファイルを作成 makecert -r -pe -n "CN=tf01.cloudapp.net" -sky exchange “tf01.cloudapp.net.cer" -sv “tf01.cloudapp.net.pvk" 4. .pvk と .cer から .pfx ファイルを作成する pvk2pfx -pvk "sydneytest.cloudapp.net.pvk“ -spc “tf01.cloudapp.net.cer“ -pfx “tf01.cloudapp.net.pfx“ -pi <パスワード> 5. .cer と .pfx ファイルを Windows Azure にインポートする 145 証明書の登録~ サブスクリプション証明書の登録(.cer) 146 証明書の登録~ サービス証明書の登録(.pfx) 147 クレーム対応アプリケーションの作成と展開~ クラウド 編 WINDOWS AZURE 用アプリケーションの作成 148 アプリケーションの開発 ~ テンプレートの選択 149 アプリケーションの開発 ~ ロールの指定 ワーカーロールとWebロールの違いについての詳細は以下を参照 Windows Azure Platform の概要 http://technet.microsoft.com/ja-jp/cloud/gg236628.aspx 150 アプリケーションの開発 ~ Windows Identity Foundation への参照追加 .NET から Microsoft.IdentityModel を追加する 151 アプリケーションの開発 ~ Microsoft.IdentityModel モジュールの複製設定 一緒にアップロード Windows Azure で用意されている Windows Server には WIF がインストール されていない。 そこで、Microsoft.IdentityModel をAzure 上でも使用できるよう、パッケージ の中に組み込んでおく必要がある。 パッケージ Microsoft.IdentityModel 152 アプリケーションの開発 ~ SSL の設定 ① SSL を使用する場合には、サービス証明書へのポインター(Thumprint)を 設定しておく必要がある thumbprint 153 アプリケーションの開発 ~ SSL の設定 ② 154 アプリケーションの開発 ~ SSL の設定 ③ 識別名なので 何でもよい このまま サービス証明書 の Thumbprint 証明書の識別名 155 アプリケーションの開発~ STS 参照の追加 ① 自分自身の公開後の URLを指定する 156 アプリケーションの開発~ STS 参照の追加 ② オンプレミスの場合と 同じ 157 アプリケーションの開発~ STS 参照の追加 ③ 158 アプリケーションの開発~ Web.config の編集 ① サービス証明書の Thumbprint を追記する <serviceCertificate> <certificateReference x509FindType="FindByThumbprint" findValue=“<THUMBPRINT>"/> </serviceCertificate> 159 アプリケーションの開発~ Web.config の編集 ② <configuration><system.web> に以下を追記 • <customErrors mode=“off” /> • <httpRuntime requestValidiationMode=“2.0” /> 160 アプリケーションの開発~ ちょっとだけコーディング(?)① 今回は、オンプレミスに展開したアプリケーションのコードを流用 • Default.aspx のソースの修正 Claims-Aware ASP.NET テンプレートで提供されている Default.aspx のコード部を、 作成中の Default.aspx に上書きでコピペして、以下の通り修正 ちょっとだけ修正 <%@ Page Language=“C#” AutoEventWireup=“true” CodeBehind=“Default.aspx.cs” Inherits=“WebRole1._Default” validateRequest="false" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> (略) </html> 161 アプリケーションの開発~ ちょっとだけコーディング(?)② • Default.aspx.cs のソースを「注意しながら」修正 public partial class _Default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { (略) } } using Microsoft.IdentityModel.Claims; 挿 入 Claims-Aware ASP.NET テンプレートのソース 追記 namespace WebRole1 { public partial class _Default : System.Web.UI.Page { protected void Page_Load(object sender, EventArgs e) { } } } 162 アプリケーションの発行方法 今回はこちらの 2通りの発行方法 方法を使用する • Visual Studio から直接発行する • パッケージファイルを保存して、ポータルサイトからアップする ここまでは 開発者の仕事 展開するのは ITPROの仕事 deploy 直接発行 アップロード .cspkg .cscfg Windows Azure Portal 163 アプリケーションの開発~ サービスパッケージを作成 IIS への発行とは少し異なります インフラ担当者は、今後パッケージの展 開を依頼されることがあるはずです その場合にはこの方法を使用します。 164 アプリケーションの開発~ サービスパッケージをアップロード .cspkg を指定 .cscfg を指定 165 Deploy が完了するまで 15分~20分 166 167 メタデータへの接続を確認 アップロードが完了してステータスが「Ready」になったら、以下に接続し て表示されることを確認してみましょう。 https://tf01.cloudapp.net/FederationMetadata/2007-06/FederationMetadata.xml 168 AD FS 2.0 への登録 ① 今度は Windows Azure に展開したアプリ ケーションを、AD FS 2.0 に登録します。 前ページのメタデータ のURLを指定する 169 AD FS 2.0 への登録 ② 見分けがつきやすい 表示名を指定する 170 AD FS 2.0 への登録 ③ 171 実行テスト https://tf01.cloudapp.net/ 172 WIF アプリケーションとSSOの仕組み クラウド上に Identity 情報を用意せずに、 クレームによるアクセス承認が可能 WIF 7 3 8 クラウド オンプレミス AD DS AD FS 2.0 5 4 1 2 WIF:Windows Identity Foundation 6 173 WS-Federation (Passive SSO) の流れ 1. オンプレミスの AD DS にログオン依頼 2. AD DS からクレデンシャルが送信されクライアントに保存 -----------3. Windows Azure 上のアプリケーションにアクセス 4. クレーム ポリシーをアプリケーションから受け取り、 STS (AD FS 2.0) にリダイレクト 5. 属性ストアである AD DS からクレームを収集 6. 集めたクレームに署名をしてセキュリティトークンを生成 し、Windows Azure アプリケーションに送信 7. アプリケーションはセキュリティトークンを受け取り、 Windows Identity Foundation (WIF) を使用してクレーム を取り出し、評価する 8. 画面がブラウザーに送られる 174 AD FS 2.0 をもっと使いこなすために AD FS 2.0 DEEP DIVE 1. 2. 3. クレームパイプラインと要求規則(クレームルール) カスタムルールの定義 AD FS 2.0 の監査 175 用語について 基本的に、日本語 UI に沿った用語を使用します。 が…ちょっとアレなところもあるので、以下の対応票を参考にしてください。 日本語 対応する英語 要求 Claim, クレーム 規則 Rule, ルール 要求の種類 Claim Type, クレームタイプ 要求記述 Claim Description, クレームディスクリプション 要求 プロバイダー Claims Provider, クレーム プロバイダー 証明書利用者 Relying Party, リライング パーティ 発行承認規則 Issuance Authorization Rules 受付変換規則 Acceptance Transform Rules 発行変換規則 Issuance Transform Rules 176 AD FS 2.0 Deep Dive クレームパイプラインと要求規則(クレームルール) 177 要求規則 (Claim Rule) • 入力された情報をルール (規則) に沿って処理し出力する • 処理されたクレームは既定のパイプラインを通る 要求規則 他の要求 プロバイダー AD DS AD LDS LDAP SQL Server その他 入力方向の要求 LDAP 属性 メンバーシップ カスタム クレーム スルー 変換 出力 フィルター 178 要求規則セット (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 で実装する。 179 AD FS 2.0 ~クレーム パイプライン 証明書利用者 (RP) クレームストア 要求プロバイダー信頼 (Claims Provider Trusts) OK/ NG output 発行 変換 規則 input 発行 承認 規則 output 受け 付け 変換 規則 input ③ 発行する output ② 承認する input ① 受付ける トークン switch 証明書利用者信頼 (Relying Party Trust) 要求規則 (Claim Rule) 180 ① 受付ける 受け付け変換規則 • 「要求プロバイダー信頼」で設定する • 「証明書利用者信頼」に渡すためのクレームをセットする 大原則① ここで定義されたクレームのみが、 パイプラインに沿って「証明書利 用信頼」に渡される 181 ② 承認する 発行承認規則 • 「証明書利用者信頼」で設定する • 「発行変換規則」に移行させるかどうかを判断 • クレームは発行しない この設定では「受け付け変換規則」 を通過したユーザー全てに、「発行 変換規則」への進行を許可 182 ③ 発行する 発行変換規則 • 「証明書利用者信頼」で設定する • 以下を最終決定する • ユーザーにセキュリティトークンを発行するかどうか • RP/SP にどんなクレームを送信するか 規定では空(何も発行しない) ただし、「認証メソッド」と「認 証日時」だけは送信される 183 クレームルールを定義するには? • 要求規則テンプレートを使用 • 規定で用意されているルールを使用する場合 • • • • • • • [LDAP 属性を要求として送信] [グループ メンバーシップを要求として送信] [入力方向の要求を変換] [入力方向の要求をパススルーまたはフィルター処理] [カスタム規則を使用して要求を送信] [入力方向の要求に基づいてユーザーを許可または拒否] [すべてのユーザーを許可] • カスタムルールを定義 • 用意されていないルール(ロジック)を使用する場合 • 用意されていない ldap 属性を使用する場合 • AD DS/ldap 以外のクレームストアを使用する場合 • SQL Server • その他(テキストファイル など) and くどいようですが… [要求記述]に記載されていないクレームタイプは使用できないので、事前に 定義しておく必要がある 184 (参考)既定の 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) Is-Member-Of-DL (memberOf) Organizational-Unit-Name (ou) Organization-Name (o) Proxy-Addresses (proxyAddress) Token-Groups - 完全修飾ドメイン名を含 む(tokenGroups) Token-Groups - 名前の指定なし (tokenGroups) User-Principal-Name (userPrincipalName) SAM-Account-Name(sAMAccountName) 185 クレームルールを定義する 例1 • エバンジェリスト属性を持ったユーザーにのみトークンを発行する • 以下の ldap 属性をクレームとして送信する ldap 属性 クレームタイプ 氏名 displayname 名前 メール email 電子メール アドレス 部署 department 部署 役職 title 役割 規定で用意されない ため「要求記述」に 定義する必要がある 作業手順 ① 要求記述に「役割」を追加 ② 「発行承認規則」で「エバンジェリスト」以外を抑止 ③ 「発行変換規則」で上記4つのクレームを定義する 186 クレームルールを定義する ① 要求記述の定義(「部署」を追加) クレームタイプ を URI で設定する。 世界で唯一にするため、自社ドメ イン名を入れるとよい。 187 ②「発行承認規則」(「エバンジェリスト」以外を抑止) 「すべてのユーザーにアク セスを許可」を削除 188 「LDAP属性を要求として送信」を選択 Active Directory の属性「title」 を 「役割」に放り込む 189 さらに規則を追加する 「入力方向の要求に基づいてユーザーを許 可または拒否」を選択 190 クレーム「役割」が「エバンジェリスト」 ならば… 条件に合致したユーザーのみを「許可」 191 要求規則 の処理プロセスについて 前のルールの結果が次のルールに引き継がれる クレーム 要求規則セット Input Claim Set 条件 Output Claim Set 要求規則1 発行 要求規則2 要求規則 n トークン 192 ③「発行変換規則」で4つのクレームを定義 ldap 属性 クレームタイプ 氏名 displayname 名前 メール email 電子メール アドレス 部署 department 部署 役職 title 役割 193 LDAP属性を要求して送信 複数の ldap 属性を一度に定義 可能 194 完成形 195 実行結果例 役割が「エバンジェリスト」 でなければアクセス拒否 196 クレームルールの定義 ありがちなミス ① 現象 • 「発行承認規則」で[入力方向の要求に基づいてユーザーを許可また は拒否] ルールを使用し、クレーム名[役職] に「部長」と書かれてい るユーザーのみに許可したいが、全てのアクセスが拒否されてしまう 原因 • [役職] クレームの中身がからっぽ。 「受け付け承認規則」で [役職] クレームが定義されていない場合、 「発行承認規則」でいきなり[役職]クレームによる条件判定を行おう としても、クレームの中身が空のため判定は「NG」となる。事前に、 [役職]クレームに値を入力するルールが定義されている必要がある。 ここでクレームを評価する以前に、クレーム が発行されていない場合、「空」の値が入っ ているものとして評価されてしまう 発行 変換 規則 output OK/ NG input 発行 承認 規則 output input output input 受け 付け 変換 規則 197 クレームルールの定義 ありがちなミス ① 現象 • ルールを変えても送信されるクレームが変わらない 原因 • デスクトップ上に別のブラウザやタブが起動しており、既にクレーム を取得している こいつを閉じ ないと…. 同じクレーム が表示される 198 クレームルールの定義 ありがちなミス③ 現象 • 「入力方向の要求をパススルーまたはフィルター処理」ルールを使用して、 「特定の電子メール フィックスの値と一致する要求値だけをパス スルーす る」を定義しているが、サフィックスが一致しないユーザーに対してもクレー ムが発行されてしまう。 原因 • クレームルールに複数のルールを定 義しており、当該ルール以前に電子 メールアドレスクレームを発行して いる場合、それを取り消すことはで きない。 対処 • 当該ルール以前のルールから電子 メールアドレスの発行ルールを削除 する 上で発行して しまうと… それ以降でフィル ターすることはで きない 199 AD FS 2.0 Deep Dive カスタムルールの定義 200 カスタムルールのサンプルを見るには 201 条件部 発行部 202 カスタムルールの構造 発行部 条件部 条件文 1 && && 条件文 2 True => 発行文 False 条件部 入力方向のクレーム/属性をチェックし、 オプション すべての条件が True の場合に「発行部」が実行される。 条件部が無い場合には無条件で True とみなされる。 発行部 発行するトークンタイプと、 そこに格納する属性/値を指定する。 必須 「クレームが発行されない」 ≠ アクセスできない ※クレームを持っていないユーザーにアクセスを許可するかどうかは アプリケーションの判断 203 書式の基本 ① • 無条件でクレーム「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”); 204 書式の基本 ② • クレーム「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)に相当する演算子は用意されていない 205 書式の基本 ③ ~ 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“ • store = "Active Directory“ ”Active directory”というクレームストアから 属性を取ってくる 発 持ってくる属性は「logonCount」で、 行 • query = “;logonCount,{0}“ ADを検索する条件は windowsaccountname = {0} 部 {0} の値は条件部で渡された • param = c.Value WindowsAccountName の値 206 カスタムルール活用のコツ ① 正規表現の利用 • (例1)クレーム「A」の値が大文字小文字を問わず「[email protected]」と完 全一致ならばクレームを発行する c:[Type == “A”, Value =~ “^(?i)junichia@tf\.com$” ] => issue(claim = c); ^(?i)junichia@tf\.com$ 行頭(これ より前に文 字が無いこ と)を示す 行末(これより後 ろに文字が無いこ と)を示す 後に続く文字の大文字 小文字を区別しない 特殊な文字の前には 「\(バックスラッ シュ)」を付加 正規表現言語要素 http://msdn.microsoft.com/ja-jp/library/az24scfc.aspx 207 カスタムルール活用のコツ ② 正規表現の利用 • (例2)クレーム「A」の値が 2 ケタの数字ならば、クレーム「B」に 「JUNIOR」を入れて発行する [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 208 カスタムルール活用のコツ ③ ファンクションの活用 • 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}")); 209 発行ステートメントについて • issue:クレームを発行する(output claim set に発行する) • add :input claim set に直接発行する → クレーム発行のためのテンポラリー領域的な使い方 クレーム 要求規則セット add ステートメント は output クレーム を発行しない => add (type = “title”, value = “部長"); title = “部長” 要求規則2 [type == “title”, Value == “部長”] => issue (type = "Role", value = “Manager"); role=“M anager” Output Claim Set Input Claim Set 要求規則1 210 カスタムルールを定義する 例2 • 役割が「エバンジェリスト」にのみトークンを発行する • ユーザーのアクティブ度(笑)をログオン回数から判定し、回数に応じ た Status 与える(アプリケーション側では Status に応じて表示する メニューを変える) • 以下のクレームを送信する ldap 属性 クレームタイプ 氏名 displayname 名前 メール email 電子メール アドレス 部署 department 部署 役職 title 役割 ログオン回数 logonCount ログオン回数 ステータス ー ステータス 規定で用意されない ため「要求記述」に 定義する必要がある 作業手順 ① 要求記述に「ログオン回数」と「ステータス」を追加 ② 「発行変換規則」で「ログオン回数」と「ステータス」を定義 211 カスタムルールを定義する 要求記述の定義(「ログオン回数」) クレームタイプ を URI で設定する。 212 カスタムルールを定義する 要求記述の定義(「ステータス」) クレームタイプ を URI で設定する。 213 カスタムルールを定義する 「ログオン回数」と「ステータス」を定義 214 logonCount 属性を「ログオン回数」にセット Active Directory から logonCount 属性を取り出し、クレームタイプ logoncount に入れている 215 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“ ) ; 216 完成形 ルールは上から実行される 6 userstatusクレームを発行する <要求規則の表示> 217 AD FS 2.0 DEEP DIVE AD FS 2.0 の監査とトレース 218 トレースログを表示するには [イベント ビューアー] - [アプリケーション と サービスログ] - [AD FS 2.0] を右クリックして [表示]-[分析およびデバッグログの表示] をチェック 219 トレースログを有効にする 220 まとめ 221 AD FS 2.0 をうまく使うには AD FS 2.0 はLOBのアーキテクチャを一新するテクノロジーです • ビジネスの方向性を見据えた設計を • AD FS 2.0 はオープンなアーキテクチャ • 企業間、組織間、異種プラットフォーム間の 相互運用も射程内にある • SaaS の選定も慎重に (クレームベースの認証が可能か?) • LOB のアーキテクチャに口出ししましょう • 認証/ロール管理を今後どうするか? • 企業全体での ID 管理の仕組みは? • AD FS 2.0 のアーキテクチャにも注目を! • Microsoft Online Service との連携 • AppFabric Access Control Service との連携 • 他社テクノロジーとの連携 222 STS は AD FS だけじゃない • AppFabric Access Control Service(ACS)との連携 信頼 信頼 ACS STS 信頼 信頼 STS AD DS AD FS 223 (参考)新しい ACS は夢が広がる IdP/CP RP/SP REST クラウド ACS V2 WIF AD FS 2.0 オンプレミス AD DS AD FS 2.0 REST WIF 224 © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. 225
© Copyright 2024 ExpyDoc