前回の続きです。前回はこちら → Azure AppFabric ACS v1+ADFS+WCF Data Services
今回は実際にフェデレーション認証を利用するサービスとクライアントを作成します。
サービス側はWCF Data Servicesを利用して、トークンが有効な場合のみデータ（Entity）を返すようにします。
クライアントはActive Federation認証を行いますので、ADFS2.0とACSv1を使用し得られたトークンと利用してWCF Data Servicesにアクセスしデータを取得します。
ではまずサービス側から。
今日はWindows Azure AppFabric Access Controle Service v1 （現行）（以下ACSv1）とActive Directory Federation Services 2.0 （以下ADFS）を組み合わせてWCF Data ServicesをActive Federation認証してみようと思います。
WCF Data Servicesを利用するクライアントは今回はブラウザではなく、Windowsアプリとします。なのでブラウザが自動リダイレクトして認証画面に飛ぶようなPassive Federation認証ではなくActive Federation認証です。（自前でトークンのやり取りします）
そもそも、現行のACSv1はPassive Federationに対応していませんし、マルチテナントを考えるとちょっとWindows Identity Foundation（以下WIF）についてるFederation Utilityは使えないのでほぼコードでいろいろ制御することにします。
はっきりいって、ACSv2が出るまでのつなぎですね。ちなみに今回のネタはWIF トレーニングキットに付属するハンズオンラボ（IntroAppFabricAccessControl）を見ながらやればある程度できると思います。
今回想定している環境はこんな感じです。
※見ての通り（？）、WCF Data ServicesとSQL ServerはWindows Azure＋SQL Azureでもまったく問題ありません。
では準備から。
前回のPOSTをしてからいろいろ教えていただきました。
まずMicrosoft Federation Gatewayが信頼してくれるルート証明機関（CA）ですが、以下のTechNetに記載がある通りとなるようです。
トラブルなしでMicrosoft Federation Gatewayとフェデレーションしたかったら記載のルートCAが発行するX.509証明書のほうがいいでしょうね。
さて結構なお値段がする証明書ですが、価格がお安めの証明書をいくつか教えていただきましたのでこちらも記載しておきます。
この中でMicrosoft Federation Gatewayに対応できそうなのはGoDaddyとCOMDOですかね。GeoTrustは親会社がベリサインですが、CA的にどうなのかは見たことないので不明です。
COMDOは90日間フリーなので使い方次第では凄い助かるかもですねー。
ちなみに先日のニュースリリースでGeoTrustがワンコインSSLなるサービスを発表しています。
※Amazon EC2のユーザーのみ対象ですけどね…
今日ちょっとなやんでしばやん先生に即答してもらったのでメモ。
まずリソースファイルをPublicにしておきます。要確認。
リソースファイルのプロパティでカスタムツールを PublicResXFileCodeGenerator にしてビルドアクションで”埋め込まれたリソース”にしておきます。
あとはデータアノテーションのところでリソース指定するだけ。
例：ASP.NET MVCで既定で生成されるAccountModelなど
[Display(ResourceType = typeof(YOURNAMESPACE.App_GlobalResources.StringResources), Name = "ResUserName")]
public string UserName { get; set; }
超簡単ですね。
ASP.NET MVC3での多言語対応はこちらも参照。
ただこれやって発行したりするとリソースDLLはできてるんだけど読み込めないみたいなんですよね。なんでだろ。。まだ調べてる途中なのでわかったら追記等します。
2011.02.23 追記
いろいろ見てると以下の事がわかりました。
ということでGetGlobalResourceObjectが問題。Webアプリケーションの発行先にApp_GlobalResourcesフォルダ（と.resxファイル）があれば問題なく動作しますが、埋め込みリソースとしてビルドするとアセンブリに埋め込まれて（あとサテライトアセンブリが出来て）発行先にはApp_GlobalResourcesフォルダは含まれません。
で、この状態でGetGlobalResourceObject呼び出すとNGと。嵌ってた状況はこんな感じです。
じゃぁどうやってアクセスするんだ？というと単純にリソースは既にPublic化されているわけですから
@MvcApplication1.App_GlobalResources.StringResources.String1
みたいにしてあげればいいわけですね。やぁ長かったよ。
参考にしたサイトはこちら。
ゼロから始めるといろいろ壁にあたりますね～。
今日はWindows Azure Connectなんぞをネタにしようと思います。
さてWindows Azure Connectとは？というところなんですが、よく考えるとあまり取り上げてなかった気がしますね。
ぶっちゃけていうと、クライアントコンピューターとWindows AzureのホストサービスをVPN（IPSec）で結んであたかも直接通信ができるようにトンネリング接続してくれる機能のことを指します。
IPSec接続にはクライアントからOutbound TCP/443ポート（HTTPS）だけ開いていればいいので、ネットワーク要件としてはファイアウォールの設定変更も大半のケースでは不要ですし、使い勝手は良さそうです。が。
Windows Azure SDK 1.3 の機能であるFull IISを利用してWeb Roleを展開すると、Web.configに明示的に指定してたMachineKeyが Windows Azure上に配置後上書きされる問題があります。（※Hosted Web Coreを利用する場合は問題ないようです）
この問題に対する回避策はSteve Marxが回答していますが、MSDNのIssueにあるようにRoleEnvironmentのOnStart等で明示的に書き換えてあげる必要があるようです。
前回のPOSTで書き忘れたこと。
インターセプターを使えば特定の列だけ値を変える等できます。OData and Authentication – Part 7 – Forms Authentication にも記載されていますが、たとえば認証されているときだけセンシティブな情報を返すとか。
認証ユーザーやロールに応じて1つのWCF Data Services で柔軟に操作範囲を変えたりできるのはすごく便利ですね。
あと忘れてましたがASP.NET開発環境だとうまくフォーム認証が動きませんでした。（.adxが見れない？）このあたりあまり情報なくてちょっと諦め気味…
面倒だけどデバッグはIISのワーカープロセスにアタッチする等したほうがいいのかも…？
またSQL Serverへの接続は手抜きですが、アプリケーションプールのユーザー等にアクセス権限無いと無駄に怒られますので注意。
最後に追加でいろいろリンクを置いておきます。
ちと調べてて悩んでたので一応吐き出しておきます。
WCF Data Services を使うとOData形式等で強力なデータ連携が可能になります。
特に Entity Framework や LINQとの相性は抜群です。
でもむやみやたりにデータ公開したくないわけで。特にクラウドに置いたりする場合は。
じゃやっぱり認証かけたいよね、ということで今回は以下のケースで考えてみます。
イントラネット等でWindows統合認証が使えるならこんな苦労はないのかも知れませんが、プログラム内から操作する方法だと取れる手法は限られてきます。
で、今回はお手軽にフォーム認証を使って Cookie ベースで制限をかけたいと思います。（まぁなんというか、やってることは OData and Authentication – Part 7 – Forms Authentication と変わりません。）
※ Cookie ベースならまぁローカルに保存してても許してくれそうですし。
ブチザッキ 