ROOM
Authentication/Authorization
Platform
SAML, WS-Fed,
OpenID Connect, Oauth 2.0に対応 Windows 統合認証Ldap 認証、パスワード 等
5
認証と公開の基本方針
• ハイブリッド認証基盤
• Azure Active Directory
• Active Directory ドメインサービス ＋ Active Directory フェデレーションサービス
• 今後開発する新しいアプリケーションは OpenID Connect 対応
• Azure Active Directory
or Windows Server 2016 Active Directory フェデレーションサービス
• オンプレミスにアクセスするための認証機能付きリバースプロキシー
• オンプレミス ：Web Application Proxy（WAP） • クラウド ：Azure Application Proxy
認証しなければならない回数を極力減らす（できれば、OS サインイン時のみ） ID とパスワードの管理はオンプレミスの Active Directory
Scenario Protocol AD FS Azure AD
Native client OAuth 2.0 auth code grant, public client 2012 R2 ○
Web sign in WS-Federation 2012 ～ ○
SAML 2.0 2012 ～ ○
Web to
Web API OpenID ConnectOAuth 2.0 implicit grant 20162016 ○○ OAuth 2.0 auth code grant, confidential
client 2016 ○
Server to
7 Azure MFA
認証基盤：ハイブリッドな Active Directory
オンプレミス パブリッククラウドAzure Active Directory
• オンプレミスのIDとアクセス制御 • 長年蓄積されたオンプレミスの IT ガバナンス • クラウドサービスに対する IDとアクセス制御 • サービス間のシングルサインオン Identity Federation • オンプレミス AD または Azure AD のいずれかにアプリケーションを接続する • ユーザーのパスワードはオンプレミスで集中管理
8
認証機能付きリバースプロキシー
Azure MFA オンプレミス パブリッククラウドAzure Active Directory
Identity Federation
Azure Application Proxy
Proxy Connector
Web Application Proxy
Active Directory への代理認 証機能を持つ Active Directory への 代理認証機能を持つ 事前認証 事前認証
9
覚えておきたい裏技：アクセスパネル
• Azure AD に接続されたアプリケーションはアクセスパネルに登録できる
• アクセスパネルに登録されたアプリケーション間は SSO
• アクセスパネルにサインインすれば、アプリケーションの認証は必要ない
10
11
覚えておきたい裏技：Azure AD パスワード連携
Access Panel MyApps
Azure AD にサインインしていれば、 アクセスパネル がパスワード入力を代行してくれる 事前に登録しておく Form に入力する ID と パスワードはAzure AD に暗号化して保存
12
覚えておきたい裏技：Web Application Proxy 認証の継承
• Web Application Proxy で一度認証されると、ブラウザセッションが生きている
間は他のアプリケーションにも認証が継承される • フェデレーションによる認証も継承される App1 App2 事前認証 アクセス App1 App2 スルー 認証要
既存アプリのタイプ
（いずれもオンプレミス） 外部公開方法
認証
Windows 統合認証 AD FS ＋ WAP Azure AD
デスクトップアプリ
認 証 方 式
Windows 統合認証 RemoteApp(on-prem) +Web Application Proxy
（2016） ○ ○
ldap など Web Application ProxyRemoteApp +
Or
Azure RemoteApp + Web Application Proxy
認証の統合（継承）はプロトコルの仕様上困難なため アプリ側のカスタマイズが必要
ローカル
既存アプリのタイプ
（いずれもオンプレミス） 外部公開方法 Windows 統合認証 AD FS + WAP認証の統合先 Azure AD
WEB アプリ
認 証 方 式
Windows 統合認証 Azure App Proxy ○
（w/ Proxy Connector） ○ (Access Panel)
Web Application Proxy ○ ○ クレーム非対応 ○ (Access Panel-existing fed)
Basic認証 Web Application Proxy（WS 2016） ○ クレーム非対応 ○ (Access Panel –Existing fed)
HTML ベースの
サインイン ページ Web Application ProxyAzure App Proxy or ○ (Access Panel –password fed)
SAMLトークン対応アプリ
(SAML 2.0/WS-Fed) Web Application Proxy
○ クレーム対応
Azure App Proxy ○
OpenID Connect/OAuth2.0 対 応アプリ
Web Application Proxy
（WS 2016） ○（WS2016） ○
○（WS2016） ○
その他認証 カスタマイズ要
認証なし Web Application Proxy ○ ○ クレーム非対応
Access Panel MyApps Azure App Proxy
25
モダンアプリケーションの種類とアクセスパターン
IdP を持つ SaaS デバイスネイティブアプリ クラウド上のAPI WEBアプリ ブラウザ 7:37 AM 2 1 3 426
① WEB アプリ
• SAML 2.0/WS-Federation または OpenID Connect / Oauth 2.0 どちらでも
ブラウザ 1 2
Oauth-Authorization WEB APP
Oauth-Token 3 4 Azure AD Cookie 認証 SAML WS-Fed ブラウザ 認証 1 2 3 4 Cookie クレームを チェック WEB APP AuthZ Code AuthN Token OpenID Connect には続きがあります（次ページ） Azure AD Graph
27 ブラウザ Oauth-Authorization WEB APP Oauth-Token Azure AD AuthZ Code AuthN Token Azure AD Graph 5 Refresh Token Access Token User Info 6 7 8 • SAML トークンにはユーザー 情報がクレームとして格納 されている • OpenID Connect の場合は、 ユーザー情報を取得するた めに Graph API にアクセス する必要がある
28
Azure AD
Browser OAuth- Web App
authorize OAuth-token graph
Navigate to your application
Post authN token and authZ code to your application’s redirect URL
No session, send authN request Verify token signature
302 redirect for sign in OpenID Connect request
(user signs in)
Set cookie and return user to page they started on Redeem authZ code
Return access token and refresh token Call the Graph API
29
② IdP を持つ SaaS との連携（異なるIdP間の連携）
Sync WS-Fed SAML 2.0
（for Shibboleth）
Office 365
Azure Active Directory • 異なる IdP 間の Identity Federation は SAML/WS-Federation を使用する
• Identity の同期が必要
30
Azure AD アプリケーション ギャラリー
※ ISV 様が自社開発 SaaS アプリをギャラリーに登録申請することもできます
アクセスパネル
http://myapps.microsoft.com/
Web page title
31
SaaS
もし SaaS アプリを OpenID Connect/OAuth2.0 のみで作成したら
• 何の問題もない。
• IdP が OpenID Connect だけではなく SAML 2.0/WS-Fed もサポートしていること が重要 Oauth-Authorization App 本体 Oauth-Token IdP 外部 IdP SAM L WS -Fed フェデレーション
OpenID Connect / OAuth 2.0
32
③ WEB Service → WEB API
ブラウザ Oauth-Authorization Web App Oauth-Token IdP Cookie • API へのアクセス認可プロトコルは OAuth2.0 一択 Authorization Code Access Token Refresh Token 1 WEB API 2 4 認可 Access Token の再取得 3
Azure AD - OAuth 2.0 EndPoint に合わせて開発する Azure AD を IdP として信頼 Security Pipeline 1Hでタイムアウト
33
④ ネイティブアプリ
• OpenID Connect / OAuth 2.0 での実装が事実上のスタンダード
• 直接実装（ADAL）も可能だが、Azure Mobile Service の利用をお勧め
OAuth-Authorization OAuth-Token IdP 7:37 AM Application Web API 1 Application 4 Code 3 5 Sign-in 2
34
アプリケーションを Azure AD に対応させるには
ApplicationAAD Native
モバイルアプリ
Azure Mobile Service
35
Visual Studio 2015 （現在 RC）
• WEB アプリや Windows アプリに加え、Android、iOS アプリケーションの開発も 可能
• インスタントにAzure AD に結合
Azure Mobile Service との結合設定画面
TPM
Windows 10 とネイティブアプリケーション
• 通常、ネイティブアプリケーションは「隔離」されているため、他のアプリ
ケーションとトークンを共有することができない
• Windows 10 ではネイティブアプリを「Web Account Manager」に対応させる
ことで完全な SSO が可能
Web Account Provider1
Azure AD
Native Application
Token Broker
Token Broker plug-in
Web Account Manager
Token を持っていれ ばそれを利用。持っ ていなければ要求。
iOS Android Native
C#/JS ADAL .NET + Xamarin
Apache Cordova Plugin for ADAL
ADAL .NET
ADAL Obj-C ADAL Android
Web Account Manager
※ 現時点では未提供
• ADAL 対応アプリ間での SSO
• 多要素認証にも対応
39 • ソーシャル ID を使用して Azure AD のアプリを使用する • セルフサービス機能 • サインアップ • パスワードリセット • プロファイル編集 • サインイン画面のカスタマイズ
Azure AD B2C: “IdMaaS for applications”
まもなく Preview 開始予定
コンシューマー向けアプリ • キャンペーン
• ご意見募集 • 会員制ページ
40
41
42
認証と公開をデザインする鍵
Traditional
•
ハイブリッド認証基盤
•
Azure アクセスパネル
•
Azure Application Proxy、Web Application Proxy
Modern
•
SAML による Identity Provider 間の Federation
•
新規アプリは OpenID Connect に対応
•
WEB、WEB API、ネイティブアプリ
•
モバイルサービスを活用するとコスト削減
•
開発には Visual Studio が最適
43
44
Next Step：モバイルデバイスの管理
Azure RMS Azure MFAIntune
MDM,ガバナンス デバイス内 データ漏えい防止 デバイス外 データ漏えい防止 SSO アクセス制御Hybrid Active Directory 認証強化
46
現在（より少し前）までの主流
同期
認証の範囲•
複数の認証サーバー
•
それぞれの認証サーバーは独立
•
Credential も独立
•
認証サーバー間は同期
（含 パスワード）
•
アプリケーションはどこかに所属
•
場合によっては独自認証
•
認証のターゲットは「人」
•
やっちゃいけないことは
ルールで規定
47
どこに問題があるのか？
WEB App 業務パッケージ （Local AuthN） Mail SV WEB API AD DS LDAP IE Safari 利用者 デバイス アプリケーション データ Client App Server App APIIdP
48
共通認証基盤の基本的な考え方～オンプレミス
クラウドとモバイルデバイスをどのように“認証基盤”に接続するか • 基本的に現状維持（無理にクラウド移行は考えないのが吉） • オンプレミスに閉じたセキュリティも重要ただし！
• 単なる「認証サーバー」から「アイデンティティプロバイダー」化へ • オーソリティとなる認証サーバー/ディレクトリを決める • モダナイズのポイント • SAML/WS-Federation プロトコルへの対応（クラウド連携、システム間連携） • デバイス認証（モバイルデバイス連携） • コンディショナル・アクセス制御 • 認証の強化 • 多要素、バイオメトリクス49
マイクロソフト製品での実装例
既存の Active Directory ドメインを拡張する • モダンなプロトコル（SAML/WS-Fed/Oauth2.0）への対応 • 外部からの認証要求の受け入れ ディレクトリ 認証サーバー Kerberos セキュリティ トークンサービス その他 認証サーバー 業務アプリ サーバー Authority SAML 2.0/ WS-Federation 同期 WS-Fed https SAML リバースプロキシー （含 認証） Conditional Access Microsoft Identity Manager Kerberos/ ldap/ NTLM Firewall WS-Fed https SAMLAD DS：Active Directory Domain Service AD FS：Active Directory Federation Service WAP：Web Application Proxy
50
新たな登場人物により設計はより複雑に。。。
同期
認証の範囲 7:37 AMクラウドアプリ
モバイルデバイス
モバイルアプリ
51
認証基盤単体の要件
基盤の安全性
管理のしやすさ、自動化
各種機能（証跡、セキュリティポリシー 等）
セルフサービス（パスワードのリセット等）
アプリケーション、デバイスからの要求
認証プロトコル（NTLM、ldap、Kerberos、SAML-P 等）
柔軟なアクセス制御と認証強度
認証基盤の設計に影響を与える要素
周囲の状況が認証基盤を選ぶ
52
クラウドとモバイルは切っても切れない
53
Enterprise 製品もモバイルデバイスをターゲットに
“クラウドだけ“ or “モバイルだけ” は
セキュリティ上あり得ない
54
共通認証基盤の基本的な考え方～クラウド
（注意）「認証サーバを IaaS に移行する」ことを「認証のクラウド対応」とは言わない
「標準規格」と「オンプレミスとの連携」を意識することが重要 • IDMaaS（Identity Management as a Service）
• オンプレミスのディレクトリを集約
• 以下のプロトコルに対応
• SAML 2.0/WS-Federation
• Open ID Connect / OAuth 2.0
• オンプレミス IdP との連携
• 他クラウドサービス、コンシューマー向けサービスとの連携
• 業務アプリケーション連携のためのインターフェースと開発ツール
• OMA-DM に対応した MDM/MAM as a Service
