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

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

+Next Generation Credentials2015.03.14

Naohiro Fujie（MVP for Forefront Identity Manager）

IdM実験室（http://idmlab.eidentity.jp）

自己紹介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

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の時代 デバイス＆サービスの時代

統合Windows認証/NTLMChallenge - Response

個別認証

4

出展：@IThttp://www.atmarkit.co.jp/fsecurity/hybooks/win_server_sec/wss01-01.html

Web/DBアプリへのログオン例

統合Windows認証/KerberosTicketベース

認証情報の引継ぎ

5

Web/DBアプリへのログオン例

出展：日経ITProhttp://itpro.nikkeibp.co.jp/article/COLUMN/20060518/238303/

Identity Federation（ID連携）トークン（XML/JSON）ベース

認証情報を含むID情報を安全に

受け渡すための仕組み

6

同列ではない（認証⇒ID連携）方式 特徴 認証範囲 利用シナリオの例

NTLM 単なる認証の方法（ID/PWDの検証方法）

認証システムとアプリケーションの間のみ

PCへのログインアプリへのログイン（個別ログイン）

Kerberos 認証＋認証結果を連携するための仕組み

ドメイン（レルム）内のみ

同一ドメイン内のPC、アプリ間でのSSO（PCにチケットを保持、アプリアクセス時はチケットをサービス用のチケットに交換するので再度認証は不要）

SAMLws-federation OpenID Connect

認証結果を含むID情報を連携するための仕組み

制限なし（信頼関係/Circle of Trustを構築した範囲内）

同じIdPを使っているアプリ間でのSSO（ブラウザに認証Cookieを保持、別アプリからIdPへリダイレクトされても再度認証は不要）

7

大きく考え方が異なる

過去の資産との付き合い方IT環境の変化◦ クラウドの活用 ⇒ 境界の変化（ネットワーク境界を超えるIT利用）

◦ デバイスの変化 ⇒ 非ドメインクライアント（BYOD、スマホ、タブレット）

既存インフラはついていけるのか？◦ 過去に構築した統合Windows認証のASP.NETアプリをタブレットから使うとページ

単位でIDとパスワードを聞いてくる・・・

◦ Federationに対応させるとなるとコストが・・・

8

一つの解としてのWeb Application Proxy

ドメイン（レルム）の範囲

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

DemoWAPを使い、非統合Windows環境よりSSOする

10

デモ環境

11

Kerberos認証する様に構成したアプリケーション• SharePoint Central Administration• Microsoft Identity Manager 2015 ドメイン参加した

WAPとAD FS

AD FS

SharePoint

MIM PortalAD DS

登録

WAP

リバプロ通信統合Windows認証 WAP経由の

アプリSSO利用（AD FS経由で認証）

前提事項（そしてはまりポイント）そのアプリ、本当に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が表示されていることを確認

まとめ①WAPは単なるAD FS専用のリバプロじゃない

既存アプリをクラウドへ持っていく前の過渡期に活用できる（かも）

対象アプリのKerberos構成の事前確認が大事

13

これからの話Next Generation Credentials（NGC）と

Cloud Domain Join（CDJ）

14

【ご注意】現在公開されている情報、および個人的な試行錯誤がベースとなっているため、勘違いや今後の仕様変更などがある可能性が非常に高いので取扱いにはご注意ください。

Next Generation Credentials(NGC)◆課題

真のSSOへの道は険しい⇒非ドメイン環境でのデバイスログインとブラウザログイン

パスワードをいつまで使い続けるのか

15

◆クレデンシャルに関する議論⇒パスワード• 本当にその人のパスワードかどうかの保証がない• 中間者攻撃（Man in the Middle）に弱い⇒スマートカード• 本人（持ち主）である保証の確率は比較的高い• 対応したクライアントが必要

シンプルで安全なクレデンシャルが求められている• なりすませない、傍受されない• プラットフォームを選ばない

Next Generation Credentials(NGC)基本的な考え方/特徴は以下の通り

秘密鍵と公開鍵のペア

秘密鍵はデバイスに残さない

秘密鍵はTPMで保護される

サーバは公開鍵を持つ

クライアントが秘密鍵で署名し、サーバが公開鍵で署名確認をする

FIDO、OAuth2.0 JWTの標準ベース

※tech days 2015 france & Google翻訳より

http://fr.slideshare.net/DecideursIT/sec303

16

Cloud Domain Join(CDJ)Windows 10 Technical Preview 9926より利用可能

NGCを利用

Azure Active Directoryへドメイン参加（デバイス登録）

Azure ADアカウントでPCへログイン可能

セットアップ後はパスワードを使わず、PINでログイン

PCログインとアプリケーション・ログインのSSO（まだ限定的）

17

DemoWindows10 TP 9926へAADアカウントでログインする

18

ステップ1. デバイス登録

2. 鍵の生成と登録

3. ユーザ認証

4. アクセストークンの要求

19

セットアップ・フェーズ

認証・フェーズ

デモ

ステップ①：デバイス登録

20

• AzureADのDRS（Device Registration Service）へデバイス登録を試行

• AzureADの認証サービスでユーザ認証（MFAも利用可能）し、DRSへのアクセストークンを受け取り、DRSへデバイス登録

• DRSがデバイス証明書を送り返してくるのでデバイスに証明書をインストール

ステップ②：鍵の生成と登録

21

• Windows10デバイス側でユーザ鍵ペア、デバイス鍵ペアを作成し、ユーザとデバイスそれぞれについてアテステーションblobを作成

• Azure AD鍵登録サービス（KRS）へ鍵登録要求を行う（アクセストークン、公開鍵などを含む）

• Azire AD鍵登録サービスがNGC-KEYをデバイスへ送り、デバイスはKGC-KEYを保持しておく

ステップ③：ユーザ認証

22

• AzureADの認証サービスにアクセス、NONCEを取得する

• NONCEとNGC KEY-IDを秘密鍵で署名• 認証要求• プライマリ・リフレッシュトークンとアクセストー

クンを取得、対象鍵をTPMにインポートする

ステップ④：アクセストークンの要求

23

• KsKの生成• AzureAD認証サービスにアクセストークンを要求

（要求時、ターゲットリソース情報、Kskを送信）• アクセストークンを返却

現状はPCログインと一部サービスしかSSO出来ないが、いずれOffice365などにも広がる（はず）

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