Upload
naohiro-fujie
View
3.597
Download
5
Embed Size (px)
Citation preview
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サーバに委任設定