de:code 2015 レポート day2 - DEV-019
クロスワープの大鷲です。
前回に引き続き、de:code 2015 day2 のレポートをお届けします。
参加セッション
私が参加したセッションは以下の通りです。
本記事では、「DEV-019 徹底解説! プログラマーがおさえておくべき Azure Active Directory のすべて」のレポートをお届けします。
資料はこちらで公開されています。
その他のセッション動画及びスライド資料も Channel9 で公開されています。
オープニング キーノートは Microsoft Virtual Academy のサイトで公開されています。
day 1
| CODE | ROOM | TITLE |
|---|---|---|
| SNR-004 | Room G | デジタルテクノロジーが推進する、アプリケーション革新 |
| SPL-001 | Room C | マイクロソフトが考える 5 年後を見据えた技術提言 |
| CHK-002 | Chalk Talk | クラウドアプリケーションのアーキテクチャ設計を深める |
| CHK-003 | Chalk Talk | プログラミング パラダイムの知識を深める |
| CDP-008 | Room C | MS版Docker 誕生! Windows Server Containers とは? |
day 2
| CODE | ROOM | TITLE |
|---|---|---|
| ARC-001 | Room A | クラウド時代のデータアーキテクチャ |
| SNR-009 | Room B | フルスタックエンジニアとか無理! 比べてわかったAzure PaaSの勘所 |
| DEV-019 | Room F | 徹底解説! プログラマーがおさえておくべき Azure Active Directory のすべて |
| PBS-001 | Room E | ここまでできる! Office 365 API を活用したアプリ開発 ～ Office 365 内のデータ活用～ |
| DEV-006 | Room A | ASP.NET 5 Web 開発 ～ ランタイム編 ～ |
| DEV-007 | Room A | ASP.NET 5 Web 開発 ～ フレームワーク編 ～ |
| DEV-008 | Room A | 進化は止まらない! ADO.NET Entity Framework の今 |
DEV-019 徹底解説! プログラマーがおさえておくべき Azure Active Directory のすべて
スピーカーは日本マイクロソフトの松崎 剛さん。
プログラマー向けの Deev Dive セッションということで、レベル 400（マイクロソフトの基準で 5 段階中、上から 2 番目の難易度）でした。
また、インフラ系の機能の紹介や構築手順といった導入などではなく、Azure AD をプログラマー視点で使うために必要なことに絞って解説されました。
Azure AD の概要
Cloud-based
オンプレミス時代、Microsoft はエンタープライズ アイデンティティの世界では勝ち組でした（多くの組織で Active Directory が使われていましたよね）。
しかし、現在、Web アプリケーションへのログインには Facebook や Twitter の ID を使うことが多くなっています。
Microsoft は Azure AD によって、クラウド時代でも、エンタープライズ アイデンティティ分野でリーダーシップを取っていこうとしています。
Openness
Azure AD は、従来の Windows Server AD をクラウドに持って来たものではなく、内部的には全く別のものです。
WS-Federation、SAML、OpenID Connect といったプロトコルに対応していますが、いずれも Microsoft が作ったプロトコルではありません。
For your own
通常、Facebook のアカウントを取得するのは、Facebook を使いたいからです。Twitter や Google も同様で、本来は、それらのサービスのためのアカウントです。
では、Azure AD は何のためのアカウントか？
Azure AD は Office 365 で使われていることから、Office 365 のアカウントを流用していると勘違いされることもありますが、そうではありません。
Office 365 のサービスを契約しなくても Azure AD を使うことができます。
難しさの隠ぺい
Azure AD を使った認証フローには、いろいろと面倒くさいこともあるのですが、Visual Studio を使うと、その多くを意識せずに作ることができてしまいます。
ASP.NET のプロジェクトウィザードには、既に Azure AD で認証するアプリケーションを作るための機能が統合されています。
「会社用及び学校用のアカウント（VS2013 では「組織アカウント」）」という選択肢がそれで、これを選ぶと、プロジェクトを作りながら、裏で Azure AD にアプリケーションを登録してくれます。
ウィザードで作成したアプリケーションを実行するだけで、Azure AD を使った認証処理は既に利用可能になっています。
アプリケーションを実行すると、自動的に Azure AD の認証サーバーにリダイレクトされ、ログイン画面が表示されます。
ここから少し細かい内部の話になります。
認証に成功してログインできると、ログイン画面からアプリケーションに POST で戻って来ます。
この際に渡されるパラメーターに、以降のアクセスに必要なトークンが渡されて来ます。
今後、このアプリケーションに対するすべてのリクエストで、HTTP ヘッダーにこのトークンを渡す必要があります。
Web API を開発する場合でも同様で、リクエストされたらトークンを検証するようにすれば、Azure AD を利用したセキュアな API を構築することができます。
Azure AD 認証を利用した API に対するクライアント側のアプリケーションを作るには、Active Directory Authentication Library (ADAL) というライブラリが利用できます。
.NET 用だけでなく、iOS 用、Android 用、Cordova 用など、様々なプラットフォーム向けにサポートされており、これを使うことで、簡単に Azure AD で認証するアプリを作ることができます。
あとは、そのライブラリから取得したトークンをヘッダーにつけて API リクエストを行うだけです。
ライブラリが対応していない場合
ADAL は多くのプラットフォームに対応していますが、すべてのケースをカバーできるわけではありません。
たとえば PHP で作らなければならない場合は？
そのような場合でも、Azure AD は Microsoft 製ではないオープンなプロトコルを使用しているという点がメリットになります。
Microsoft 以外が、そのプラットフォームや言語に対応するライブラリを公開している場合もありますし、最悪、自分でそのプロトコルを実装することができます。
自分で実装する場合に気を付けなければいけないのは、トークンのデジタル署名を常に確認するということです。ここをおろそかにすると、セキュリティホールを作ってしまうことになります。
ADAL が使える環境では、ライブラリが自動的に署名の検証をしてくれます。
レガシーな Web アプリ
例えば、単純な ID／パスワード認証を利用している既存のアプリケーションがあって、それをシングル サインオンに対応させたい場合はどうすればよいでしょう？
そのアプリを WS-Federation や OpenId に対応させることができればよいのですが、常にそうできるとも限りません。
この場合、Azure AD が持つ「パスワード シングル サインオン」という機能を利用することができます。
これは、そのアプリケーション内で独自に管理されているアカウント／パスワード（A）と、Azure AD 内のユーザー アカウント（B）をあらかじめ結び付けておくことで、Azure AD（B）でサインインすると、自動的にアプリケーションのログイン フォームに資格情報（A）を POST してくれるという機能です。
ただし、利用にはブラウザー プラグインが必要なので、利用できる環境は限定されます。
この機能はまだプレビュー版で、制約が多いそうです。
プロキシ アプリケーション
インターネット上に公開されていないオンプレミスな Web アプリケーションも、Azure AD でシングルサインオンさせることができます。
これはプロキシ アプリケーションという機能を利用します。
インターネットからアクセスするための URL が別途生成され、そこにアクセスすることで、要は Azure AD がプロキシとして働き、リクエスト／レスポンスを中継してくれるという機能のようです。
Mobile First
モバイルにおける非 Web（ネイティブ）アプリでは、さらに考慮すべきことがあります。
Web ページを表示するだけのお手軽な「ネイティブ」アプリもありますが、本格的なものでは、Web API を叩く作りにするのが一般的でしょう。
WS-Federation や SAML といったプロトコルも、非 Web アプリ用の機能を持っており、それぞれ WS-Trust とか SAML-ECP と呼ばれます。
しかし、一般的には OAuth が市民権を得ており、本命と言えるでしょう。
OAuth は Web アプリとの親和性が高いのが特徴です。
ネイティブアプリでもブラウザーコンポーネントを利用すれば、Web アプリの場合とほとんど同じように認証できます。
WS-Trust や SAML-ECP では、Web の場合とネイティブの場合で、使い方がかなり異なってしまうようです。
また、OAuth では、ログイン画面が出た後、どうやって認証するか（ADFS を使うのか、二要素認証を使うのか、etc…）はアプリケーションから見るとブラックボックスになっています。
そのため、アプリケーションを変更することなく認証方法を変更できるので、開発者の関心と IT 管理者の関心を切り離すことができます。
認証に成功すると、Access Token が手に入るので、以降の API アクセスにはこのトークンを利用します。
この後、セッション中では、API サービス側が見るべきトークンの内容や、クライアントの形態に応じたトークンの扱い方などの解説がありました。
ただ、この時点でかなり時間が押してしまっており、かなり急ぎ足での解説になってしまったため、ここではその内容については割愛させて頂きたいと思います。
