毎年恒例アドベントカレンダーですが、ちょっとマイナー系（？）なContribution License Agreement （CLA）まわりを書こうと思ったらまさかのネタ被りしたので違うこと書きます（未着手だったので問題はない）

というわけで、この記事はAzure Advent Calendar 2014 の10日目の記事です。ちなみに過去こんな感じでやってます。

• Windows Azure Advent Calendar jp: 2012
• Azure Guest OS 3.xでARRv3を使う
• Windows Azure Advent Calendar 2013
• Windows Azure Web Sitesの魅力を120%引き出す

なんかその年の潮流というか雰囲気がわかって見返しても楽しいですね。（しかし時の流れは無情だな）

さてさて、今年はAzure Websitesにひっそりと追加されている認証/承認機能（Preview）を試してみたいと思います。公式的にはこちらを参照ください。

• Azure Websites Authentication / Authorization のご紹介

認証/承認機能って？

簡単に言うとWebsitesとAzureAD（Azure Active Directory）の連携をシンプルにする機能です。Webサイトに配置するアプリケーション如何にかかわらず、AzureADとのフェデレーション認証を有効化することができます。またその際に複雑な設定などは不要というお手軽さ。

通常、アプリケーションの認証先としてAzureADを使う場合などはAzureAD側でWebアプリケーションのURLの定義をして～アプリケーション側でフェデレーション先の情報を設定したりコードを書いたりして～と存外面倒くさいですよね。

この機能ではその辺をバッサリ省くことができます。但しアプリケーション内の特定のページ（たとえばランディングページやTopページなど）は誰でも（認証なくても）アクセス可にしたい、といった要件には合いません。無条件にWebサイトが要認証になりますので用途は選びます。

事前準備

ではでは、さっそくみていきましょう。事前準備としてはAzureサブスクリプションですね。あとAzure ADを触ったりするので、ディレクトリを触れるように準備しておきましょう（新しく作るかCo-Adminではないアカウントでやりましょう）

• Azure Active Directory
• Azure Active Directory Sync (英語)
• Azure AD テナントの管理

それから、普通のAzure Webサイトが必要なのでさくっと作っておいてください。空ページのままでOKです。（ホスティングプランは無料（Free）でも使えます）

※初期状態です。誰でも見れますね。

設定方法

設定はいたって簡単です。Webサイトの構成ページ内にある「認証/承認」で行います。

ぽちっと構成ボタンを押しましょう。

AzureADを選択して、対応するアプリケーションを選択します。作ってない場合は「新しいアプリケーションの作成」ですね。ちょっと待つと構成が終わります。

これで終わりです。ほんとに！？

作ったWebサイトに（In-Privateモードなどで）アクセスしてみましょう！

何とAzureADのサインイン画面に飛ばされて認証必須になりました！

ちなみにこの構成をするとHTTPS必須になります。（HTTPで接続するとリダイレクトされる）

たったこれだけ（1ステップ）でサイト全体を要認証ページにできました！お手軽～！

指定したAzureADと連携してるので、ユーザーを追加したり多要素認証を設定したりブランディングをすることも簡単です。

こんな感じでAzureADで登録したユーザーにアクセス許可が与えられます。AADSyncなんかを使っているとオンプレのADとの同期とかもおｋですね。

先ほどのWebサイトの構成で設定した内容はAzureADのアプリケーションのところで詳しく見ることができます。

実際何をしているかというと、AzureADへのアプリケーションの登録と、Webサイトの（たぶん秘密のISAPIモジュールで）認証を強制的にする、ということが裏で行われてます。フェデレーション認証に必要なクライアントIDやらメタデータやらなんやら細かいことは自動的にしてくれるので便利ですね。

Webサイトに配置したWebアプリケーションにリクエストが来る手前で処理されるので、HTMLでもASP.NETでもPHPでもなんでもOKという感じです。

少し詳細

さて単に制限かけたいなーというだけであればこれで済みますが、もうちょっとアプリケーションでいろいろしたい、という要求はあるかと思います。

ちょうど良いサンプルが公開されているので、まずはそちらを見てみましょう。

• Websites-Authentication-Authorization (GitHub)

cshtmlとWeb.configをWebサイトにアップロードして接続してみましょう。

こんな感じで認証されたユーザーの情報などが取得できることがわかります。

AzureADで定義された姓名などがクレームとして取得できてるのがわかります。この辺の情報はCookieに自動的に入れられるようですね。

ASP.NET的にはThread.CurrentPrincipal as ClaimsPrincipalで一通りごにょごにょ触れます。
サインイン名ぐらいであればリクエストヘッダの「X-MS-CLIENT-PRINCIPAL-NAME」に入っているのでASP.NETでなくてもお手軽ですね。

1点特殊なのがサインアウト方法です。フェデレーション認証している場合、サインアウトするにはちょっと面倒くさいのですがこの認証/承認機能では専用のサインアウトURLを用意してくれています。

環境変数の「WEBSITE_AUTH_LOGOUT_PATH」にサインアウト用のURLが格納されているので、そちらを使えばアプリケーションからサインアウトすることができます。

URL例：https://kosmosebiac.azurewebsites.net/be843d9e-101a-430d-be72-195a5b1b1e0d/logout

注意点：ASP.NET MVCの既定のプロジェクトを使う場合

よくあるトラップだと思いますが、ASP.NET MVCなプロジェクトでそのままフェデレーション認証しちゃうと以下のようなエラーに出くわす場合があります。

A claim of type ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier’ or ‘http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider’ was not present on the provided ClaimsIdentity. To enable anti-forgery token support with claims-based authentication, please verify that the configured claims provider is providing both of these claims on the ClaimsIdentity instances it generates. If the configured claims provider instead uses a different claim type as a unique identifier, it can be configured by setting the static property AntiForgeryConfig.UniqueClaimTypeIdentifier.

書いてる通り、AntiForgeryのトークン生成に使う値を例えばNameIdentifierなどにしてあげれば解決します。

例：

        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);

			AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.NameIdentifier;
        }

AntiForgeryConfig.UniqueClaimTypeIdentifierにClaimTypes.NameIdentifierを指定するだけです。

後はこんな感じで何もしなくてもユーザーIDぐらい取れます。LiveIDで認証してる場合、ちょっとlive.com#とか頭につきますけど。（x-ms-client-principal-nameリクエストヘッダのほうは大丈夫なので適宜修正しましょう）

制限事項

• 現時点では設定した先のAAD（ディレクトリ）のユーザー全員がアプリケーションにアクセスできます（Webサイト側で認証通れば無条件にアプリケーションを見れるということ（アプリケーション側で何とか制御するしかない）
• またWebsite全体が要認証となります（一部のページ等だけ認証が必要であとは匿名にしたい、といった要件には対応できません）
• リダイレクトやログインフォームを出さないようなヘッドレス認証はまだサポートされていません。

まとめ

とりあえずインターネット上にWebサイトを公開したいけど、認証ではじきたいなー、でもコード書くの面倒くさい（Or静的HTMLだったり）場合、設定で簡単に認証必須にできるのがいいですね。

おまけ

WebsitesのService Management REST APIに関するリファレンスが無くて泣けるという闇話もありましたが面白くないのでやめました。いつ復活するんだろう。

現行のAzure PowerShellで実行できる内容ならソース追えばいいですが、、、面倒くさいです。。