Transcript

• 1. Microsoftの認証システムの歴史と 過渡期におけるWAPの活用 +Next Generation Credentials 2015.03.14 Naohiro Fujie（MVP for Forefront Identity Manager） IdM実験室（http://idmlab.eidentity.jp）
• 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. 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. 統合Windows認証/NTLM Challenge - Response 個別認証 4 出展：@IT http://www.atmarkit.co.jp/fsecurity/hybooks/win_server_sec/ws s01-01.html Web/DBアプリへのログオン例
• 5. 統合Windows認証/Kerberos Ticketベース 認証情報の引継ぎ 5 Web/DBアプリへのログオン例 出展：日経ITPro http://itpro.nikkeibp.co.jp/article/COLUMN/20060518/238303/
• 6. Identity Federation（ID連携） トークン（XML/JSON）ベース 認証情報を含むID情報を安全に 受け渡すための仕組み 6
• 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. 過去の資産との付き合い方 IT環境の変化 ◦ クラウドの活用 ⇒ 境界の変化（ネットワーク境界を超えるIT利用） ◦ デバイスの変化 ⇒ 非ドメインクライアント（BYOD、スマホ、タブレット） 既存インフラはついていけるのか？ ◦ 過去に構築した統合Windows認証のASP.NETアプリをタブレットから使うとページ 単位でIDとパスワードを聞いてくる・・・ ◦ Federationに対応させるとなるとコストが・・・ 8 一つの解としてのWeb Application Proxy
• 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. Demo WAPを使い、非統合Windows環境よりSSOする 10
• 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. 前提事項（そしてはまりポイント） そのアプリ、本当に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. まとめ① WAPは単なるAD FS専用のリバプロじゃない 既存アプリをクラウドへ持っていく前の過渡期に活用できる （かも） 対象アプリのKerberos構成の事前確認が大事 13
• 14. これからの話 Next Generation Credentials（NGC）と Cloud Domain Join（CDJ） 14 【ご注意】 現在公開されている情報、および個人的な試行錯誤がベースと なっているため、勘違いや今後の仕様変更などがある可能性が 非常に高いので取扱いにはご注意ください。
• 15. Next Generation Credentials(NGC) ◆課題 真のSSOへの道は険しい⇒非ドメイン環境でのデバイスログインとブラウザログイン パスワードをいつまで使い続けるのか 15 ◆クレデンシャルに関する議論 ⇒パスワード • 本当にその人のパスワードかどうかの保証がない • 中間者攻撃（Man in the Middle）に弱い ⇒スマートカード • 本人（持ち主）である保証の確率は比較的高い • 対応したクライアントが必要 シンプルで安全なクレデンシャルが求められている • なりすませない、傍受されない • プラットフォームを選ばない
• 16. Next Generation Credentials(NGC) 基本的な考え方/特徴は以下の通り 秘密鍵と公開鍵のペア 秘密鍵はデバイスに残さない 秘密鍵はTPMで保護される サーバは公開鍵を持つ クライアントが秘密鍵で署名し、サーバが公開鍵で署名確認をする FIDO、OAuth2.0 JWTの標準ベース ※tech days 2015 france & Google翻訳より http://fr.slideshare.net/DecideursIT/sec303 16
• 17. Cloud Domain Join(CDJ) Windows 10 Technical Preview 9926より利用可能 NGCを利用 Azure Active Directoryへドメイン参加（デバイス登録） Azure ADアカウントでPCへログイン可能 セットアップ後はパスワードを使わず、PINでログイン PCログインとアプリケーション・ログインのSSO（まだ限定的） 17
• 18. Demo Windows10 TP 9926へAADアカウントでログインする 18
• 19. ステップ 1. デバイス登録 2. 鍵の生成と登録 3. ユーザ認証 4. アクセストークンの要求 19 セットアップ・フェーズ 認証・フェーズ デモ
• 20. ステップ①：デバイス登録 20 • AzureADのDRS（Device Registration Service）へ デバイス登録を試行 • AzureADの認証サービスでユーザ認証（MFAも利用 可能）し、DRSへのアクセストークンを受け取り、 DRSへデバイス登録 • DRSがデバイス証明書を送り返してくるのでデバイ スに証明書をインストール
• 21. ステップ②：鍵の生成と登録 21 • Windows10デバイス側でユーザ鍵ペア、デバイス 鍵ペアを作成し、ユーザとデバイスそれぞれについ てアテステーションblobを作成 • Azure AD鍵登録サービス（KRS）へ鍵登録要求を行 う（アクセストークン、公開鍵などを含む） • Azire AD鍵登録サービスがNGC-KEYをデバイスへ 送り、デバイスはKGC-KEYを保持しておく
• 22. ステップ③：ユーザ認証 22 • AzureADの認証サービスにアクセス、NONCEを取 得する • NONCEとNGC KEY-IDを秘密鍵で署名 • 認証要求 • プライマリ・リフレッシュトークンとアクセストー クンを取得、対象鍵をTPMにインポートする
• 23. ステップ④：アクセストークンの要求 23 • KsKの生成 • AzureAD認証サービスにアクセストークンを要求 （要求時、ターゲットリソース情報、Kskを送信） • アクセストークンを返却 現状はPCログインと一部サービスしかSSO出来な いが、いずれOffice365などにも広がる（はず）
• 24. まとめ② Password is dead！ やっぱりPCログインとサービスへのログインをSSOしたい （ブラウザ/ネイティブ） 24
• 25. 参考）デモ時のWAP構成 25
• 26. 社内環境（統合Windows認証） ドメインPC SSO 26
• 27. 社外/スマホ（非統合Windows認証） 遷移するとID/PWDを 聞かれる（非SSO）非ドメイン PC/スマホ 27
• 28. WAP経由 28 AD FSで認証された 後はSSO 非ドメイン PC/スマホ
• 29. WAP構成 29 AD FSで事前認証する形でアプリ ケーションを公開
• 30. AD FS構成 30 証明書利用者信頼に要求に非対応 のアプリケーションとして登録
• 31. Service Principal Name構成 31 Application Pool実行ユーザに SPNを登録 WAPサーバに委任設定