Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Microsoftの認証システムの歴史と
過渡期におけるWAPの活用
+Next Generation Credentials
2015.03.14
Naohiro Fujie(MVP for Forefront Identity Manage...
自己紹介
Blog
◦ IdM実験室(Identityに関することを徒然と):http://idmlab.eidentity.p
Social
◦ Facebook Page : eIdentity(Identityに関するFeed):http...
Microsoftの認証システムの歴史とこれから
統合Windows認証
(Windows95/NT-Current)
• LM⇒NTLM⇒NTLMv2⇒Kerberos
• WindowsPC、Windowsアプリ、
Webアプリ(IE)
I...
統合Windows認証/NTLM
Challenge - Response
個別認証
4
出展:@IT
http://www.atmarkit.co.jp/fsecurity/hybooks/win_server_sec/ws
s01-01...
統合Windows認証/Kerberos
Ticketベース
認証情報の引継ぎ
5
Web/DBアプリへのログオン例
出展:日経ITPro
http://itpro.nikkeibp.co.jp/article/COLUMN/2006051...
Identity Federation(ID連携)
トークン(XML/JSON)ベース
認証情報を含むID情報を安全に
受け渡すための仕組み
6
同列ではない(認証⇒ID連携)
方式 特徴 認証範囲 利用シナリオの例
NTLM 単なる認証の方法
(ID/PWDの検証方法)
認証システムとアプリ
ケーションの間のみ
PCへのログイン
アプリへのログイン(個別ログイン)
Kerberos 認...
過去の資産との付き合い方
IT環境の変化
◦ クラウドの活用 ⇒ 境界の変化(ネットワーク境界を超えるIT利用)
◦ デバイスの変化 ⇒ 非ドメインクライアント(BYOD、スマホ、タブレット)
既存インフラはついていけるのか?
◦ 過去に構築し...
ドメイン(レルム)の範囲
Federation信頼の範囲(Circle of Trust)
PCログイン時に取得した
Kerberosチケットの有効範囲
ブラウザでログイン時に取得した
トークンの有効範囲
AD FSの役割はKerberosチケ...
Demo
WAPを使い、非統合Windows環境よりSSOする
10
デモ環境
11
Kerberos認証する様に構成したアプリケーション
• SharePoint Central Administration
• Microsoft Identity Manager 2015 ドメイン参加した
WAPとAD F...
前提事項(そしてはまりポイント)
そのアプリ、本当にKerberosで構成されている?
Kerberos Authentication Tester ver.0.9.3(beta)で事前にチェック。
http://blog.michelbarn...
まとめ①
WAPは単なるAD FS専用のリバプロじゃない
既存アプリをクラウドへ持っていく前の過渡期に活用できる
(かも)
対象アプリのKerberos構成の事前確認が大事
13
これからの話
Next Generation Credentials(NGC)と
Cloud Domain Join(CDJ)
14
【ご注意】
現在公開されている情報、および個人的な試行錯誤がベースと
なっているため、勘違いや今後の仕様変更な...
Next Generation Credentials(NGC)
◆課題
真のSSOへの道は険しい⇒非ドメイン環境でのデバイスログインとブラウザログイン
パスワードをいつまで使い続けるのか
15
◆クレデンシャルに関する議論
⇒パスワード
...
Next Generation Credentials(NGC)
基本的な考え方/特徴は以下の通り
秘密鍵と公開鍵のペア
秘密鍵はデバイスに残さない
秘密鍵はTPMで保護される
サーバは公開鍵を持つ
クライアントが秘密鍵で署名し、サー...
Cloud Domain Join(CDJ)
Windows 10 Technical Preview 9926より利用可能
NGCを利用
Azure Active Directoryへドメイン参加(デバイス登録)
Azure ADアカウ...
Demo
Windows10 TP 9926へAADアカウントでログインする
18
ステップ
1. デバイス登録
2. 鍵の生成と登録
3. ユーザ認証
4. アクセストークンの要求
19
セットアップ・フェーズ
認証・フェーズ
デモ
ステップ①:デバイス登録
20
• AzureADのDRS(Device Registration Service)へ
デバイス登録を試行
• AzureADの認証サービスでユーザ認証(MFAも利用
可能)し、DRSへのアクセストークンを受け取...
ステップ②:鍵の生成と登録
21
• Windows10デバイス側でユーザ鍵ペア、デバイス
鍵ペアを作成し、ユーザとデバイスそれぞれについ
てアテステーションblobを作成
• Azure AD鍵登録サービス(KRS)へ鍵登録要求を行
う(アク...
ステップ③:ユーザ認証
22
• AzureADの認証サービスにアクセス、NONCEを取
得する
• NONCEとNGC KEY-IDを秘密鍵で署名
• 認証要求
• プライマリ・リフレッシュトークンとアクセストー
クンを取得、対象鍵をTPMに...
ステップ④:アクセストークンの要求
23
• KsKの生成
• AzureAD認証サービスにアクセストークンを要求
(要求時、ターゲットリソース情報、Kskを送信)
• アクセストークンを返却
現状はPCログインと一部サービスしかSSO出来な
...
まとめ②
Password is dead!
やっぱりPCログインとサービスへのログインをSSOしたい
(ブラウザ/ネイティブ)
24
参考)デモ時のWAP構成
25
社内環境(統合Windows認証)
ドメインPC
SSO
26
社外/スマホ(非統合Windows認証)
遷移するとID/PWDを
聞かれる(非SSO)非ドメイン
PC/スマホ
27
WAP経由
28
AD FSで認証された
後はSSO
非ドメイン
PC/スマホ
WAP構成
29
AD FSで事前認証する形でアプリ
ケーションを公開
AD FS構成
30
証明書利用者信頼に要求に非対応
のアプリケーションとして登録
Service Principal Name構成
31
Application Pool実行ユーザに
SPNを登録
WAPサーバに委任設定
Upcoming SlideShare
Loading in …5
×

Microsoftの認証システムの歴史と 過渡期におけるWAPの活用 +Next Generation Credentials

12,642 views

Published on

Japan SharePoint Group 2015/03/14で使ったネタ。
(SharePointには全く関係なし)

WebApplicationProxyを使った非ドメインデバイスから統合Windows認証アプリへのSSOの話
+Next Generation Credentials(NGC)とWindows10のCloud Domain Join(CDJ)の話

Published in: Technology
  • Be the first to comment

Microsoftの認証システムの歴史と 過渡期におけるWAPの活用 +Next Generation Credentials

  1. 1. Microsoftの認証システムの歴史と 過渡期におけるWAPの活用 +Next Generation Credentials 2015.03.14 Naohiro Fujie(MVP for Forefront Identity Manager) IdM実験室(http://idmlab.eidentity.jp)
  2. 2. 自己紹介 Blog ◦ IdM実験室(Identityに関することを徒然と):http://idmlab.eidentity.p Social ◦ Facebook Page : eIdentity(Identityに関するFeed):https://www.facebook.com/eidentity Web記事 ◦ Windowsで構築する、クラウド・サービスと社内システムのSSO環境 (http://www.atmarkit.co.jp/fwin2k/operation/adsf2sso01/adsf2sso01_01.html) ◦ クラウド・サービス連携の基本と最新トレンド (http://www.atmarkit.co.jp/fwin2k/operation/idftrend01/idftrend01_01.html) ◦ 開発者にとってのWindows Azure Active Directoryの役割と今後の展開 (http://www.buildinsider.net/enterprise/interviewvittorio/01) その他 ◦ 日本ネットワークセキュリティ協会(JNSA)アイデンティティ管理WG (書籍:「クラウド環境におけるアイデンティティ管理 ガイドライン」etc) ◦ OpenID Foundation Japan 教育・翻訳WG(OAuth/OpenID Connect仕様翻訳)、エンタープライズ・アイデンティティWG 2
  3. 3. Microsoftの認証システムの歴史とこれから 統合Windows認証 (Windows95/NT-Current) • LM⇒NTLM⇒NTLMv2⇒Kerberos • WindowsPC、Windowsアプリ、 Webアプリ(IE) Identity Federation (WS2003R2-Current) • ws-trust / ws-federation / SAML ⇒ OpenID Connect • Webアプリ Next Generation Credentials (Azure/Windows 10-) • Device、ネイティブアプ リ、Webアプリ 3 PCの時代 Webの時代 デバイス&サービスの時代
  4. 4. 統合Windows認証/NTLM Challenge - Response 個別認証 4 出展:@IT http://www.atmarkit.co.jp/fsecurity/hybooks/win_server_sec/ws s01-01.html Web/DBアプリへのログオン例
  5. 5. 統合Windows認証/Kerberos Ticketベース 認証情報の引継ぎ 5 Web/DBアプリへのログオン例 出展:日経ITPro http://itpro.nikkeibp.co.jp/article/COLUMN/20060518/238303/
  6. 6. Identity Federation(ID連携) トークン(XML/JSON)ベース 認証情報を含むID情報を安全に 受け渡すための仕組み 6
  7. 7. 同列ではない(認証⇒ID連携) 方式 特徴 認証範囲 利用シナリオの例 NTLM 単なる認証の方法 (ID/PWDの検証方法) 認証システムとアプリ ケーションの間のみ PCへのログイン アプリへのログイン(個別ログイン) Kerberos 認証+認証結果を連携す るための仕組み ドメイン(レルム)内 のみ 同一ドメイン内のPC、アプリ間でのSSO (PCにチケットを保持、アプリアクセス 時はチケットをサービス用のチケットに 交換するので再度認証は不要) SAML ws-federation OpenID Connect 認証結果を含むID情報 を連携するための仕組み 制限なし(信頼関係 /Circle of Trustを構築 した範囲内) 同じIdPを使っているアプリ間でのSSO (ブラウザに認証Cookieを保持、別アプ リからIdPへリダイレクトされても再度認 証は不要) 7 大きく考え方が異なる
  8. 8. 過去の資産との付き合い方 IT環境の変化 ◦ クラウドの活用 ⇒ 境界の変化(ネットワーク境界を超えるIT利用) ◦ デバイスの変化 ⇒ 非ドメインクライアント(BYOD、スマホ、タブレット) 既存インフラはついていけるのか? ◦ 過去に構築した統合Windows認証のASP.NETアプリをタブレットから使うとページ 単位でIDとパスワードを聞いてくる・・・ ◦ Federationに対応させるとなるとコストが・・・ 8 一つの解としてのWeb Application Proxy
  9. 9. ドメイン(レルム)の範囲 Federation信頼の範囲(Circle of Trust) PCログイン時に取得した Kerberosチケットの有効範囲 ブラウザでログイン時に取得した トークンの有効範囲 AD FSの役割はKerberosチケットと SAMLトークンの変換(AD FSでの認証 をKerberosチケットで実施) ⇒KerberosレルムとCoTの橋渡し AD FS WAP WAPの役割はSAMLトークンと Kerberosチケットの変換 ⇒CoTとKerberosレルムの橋渡し 9 WAP:Web Application Proxy(旧AD FS Proxy) AD FS:Active Directory Federation Service
  10. 10. Demo WAPを使い、非統合Windows環境よりSSOする 10
  11. 11. デモ環境 11 Kerberos認証する様に構成したアプリケーション • SharePoint Central Administration • Microsoft Identity Manager 2015 ドメイン参加した WAPとAD FS AD FS SharePoint MIM PortalAD DS 登録 WAP リバプロ通信統合 Windows 認証 WAP経由の アプリSSO利用 (AD FS経由で認証)
  12. 12. 前提事項(そしてはまりポイント) そのアプリ、本当にKerberosで構成されている? Kerberos Authentication Tester ver.0.9.3(beta)で事前にチェック。 http://blog.michelbarneveld.nl/media/p/33.aspx ※.NET Framework 3.5が必要 12 WAPサーバで起動し、対象URLを入 れて[Test] ⇒Authentication Type:Kerberos、 SPNにWAPに設定するSPNが表示さ れていることを確認
  13. 13. まとめ① WAPは単なるAD FS専用のリバプロじゃない 既存アプリをクラウドへ持っていく前の過渡期に活用できる (かも) 対象アプリのKerberos構成の事前確認が大事 13
  14. 14. これからの話 Next Generation Credentials(NGC)と Cloud Domain Join(CDJ) 14 【ご注意】 現在公開されている情報、および個人的な試行錯誤がベースと なっているため、勘違いや今後の仕様変更などがある可能性が 非常に高いので取扱いにはご注意ください。
  15. 15. Next Generation Credentials(NGC) ◆課題 真のSSOへの道は険しい⇒非ドメイン環境でのデバイスログインとブラウザログイン パスワードをいつまで使い続けるのか 15 ◆クレデンシャルに関する議論 ⇒パスワード • 本当にその人のパスワードかどうかの保証がない • 中間者攻撃(Man in the Middle)に弱い ⇒スマートカード • 本人(持ち主)である保証の確率は比較的高い • 対応したクライアントが必要 シンプルで安全なクレデンシャルが求められている • なりすませない、傍受されない • プラットフォームを選ばない
  16. 16. Next Generation Credentials(NGC) 基本的な考え方/特徴は以下の通り 秘密鍵と公開鍵のペア 秘密鍵はデバイスに残さない 秘密鍵はTPMで保護される サーバは公開鍵を持つ クライアントが秘密鍵で署名し、サーバが公開鍵で署名確認をする FIDO、OAuth2.0 JWTの標準ベース ※tech days 2015 france & Google翻訳より http://fr.slideshare.net/DecideursIT/sec303 16
  17. 17. Cloud Domain Join(CDJ) Windows 10 Technical Preview 9926より利用可能 NGCを利用 Azure Active Directoryへドメイン参加(デバイス登録) Azure ADアカウントでPCへログイン可能 セットアップ後はパスワードを使わず、PINでログイン PCログインとアプリケーション・ログインのSSO(まだ限定的) 17
  18. 18. Demo Windows10 TP 9926へAADアカウントでログインする 18
  19. 19. ステップ 1. デバイス登録 2. 鍵の生成と登録 3. ユーザ認証 4. アクセストークンの要求 19 セットアップ・フェーズ 認証・フェーズ デモ
  20. 20. ステップ①:デバイス登録 20 • AzureADのDRS(Device Registration Service)へ デバイス登録を試行 • AzureADの認証サービスでユーザ認証(MFAも利用 可能)し、DRSへのアクセストークンを受け取り、 DRSへデバイス登録 • DRSがデバイス証明書を送り返してくるのでデバイ スに証明書をインストール
  21. 21. ステップ②:鍵の生成と登録 21 • Windows10デバイス側でユーザ鍵ペア、デバイス 鍵ペアを作成し、ユーザとデバイスそれぞれについ てアテステーションblobを作成 • Azure AD鍵登録サービス(KRS)へ鍵登録要求を行 う(アクセストークン、公開鍵などを含む) • Azire AD鍵登録サービスがNGC-KEYをデバイスへ 送り、デバイスはKGC-KEYを保持しておく
  22. 22. ステップ③:ユーザ認証 22 • AzureADの認証サービスにアクセス、NONCEを取 得する • NONCEとNGC KEY-IDを秘密鍵で署名 • 認証要求 • プライマリ・リフレッシュトークンとアクセストー クンを取得、対象鍵をTPMにインポートする
  23. 23. ステップ④:アクセストークンの要求 23 • KsKの生成 • AzureAD認証サービスにアクセストークンを要求 (要求時、ターゲットリソース情報、Kskを送信) • アクセストークンを返却 現状はPCログインと一部サービスしかSSO出来な いが、いずれOffice365などにも広がる(はず)
  24. 24. まとめ② Password is dead! やっぱりPCログインとサービスへのログインをSSOしたい (ブラウザ/ネイティブ) 24
  25. 25. 参考)デモ時のWAP構成 25
  26. 26. 社内環境(統合Windows認証) ドメインPC SSO 26
  27. 27. 社外/スマホ(非統合Windows認証) 遷移するとID/PWDを 聞かれる(非SSO)非ドメイン PC/スマホ 27
  28. 28. WAP経由 28 AD FSで認証された 後はSSO 非ドメイン PC/スマホ
  29. 29. WAP構成 29 AD FSで事前認証する形でアプリ ケーションを公開
  30. 30. AD FS構成 30 証明書利用者信頼に要求に非対応 のアプリケーションとして登録
  31. 31. Service Principal Name構成 31 Application Pool実行ユーザに SPNを登録 WAPサーバに委任設定

×