Your SlideShare is downloading. ×
Microsoftの認証システムの歴史と過渡期におけるWAPの活用+Next Generation Credentials
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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

266
views

Published on

Japan SharePoint Group 2015/03/14で使ったネタ。 …

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

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

Published in: Technology

0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
266
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

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サーバに委任設定