Transcript AD FS 2.0 のセットアップ

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 上に展開
途中、操作をお手伝いいただくこともあります。
３.5時間～４時間を要しますが、根性でのりきりましょう！
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
②Token発行
クレームストア
AD FS 2.0
WIF
Application
クレーム
ストア
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