Azure AppFabric ACS v1+ADFS+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でもまったく問題ありません。

では準備から。

ACSv1のセットアップ

ACSv1のセットアップはAzure AppFabric管理ポータルからアクティベーションするだけです。サービス名を入力してクリックしていくだけでいいので簡単に。

サービス名、アクセス用のキーは後で使いますので控えておきます。
作成後、Active状態になればOKです。

 

ADFSのセットアップとRPの追加

ADFS 2.0のセットアップは省略します。ちなみにWindows統合認証でSSOチックにするために今回はActive Directoryドメイン配下に参加させて、ADFS2.0をインストールします。※クライアントもドメイン参加させておきます。(必須ではありません)

セットアップ後、まずはWindows統合認証用にエンドポイントを有効にします。

/adfs/services/trust/13/windowsmixed を選択して有効にします。

有効後、Relying Party(証明書利用者信頼)を追加します。

 

オンラインでインポートを選択し、ACSv1の情報を入力します。参考までに入力するURLは以下のようになります。(ホスト名=サービス名だけ変更すればいいですね)

https://<サービス名>.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml

アクセス許可はすべてのユーザーに許可するようにしておきます。

RPの追加後、要求規則の編集を行います。(チェックを付けていると自動的にダイアログが起動します)
発行変換規則タブの規則の追加ボタンをクリックして規則を追加します。

ここではLDAP(Active Directory)から属性をとってきて送信するようにします。(「LDAP属性を要求として送信」を選択)

属性ストアから「Active Directory」を選択してLDAP属性に適当なの(DisplayName)と出力方向の種類を選択します。(必要に応じて追加していくことができます)※このあたりはMS安納さんのセミナー資料に詳しく載っていますね

追加後はこのような感じ。これでOKボタンをクリックして終了します。

ADFS側の設定はこんな感じで終わりです。

 

ACSv1の設定

次はACSv1側にIssuerやクレームのルール等を設定していきます。

今回はGUIな管理ツールのACMBrowserを利用して設定します。ACMBrowserはなぜか今ダウンロードできなさそうな感じなので、Windows Azure AppFabricSDK v1.0のSamplesにあるACMBrowserをソースからビルドして使用します(やれやれ)

サンプルの \WindowsAzureAppFabricSDKSamples_V1.0-CS\AccessControl\ExploringFeatures\Management\AcmBrowser\ フォルダにソリューションがあるのでVisual Studio 2010で開いてビルドします。(プロジェクトの変換が必要ですが、すんなり終わるのでウィザードに従いましょう)

ビルド後、以下のパスにEXEができますので実行します。

\WindowsAzureAppFabricSDKSamples_V1.0-CS\AccessControl\ExploringFeatures\Management\AcmBrowser\ManagementBrowser\bin\Debug\AcmBrowser.exe

GUIが起動するので、それぞれの項目に追加していきます。

「Token Policies」を右クリックしてCreateを選択します。

「Token Lifetime」にはトークンの有効期限を、「Signing Key」はGenerateボタンをクリックして自動生成します。Signing Keyはアプリでトークンを検証する際に必要になりますので控えておきましょう。

次に「Issuers」を右クリックしてCreateを選択します。

Issuerは利用者ですので、今回はADFSを指すことになります。「Algorithm」は”FedMetadata”を選択してADFSのメタデータから取得するようにします。
「Endpoint URI」はADFSのメタデータへのURLになります。だいたい以下の通り。

https://<ADFSサーバー>/federationmetadata/2007-06/federationmetadata.xml

サーバー名は証明書で指定されてるものと同じ(証明書の検証でエラーにならないよう)にする必要がありますので注意。
ちなみにEndpoint URIから実際にデータを取得しますので、ACMBrowserが動作してる端末からADFSにちゃんと(証明書エラーなく)通信できる必要があります。勝手証明書や自己署名証明書の場合はちゃんとインポートしておきましょう。

次に、「Scopes」を右クリックしてCreateを選択します。

ここではトークンを利用するサービスを指定します。(今回の場合はWCF Data Services)
「Applies To」にWCF Data ServicesのURLを、「Token Policy」には先ほど作成したポリシーを指定します。
Scope作成後、クレームのルールを作成します。(作成したScopeを展開してRulesを右クリック→Create)

今回は単純にするために「Type」を「PassThrough」にし、ADFSから発行されたトークンに含まれるクレームの1つをそのまま出力するようにします。
Input Claimの「Issuer」には先ほど作成したIssuer(ADFS)を選択し、Typeは以下のようにします。

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

ADFSが出力できるAD上の属性は以下の通りですので参考までに。

Output Claimにはそのまんまname等を指定しておきます。

さて作成が終わりましたら、いったんローカルのXMLファイルに設定内容を保存しておきましょう。
というのもACMBrowserの出来があまりよろしくないようで、後で修正したり変更をUpしようとしてもうまく行かなかったり、何かあった時に悲しいことになるので…

さてACSv1へのアップロードはService NamespaceにACSv1のActiveになったサービス名、Management KeyにACSv1のキーを入力します。入力後、フロッピー+雲アイコンのメニューをクリックしてACSv1に反映させて完了です。

無事エラーなく保存されれば完了です。

インフラとしてのADFSとACSv1の準備はこれで完了です。あとはアプリケーションでトークンを要求したり送出するサービスクライアントと、トークンを受け取って検証・認証するようなWCF Data Servicesを作ればOKですね。

以下次回へ続く

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中