ラベル AppFabric の投稿を表示しています。 すべての投稿を表示
ラベル AppFabric の投稿を表示しています。 すべての投稿を表示

2012年12月23日日曜日

[Azure]新ポータルから Access Control 名前空間を作成可能に


Windows Azure のポータルが2012年5月にリニューアルされてからも Access Control(ACS)だけは旧ポータルからしか管理できませんでしたが、ようやく新ポータルからも管理できるようになりました。


新しい名前空間を作成することも可能になっています。


作成後、アクティブ化が完了するのを待ちます。


管理画面に遷移した後は以前と変わりません。



あとは、実現しなさそうですが、このプラットフォームの管理ポータルと、ディレクトリサービスの管理ポータル、オンラインサービスの管理ポータルの統合ですかねぇ。。
少なくとも同じサービス名がついてしまっている Windows Azure Active Directory(WAAD)の管理が複数のサブスクリプション、管理インターフェイスに分かれているので、もう少しシンプルになれば、と思います。

2012年12月2日日曜日

[WAAD] ACS および コア機能が無償で提供

これは結構大きなニュースです。

これまで本当はいつから課金されるのかよくわからなかった 旧 AppFabric Access Control / Windows Azure Active Directory ですが、ようやく明確なアナウンスがありました。

- Windows Azure Team の blog
 Windows Azure Active Directory: Making it easier to establish Identity Management in the cloud
- Vittorio の blog
 Access Control & Core Directory Available at No Charge

以下の 2 つのコア機能については無償!ということです。素晴らしい。

  • アクセス制御(旧 Access Control Service)
    • Facebook 連携やオンプレミスの Active Directory などとの連携機能
  • コア・ディレクトリおよび認証
    • シングルサインオン、ユーザ・グループ管理、ディレクトリ同期、フェデレーション機能


we are announcing today that two key features of Windows Azure Active Directory are available at no charge.
  • Access control provides centralized authentication and authorization by integrating with consumer identity providers, such as Facebook, or using on-premises Windows Server Active Directory.  By having Access Control available you can create a single application that can allow users to login with both their Organizational Credentials stored in Windows Azure AD or Windows Server AD, or to login in using popular consumer service identity services like Microsoft Account, Facebook, Google, or Twitter.  Historically, Access Control has been priced based on the number of transactions. We are now making it free.
  • Core Directory & Authentication enables capabilities such as single sign-on, user and group management, directory synchronization and directory federation. These features are currently free in the Windows Azure AD Developer Preview and will remain free after it reaches general availability.

前者(ACS)についてはこれまでトランザクション課金でしたが無償化、後者(WAAD)については現在プレビュー提供ですが、GA後も無償のまま、ということです。

ちなみにこれまでの課金に関する表記。若干混乱気味でした。

2012年11月4日日曜日

VS2012 用の Identity and Access Tool が RTM


遅ればせながら 10月23日にリリースされた Visual Studio 2012 用の Windows Identity Foundation Tools を試してみます。

まず、機能面の紹介です。
基本的には以前の WIF の Federation Utility と変わりませんが、個人的には下記が大きなポイントだと思います。

1.Identity Provider を ローカル STS、ビジネス Identity Provider(AD FS2.0)、Windows Azure Access Control Service から選択できるようになった。
  ⇒以前は、新しい STS を作成するか、既存の STS を利用するかの選択だった。

2.管理者として Visual Studio を実行しなくても Identity and Access Tool が利用できるようになった。
  ⇒以前は管理者として Visual Studio を実行しないと Federation Utility が実行できなかった。

3.ACS 側の設定を自動的に作成してくれるようになった。
  ⇒以前は ACS 上に RP の作成およびクレーム・ルールの作成を手動で行う必要があった。

4.認証されていないリクエストに対するアクションを選択できるようになった。
  ⇒以前は単純に STS にリダイレクトするだけだったが、今回から加えて controller を生成することが出来るようになった。


特に3番目、4番目については開発者にとって非常に有用な機能なのではないでしょうか?


では、早速試してみます。

■モジュールのダウンロードとインストール
 モジュールは vsix 形式で提供されていますので、ダウンロード、実行すると Visual Studio の拡張機能が有効になります。

 Identity and Access Tool のダウンロード URL
  http://visualstudiogallery.msdn.microsoft.com/e21bf653-dfe1-4d81-b3d3-795cb104066e


■プロジェクトの作成
 Controller の自動生成を試してみたいので、今回は MVC4 のプロジェクトを作ってみます。もちろん Visual Studio は管理者で実行しなくても大丈夫です。

 テンプレートから web -> ASP.NET MVC 4 Web アプリケーションを選択し、適当な名前を付けてプロジェクトを作成します。


 OK をクリックするとプロジェクト テンプレートの選択画面が出てきますが、デフォルトで選択されている[インターネット アプリケーション]を選んだまま OK をクリックします。



■Identity and Access Tool の設定
 プロジェクトの作成が終わったら、ソリューションエクスプローラからプロジェクト名を右クリックして表示される[Identity and Access]を開きます。


 Choose where your users are from でどの STS を使うのか選択できます。今回は ACS の自動設定を試してみたいので、[Use the Windows Azure Access Control Service]を選択します。
 すると、Select one or more providers from the ones configured in the ACS Namespace: で使用する ACS の Namespace の設定を行うリンクが表示されるので、クリックします。


 Configure ACS namespace のダイアログが表示されるので、ACS namespace および management key を入力します。


 ここで設定する management key は ACS の管理ポータルの管理サービスのパスワードです。



 設定が完了し、ダイアログを閉じると ACS 上に設定されている IdP 一覧が取得されて表示されるので、このアプリケーションで利用したい IdP を選択し、一旦 OK をクリックし Identity and Access Tool を閉じます。


 ちなみに、このとき ACS 管理ポータルを見ると 証明書利用者アプリケーションとして作成したアプリケーションが登録されていることがわかります。


 同様に規則グループも自動生成されます。内容は単なるパススルーなので、必要に応じて編集をしてあげる必要はあります。



■Controller の自動生成
 次は、これまた新機能である Controller の自動生成を試します。
 再び Identity and Access Tool を起動し、今度は[Configuration]タブを開きます。
 すると、Choose how to handle unauthenticated requests という項目があるので、[Generate a controller in your project to handle the authentication experience at the following address]を選択します。


 これで、認証されていないリクエストに対応する Controller が生成されましたので、実際に認証が必要なリクエストを行うように設定を行います。
 今回はデフォルトの About 画面を認証が必要な画面として定義してみます。
 方法は簡単で、HomeController.cs の About() に対して [Authorize] を追加するだけです。



■アプリケーションの実行
 では、F5 キーを押して実際にアプリケーションを実行してみます。

 起動してきたら[バージョン情報]をクリックします。


 すると、ログインページが表示されます。ホームレルム ディスカバリ先として、先ほど ACS から取得してきた IdP 一覧が表示されるのがわかります。


 今回は Google を選択してみます。Google アカウントへリダイレクトされ、Account Chooser が表示されるので、使いたいアカウントをクリックします。



 認証が終わると、ホーム画面へ戻り、ユーザ名が取得できているのがわかります。




いかがだったでしょうか?非常に単純なサンプルだったので実際は色々とカスタマイズが必要にはなるでしょうが、ほぼノンコードでここまで出来るようになっている、という意味で以前のツールに比べてもかなりの進化を遂げていることがわかります。
ACS を使って多くの外部 IdP ユーザを対象にしたアプリケーションを簡単に開発できるので、EC サイトなど B2C シナリオではかなり有用な機能になるのではないかと思います。

2012年9月26日水曜日

[WAAD] REST Client で Graph API を直接実行する

# 一部ご指摘をいただきましたので若干修正(Base64 encode ⇒ Base64 url encode)

Windows Azure Active Directory をアプリケーションから利用する際、 Windows プラットフォームであれば、Windows Azure Authentication Library(AAL)を利用することになると思いますが、折角 RESTful な Graph API があるので、汎用 REST Client を使って API へアクセスしてみたいと思います。

■準備
 TenantContextID、AppPrincipalId、SymmetricKey が必要となります。前回同様、CreateServicePrincipal.ps1を使って必要な値を取得します。

 用意が出来たらいよいよアクセスしますが、今回やろうとしていることの全体像を簡単に図にしておきます。

 まず Graph API を利用するために必要な認可を ACS で受け、ACS から取得した Access Token を持って Graph API を利用する、という流れになります。

 実際にやってみると以下のような手順になります。

■Graph API を利用するための Access Token を取得する(REST Client ⇒ ACS)

 初めに、Graph API へのアクセスを行うために必要な Access Token を ACS から取得する必要があります。
 そのためには ACS へ JSON Web Token(JWT)形式でリクエストを投げる必要があります。

 リクエスト先および内容は以下の通りです。

Target Endpointhttps://accounts.accesscontrol.windows.net/tokens/OAuth/2
MethodPOST
Request HeaderContent typeapplication/x-www-form-urlencoded
Request Bodygrant_typehttp://oauth.net/grant_type/jwt/1.0/bearer
assertion
(実際は Symmetric Key でデジタル署名したもの)
{
"alg": "HS256",
"typ": "JWT"
}
{
"aud": "00000001-0000-0000-c000-000000000000/accounts.accesscontrol.windows.net@[TenantContextId]",
"iss": "[AppPrincipalId]@[TenantContextId]",
"nbf": "[UNIX 時間で現在の時刻]",
"exp": "[UNIX 時間でTokenの有効期限]"
}
resourceresource : 00000002-0000-0000-c000-000000000000/directory.windows.net@[テナントID]

 Assertion の部分を作り方は少々面倒ですが、下記の通りです。

 ・ヘッダ部分を Base64 でエンコード

  文字列「{"alg": "HS256","typ": "JWT"}」をこのあたりのツールで Base64 URL エンコードします。

  結果、「eyJhbGciOiAiSFMyNTYiLCJ0eXAiOiAiSldUIn0」という文字列が得られます。



 ・ボディ部分を作成

  JWT を構成する、nbf(Not Before / 有効開始時刻)、exp(Expiration Time)クレームは UNIX 時刻(1970年からの経過秒数)で表すため、このあたりのツールを使って現在時刻および現在時刻+1時間を変換した値を取得します。

  例えば、2012年9月25日23時00分00秒~2012年9月26日00時00分00秒まで有効なトークンを作成するには、
  "nbf" : "1348581600",
  "exp" : "1348585200"
  というクレームを設定します。

  結果、以下の様な JWT ボディを作成します。
  {
   "aud": "00000001-0000-0000-c000-000000000000/accounts.accesscontrol.windows.net@[TenantContextId]",
   "iss": "[AppPrincipalId]@[TenantContextId]",
            "nbf": "1348581600",
            "exp": "1348585200"
  }

 ・ボディ部分を Base64 でエンコード

  先ほどのヘッダ部分と同様に生成した JWT のボディも Base64 URL エンコードします。

  結果、「eyJleHAiOiIxMzQ4NTU5MTY4IiwiYXVkIjoiM(以下略)」といった文字列が得られます。

 ・ヘッダ+ボディを連結した raw token と SymmetricKey でデジタル署名を生成

  ヘッダ部分とボディ部分を"."(ピリオド)で連結した raw token を作成し、SymmetricKey を Base64 デコードした文字列を使ってデジタル署名を生成します。

  良いオンラインツールがなかったので、以下の Java コードを作成し、署名を生成しました。
  ※Java であることに深い意味はありません。手元に eclipse が起動していた&Java のサンプルがあった、というだけです。
  ※どなたか良いオンラインツールがあれば教えてください。


import javax.crypto.spec.SecretKeySpec;
import javax.crypto.Mac;
import org.apache.commons.codec.binary.Base64;

public class GenerateSignature {

    private static byte[] signData(String signingKey, String rawToken) {
        SecretKeySpec secretKey = null;
        secretKey = new SecretKeySpec(Base64.decodeBase64(signingKey), "HmacSHA256");
        Mac mac;
        byte[] signedData = null;
        try {
            mac = Mac.getInstance("HmacSHA256");
            mac.init(secretKey);
            mac.update(rawToken.getBytes("UTF-8"));
            signedData = mac.doFinal();
        } catch (Exception e) {
            System.out.println("signData error");
        }        
        return signedData;
    }
    /**
     * @param args
     */
    public static void main(String[] args) {
        String signingkey = "Li7Awy53cq(以下略。SymmetricKey文字列)";
        String rawToken = "eyJhbGciOiJ(以下略。ヘッダ部分)).eyJleHAiOiIxMzQ4(以下略。ボディ部分)";
        String signature = Base64.encodeBase64String(signData(signingkey,rawToken));
        System.out.println(signature);
    }

}

 ・Assertion の生成

  生成した署名文字列を先ほどの raw token の後に同じく"."(ピリオド)で連結します。



 このようにして作成した Assertion を他のパラメータと一緒に ACS へ POST します。
 リクエストの POST は Chrome Extension の Advanced Rest Client を使いました。

 以下の様にパラメータをセットし、[Send request]ボタンをクリックします。


 うまくいくと、HTTP 200 が返ってきて、JSON 形式で Access Token が取得できます。




■取得した Access Token で Graph API を利用する(REST Client ⇒ Graph API)

 いよいよ Graph API を使います。

 リクエスト先および内容は以下の通りです。

Target Endpointhttps://directory.windows.net/[テナントドメイン名].onmicrosoft.com/Users
MethodGET
Request HeaderAuthorization取得した Access Token 文字列(bearer 以降)
x-ms-dirapi-data-contract-version0.8


 先ほどと同様に Advanced Rest Client にパラメータをセットして、[Send request]ボタンをクリックします。


 うまくいくと、HTTP 200 が返ってきて、ユーザ一覧が取得できます。



尚、書き込みを行う場合はロール設定が必要になるので、このあたりは次回以降で。。

2012年7月13日金曜日

[WAAD]Graph API で Office365 アカウントを管理する


Windows Azure Active Directory(WAAD)は Office365 などで利用されるマイクロソフトのオンライン・ディレクトリ・サービスです。
ということは Office365 のユーザ情報は WAAD 内にストアされており、Graph API で管理することが出来る、ということになります。

早速、Office365 のユーザの情報を Graph API で取得してみたいと思います。

まず当然ですが Office365 上にユーザを作っておきます。


このユーザ情報を Graph API を試すためのツールである Graph Expolorer を使って取得してみます。

このツールの Resource の値に
  - https://directory.windows.net/sub02adfs.onmicrosoft.com/Users
という形で対象ドメインと取得リソースを指定すれば値が取得できるはずです。



早速、GET をクリックしてみると、、、当然認証が走ります。

この中の Principal Id とか Symmetric Key とは何を指しているのかが、よくわかりません。

このあたりのドキュメントを読むと Graph API を使うには Service Princial を作成するという作業が必要の様です。
 - How-to Procedure: Authenticate To Windows Azure AD Graph Using Windows Azure AD Access Control
   http://msdn.microsoft.com/en-us/library/hh974468

具体的には Office365 の Powershell コマンドレットを使って Service Principal Id を取得するスクリプトを実行する必要があります。
※事前に Microsoft Online Servies サインインアシスタントも必要


ただ、面倒なので既に用意されているスクリプトを使いましょう。
 - PowerShell authorization script
   http://iddemo.blob.core.windows.net/files/CreateServicePrincipal.ps1

上記は直リンクですが、CodePlex で公開されているサンプルアプリケーションの中にもスクリプトが含まれていますので、そちらを利用しても良いでしょう。

 - サンプルアプリケーション
   http://code.msdn.microsoft.com/Sample-App-for-accessing-d71122ff

この中の「C#\PowerShell Scripts」の中に、CreateServicePrincipal.ps1 が上記からダウンロードできるスクリプトと同じものです。


このスクリプトを実行すると Service PrincipalName の指定するように要求されるので、任意の名前を入力します。

Windows Azure Active Directory 内でのユニーク性のチェックが行われ、問題なければマイクロソフト・オンライン・サービスの認証が走り、4つの値が払い出されます。

・Company ID
・AppPrincipal ID
・App Principal Secret
・Audience URI

この値の中の、AppPrincipal ID が先ほどの Graph Explorer の Principal Id、App Principal Secret が Symmetric Key に対応しているので、先ほどのログイン画面でその値を入力しログオンするとユーザの情報が表示されます。
※他の値については SSO を行う際に使うものなのでそのうち紹介したいと思います。


さきほど Office365 上に作ったユーザも確認できます。


今回は単に一覧を表示するだけでしたが、当然追加・変更・削除も出来るので、今後は Office365 へのプロビジョニングを DirSync に頼らなくても出来る様になってくると思います。
TechEd North America のセッションを見ていると既に FIM 2010 用の Graph API Management Agent を開発している会社もあるようなので、より柔軟にオンライン・アカウントを管理出来る様になってくると思います。


Windows Azure Active Directory Developer Preview が公開


European Identity Conference の Keynote で Kim Cameron 氏が語った Microsoft の IDMaaS(Identity Management as a Service)の実現である Windows Azure Active Directory の Developer Preview がアナウンスされました。

 - Windows Azure Team blog
   Announcing the Developer Preview of Windows Azure Active Directory
   http://blogs.msdn.com/b/windowsazure/archive/2012/07/12/announcing-the-developer-preview-of-windows-azure-active-directory.aspx

 - Vibro.NET / Vittorio Bertocci
   Single Sign On with Windows Azure Active Directory: a Deep Dive
   http://blogs.msdn.com/b/vbertocci/archive/2012/07/12/single-sign-on-with-windows-azure-active-directory-a-deep-dive.aspx


あわせて、各種ドキュメントやサンプルツールなどもリリースされています。

 - MSDN ドキュメント
   http://msdn.microsoft.com/en-us/library/hh974476

 - サンプルアプリケーション
   http://code.msdn.microsoft.com/Sample-App-for-accessing-d71122ff

 - Graph Explorer / テスト用ツール
   https://graphexplorer.cloudapp.net


更に興味深いのが Kim Cameron 氏が 最新の blog エントリ「Yes to SCIM. Yes to Graph.」で語っている Graph API と SCIM(Simple Cloud Identity Management)の関係です。


エントリの中で Kim 氏は基本的に SCIM の目指しているゴールをサポートしており、マイクロソフトとして取り組みを支援する姿勢を見せています。

しかし、何故マイクロソフトは SCIM を採用せずに Graph API を検討しているのか?という疑問に対する解として以下の2点を挙げています。

1.多様なオブジェクトが相互に多様な関係性の中に存在する環境において Graph API は検索や操作性において統合されたアプローチを提供するため。

 つまり、SCIM で提供されているスコープ(現状はユーザとグループオブジェクト)以上のオブジェクトと複雑な関係性を表現する上では Graph API の方が向いている、ということでしょうか。

2.巨大なスケールにおいてディレクトリは「多次元ネットワークを表現するものに変化する」ため。

 今後のディレクトリ内にストアされるオブジェクトは全てにつながり、多くのディメンジョンを持つことになるため、 オブジェクトを扱うためには Graph API が必要だ、ということでしょうか。
 例として、レガシーなディレクトリは組織や人やグループなどのオブジェクトを持っていて、組織は人を含み、グループは階層化されている、という様な構造を持っていましたが、ソーシャル構造を表現する必要が出てきている、という話が挙げられており、レガシーな単一指向性のディレクトリでは構造を表現することが不可能になってきている、という主張なのだと思います。


Kim Cameron 氏は次の blog エントリでも Windows Azure Active Directory のリリースについて書く、と宣言しているのでしばらくは目が離せそうにありません。

2012年5月26日土曜日

[IDaaS] ようやく流行ってきた?


1年半ほど前に IDaaS について紹介しましたが、ここにきて続々とサービス化がされてきています。

5/24 の Intel Cloud SSO に関する記事です。
インテル、クラウド型シングル・サインオン・サービス「Cloud SSO」をリリース

5/23 の Windows Azure Active Directory に関する公式 blog ポストです。
Reimagining Active Directory for the Social Enterprise (Part 1)

同じく 5/23 の Kim Cameron 氏の blog です。
Identity Management As A Service


他にもクラウド・アイデンティティ界の雄である PingIdentity が日本にオフィスを開設したり IIJ と協業を開始してサービスを開始したり、ちょっと前ですが salesforce.com が SAML RP だけでなく IdP としても動作するようになりました。


最近の IDaaS の特徴を見ていると、

  • フェデレーション
  • プロビジョニング
  • 認証強化

の3つの機能要素で構成されています。

それぞれの機能についてどんな選択肢が用意されているのか、が差別化の要因になると思います。

  • フェデレーション
    • 対応プロトコルはもちろん、接続先があらかじめメニューとして組み込まれていたりウィザードで簡単に設定できる、という部分が強みとなると思います。
  • プロビジョニング
    • サービス側の対応がまだ限られているので Google Apps、salesforce.com、WebEx、Office365 など限定的ですが実際には一番管理者にとってメリットが出る部分なので今後のサービス側の対応が望まれます。
  • 認証強化
    • ワンタイムパスワード(OTP)や SeucureID、IP 制限、モバイル対応など色々と選択肢がありますが、インターネット経由のアクセスを考えるとここも気になる点だと言えます。


現段階でのメジャーなサービスを比べてみます。(Windows Azure Active Directory の詳細はこれからなので微妙ですが)

ベンダサービス/製品特長フェデレーションプロビジョニング認証強化
IntelIntel Cloud SSO対応APLが多数○(サービスによる)OTP、IP制限、モバイル、時間帯、曜日
MicrosoftWindows Azure Active DirectoryOffice365連携Office365AD FS2.x ベースのカスタマイズ
PingIdentityPingFederateオンプレミス○(サービスによる)証明書、RSA SecureID、Symantec VIP、PhoneFactor
※ちなみに Intel は IAMaaS 、Microsoft は IdMaaS という表現を使うこともあります。

後は、やはり CSA のガイドライン対応や LoA などプロバイダの信頼性が一番気になるところかと。
また日本国内での普及についてはアイデンティティ情報がサービスプロバイダ側での物理的配置の問題など色々と気にすることになると思いますので、そのあたりを踏まえると国産の IDaaS プロバイダがもっと前面に出てくると良いかな、、と思います。

2012年1月26日木曜日

AppFabric ACSの構成をバックアップする

昨日の朝、こんなアナウンスがありました。



重要なお知らせ – Windows Azure アクセス制御サービスの設定情報確認のお願 
お客様各位、

マイクロソフトは、Windows Azureアクセス制御サービス(ACS)の設定情報(証明 書利用者、IDプロバイダー、ルールなど)が、ある条件下で予期せずに損失する こと検出・修正しました。この修正は、日本時間2011月12月12日午前11時に実行 いたしました。この障害は一部のお客様のみ発生しております。のため、お客 様のACSの名前空間が正しく設定されているかご確認お願いいたします。

対象バージョン: Windows Azure Access Control Service 2.0

この度は、ご迷惑をおかけしたことを深くお詫び申し上げます。不明な点がご ざいましたら、https://www.windowsazure.com/ja-jp/support
    カスタマー サポート までお問い合わせください。 

クラウド上で提供されているサービスについても障害に備えてバックアップを取っておく必要がありそうです。

こんな時に役に立つのが以前紹介した、「Windows Azure PowerShell Comandlets」です。
http://wappowershell.codeplex.com/releases/view/66308#DownloadId=240649

このコマンドレッドをインストールすると、サンプルとして ACS の設定のインポート/エクスポートスクリプトが提供されます。

このスクリプトを実行すると以下のように設定がエクスポートされます。


> ExportNamespace.ps1 "ACSネームスペース" "マネージメントキー" "出力ファイル名"
Adding AcsManagementToolsSnapIn Snap-in...
Getting all the Identity Providers from sso-test namespace...
Getting all the Relying Parties from sso-test namespace...
Getting all the Rule Groups from sso-test namespace...
Getting all the Service Keys from sso-test namespace...
Getting all the Service Identities from sso-test namespace...
Serializing all the information in sso-test namespace to the 出力ファイル名 file...

Done

ファイルの中身を見るとこんな感じで設定がエクスポートされています。


















インポートする際はこの逆で ImpoerNamespace.ps1 を実行することになります。


もしもの時に備えて設定をエクスポートしておくことをおすすめします。

2011年12月13日火曜日

Windows Azure Active Directory


Azure 方面では大幅アップデートでお祭り状態?になっているみたいですが、ひっそりとアイデンティティ関連に関してもアナウンスがされています。
詳細はこれから徐々に出てくると思われますが、現状出ている情報から見えるところだけとりあえず。


まず、タイトルが「Windows Azure Active Directory」になっています。
http://www.windowsazure.com/en-us/home/tour/access-control/

少しずつ本文から抜粋します。
Windows Azure Active Directory is a cloud service that provides identity and access capabilities for applications on Windows Azure and Microsoft Office 365. Windows Azure Active Directory is the multi-tenant cloud service on which Microsoft Office 365 relies on for its identity infrastructure. 


Windows Azure 上のアプリケーションおよび Office365 用のアイデンティティ&アクセス機能を提供、とあります。
これまで、似たようなサービスではありましたが、全く別の基盤として稼働してきた AppFabric ACS と Office365 のアイデンティティ・プラットフォームでしたが、ついに統合?されることになりそうです。(単なるブランド統合だけかもしれませんが)

【参考】
これまでの Office365 のアイデンティティ・プラットフォーム。
ACS と同様に AD FS2.0 とのフェデレーションが出来ましたがあくまで Offce365 専用。

































こんな記述もあります。
You can enable single sign-on, security enhanced applications, and simple interoperability with existing Active Directory deployments using Access Control Service (ACS), a feature of Windows Azure Active Directory

AppFabric ACS の位置づけが明確に Windows Azure Active Directory の一機能とされています。

こんな記載もあるので、やれることとしては既存の Active Directory と一緒に使うことによって SSO などを実現、とあるのでそれほど変わらないのかと。
You can quickly extend your existing on-premises Active Directory authentication to your cloud applications through ACS. By using your existing user directory as the authoritative identity provider, users are authenticated to your cloud applications with their existing accounts.   


標準技術への対応に関する記述は以下の通り。OpenID 2.0 との記載は以前からありましたが、OpenID Provider の追加は非サポートでした。今後はどうなるのかちょっと期待。
Integrated and customizable Home Realm Discovery so users can choose their identity provider with support for Windows Live ID, OpenID 2.0, Google, Yahoo, Facebook, and enterprise providers such as Windows Active Directory.


その他ですが、最近の Azure 界隈はかなり OSS に寄っている気がします。以下の記述を見ても Ruby の記述があるあたりが OSS 開発者を強く意識しているのかな?と思います。
ACS is compatible with virtually any modern web platform, including .NET, PHP, Python, Java, and Ruby, and has out-of-the-box support for popular web identity providers including Windows Live ID, Google, Yahoo!, and Facebook. 


今回はまだリリースされている情報が少ないので、機能面ではあまり見えておらず、単なるリブランディングなのか?とも思えますが、引き続き要ウォッチです。

A Guide to Claim-Based Identity and Access Control 2.0 の eBook 版がリリース


以前のポストでも紹介したとおり、先日第2版もリリースされたお馴染み Claims Guide ですが、このたび eBook 版がリリースされています。
MSDN のサイトで公開されていたものです)

PDF でダウンロード出来るのでお手元のモバイル端末へ入れておくのが吉かと。
http://www.microsoft.com/download/en/confirmation.aspx?id=28362



2011年12月1日木曜日

OAuth 2.0 仕様書の翻訳版リリース!

AppFabric ACSv2 や WIF を使ったり、facebook をはじめとするソーシャル API を使おうとすると避けて通れないのが OAuth です。

これまでも OpenID Technight などで仕組みの解説がありましたし、一部当ブログでも紹介しましたが、厳密に知ろうと思うと原文のスペックを読むしかなく、ハードルが高かったのが現状です。

そんな方に朗報です!
OpenID Foundation Japan の翻訳ワーキンググループの活動で OAuth 2.0 core draft 22 および Bearer draft 11 の仕様書の日本語版がリリースされました。
(私も一部お手伝いをさせていただきました)

http://openid-foundation-japan.github.com/

ぜひ、一度ご覧いただければと思います。

2011年9月20日火曜日

ACS の Facebook 連携利用ガイド

先日の OpenID Technight vol.8 @ 大阪でも触れましたが、時間もなかったので簡単にしか話が出来なかったので、振り返りつつ解説をしていきたいと思います。

■ACS の機能のおさらい

AppFabric ACS v2 は Windows Azure 上にデプロイされたクラウド上の STS / Federation Provider です。主な機能は「外部 Identity Provider から発行されたセキュリティ・トークンの形式を変換して、要求元のアプリケーションへ渡すゲートウェイ機能」であり、対応するプロトコルとしては ws-federation、OpenID、OAuth2.0 などがあります。
ざっくりいうと Yahoo!やGoogle、facebookなどで発行されたセキュリティ・トークンを ws-federation に乗せた SAML トークンとして Windows Identity Foundation(WIF)を使った .NET アプリケーションへ渡す、という役割を持ちます。
このことによって各 .NET アプリケーションは Yahoo! や Google に対応する形で個別のコードを記述する必要がなくなり開発効率があがる、というのが最大の利点といえます。





















■ACS の Facebook 連携とは

ACS の Facebook 連携は OAuth2.0 が利用されています。具体的に言うと、Facebook の認可サーバ(AuthZ Server)からアクセス・トークンを取得するのがここで言う連携の最大の目的であり実体です。

以下の図でいう OAuth AuthZ Server / OAuth Resource Server が Facebook に当たります。ACS は Facebook からアクセス・トークンを取得しています。




















■混同しやすい点

ここが最大の注意点なのですが、Yahoo! や Google、オンプレミスの AD FS2.0 との連携に使われる OpenID や ws-federation といったプロトコルと OAuth2.0 は若干性質が違います。
例えば ACS の Google 連携 では(おそらく)OpenID Authentication を利用しているのであくまで認証の外部化を目的としていますし、AD FS2.0 との連携では ws-federation を利用しているので認証およびクレームの伝搬を目的としています。
しかし、Facebook 連携に使用している OAuth2.0 は基本的には「保護されたリソースへアクセスするための認可を受けること」を目的としています。つまり、認証自体を目的としている訳でも、Facebook 上の属性をクレームとして伝搬することを目的としている訳でもありません。
ただ、結果として ACS を経由することで .NET アプリケーションは個別に認証機能を実装する必要はなくなりますし、ある程度のクレーム情報については取得することが出来てしまいますので、認証を受けて名前やメールアドレスを取得する、という目的での利用をすることも可能ではある訳です。

Facebook から取得したクレーム









■Facebook 連携の使い方

では、本来(?)のACS / Facebook 連携の使い方、というより OAuth の使い方はどのような物なのでしょうか?
先ほどの Facebook から取得したクレームの中に claimType が http://www.facebook.com/claims/AccessToken となっている物がありました。これが ACS が Facebook から取得したアクセス・トークンです。
本来は Facebook の保持するリソースに対して API アクセスを行うために Facebook の認可サーバがクライアント(RESTful Web Service)に対して払い出すのがこのアクセス・トークンであり、ACS の Facebook 連携においては ACS が Facebook から見てクライアントとなります。
しかし、一番最初に書いた通り、ACS は「ゲートウェイ」なので、Facebook から取得したアクセス・トークンを SAML トークンの1つの Assertion として変換し、ws-federation プロトコルに乗せて WIF を使った .NET アプリケーションへ渡します。

それが、先にも出したこの図の左半分です。




















後は、 .NET アプリケーションが受け取ったアクセス・トークンを使って Facebook の API へアクセスしリソースの取得や各種操作を行う、というのが本来の Facebook 連携を行う意味合いに沿った使い方、ということになります。

例えば、Facebook から誕生日情報を取得したければ、例えば以下の様なコードを書くことになります。
var f_birthday = new WebClient().DownloadString(@"https://graph.facebook.com/me?fields=birthday&access_token=" + [ACS より取得したアクセス・トークン]);
var json = DynamicJson.Parse(f_birthday);
TextBox1.Text = json.birthday;


内容ですが、Facebook の graph API (http://graph.facebook.com)に対して自分の誕生日(me?fields=birthday)を取得したアクセス・トークンをパラメータとして付与(access_token=[ACS より取得したアクセス・トークン])して HTTP/GET する、というものです。
結果、json 形式で誕生日の文字列が返却されますので、例では Dynamic JSON(http://dynamicjson.codeplex.com/)を使って文字列をパースしてテキストボックスに表示をさせています。

同様に Facebook のウォールへの投稿の例です。
System.Collections.Specialized.NameValueCollection ps = new System.Collections.Specialized.NameValueCollection();
ps.Add("access_token", [ACS から取得したアクセス・トークン]);
ps.Add("message", [投稿したいメッセージ]);
WebClient wc = new WebClient();
byte[] resData = wc.UploadValues(@"https://graph.facebook.com/me/feed", ps);
wc.Dispose();


今度は HTTP/POST メソッドを利用した例ですが、考え方は同じで ACS から取得したアクセス・トークンおよび投稿したいメッセージを graph API の me/feed に与える、というやり方です。


■アクセス・トークンの扱いについて

ここまで ACS の Facebook 連携の使い方について整理をしてきましたが、1点注意をすべき点としてアクセス・トークンの取り扱いがあります。
これは OAuth を使ったアプリケーション全般に言えますが、取得したアクセス・トークンはあくまで文字列なので他のアプリケーションから再利用することが出来てしまいます。その意味でアクセス・トークンは Facebook のリソースへアクセスするための「合鍵」と言うことが出来ます。

例えば、取得したアクセス・トークンをコピーして全く別のアプリケーションから Facebook のリソースへアクセスすることも出来てしまいます。

フォームアプリケーションに取得したアクセス・トークンをコピーして Facebook のリソースへアクセスする例




















このようなことを防ぐためにもアプリケーション開発者は取得したアクセス・トークンが外部に漏れないように保護することが必要です。
また、これも当然ですが ACS に設定する Facebook へのアクセス許可の範囲については必要最低限に絞っておくことが肝要です。



















尚、アプリケーションの許可フィールドに設定可能な Facebook の Permission 一覧は以下のページを参照してください。(Facebook へのログインが必要です)
http://developers.facebook.com/docs/reference/api/permissions/


■参考資料

・ACS / Facebook 連携手順
 MS 安納さんの資料
 https://skydrive.live.com/?cid=2bd8b3552eedd654&sc=documents&id=2BD8B3552EEDD654%214073
・OpenID / OAuth の違い
 NRI 崎村さんの blog
 http://www.sakimura.org/2011/05/1087/


■おまけ

最後に先日の OpenID Technight の資料をアップしておきます。

2011年9月16日金曜日

Claim-Based Identity and Access Control の第2版がリリース

ずっとベータ版だった Microsoft Patterns & Practices の A Guide to Claim-Based Identity and Access Control の第2版がリリースされました。
※ちなみに第1版は書籍化もされ Amazon でも購入可能です。
 また、日本語化されて technet で公開されています。
 http://technet.microsoft.com/ja-jp/library/gg457904.aspx


以下のURLで参照およびサンプルコードのダウンロードが可能です。
 http://msdn.microsoft.com/en-us/library/ff423674.aspx


さて、気になる内容ですが大幅に増強されています。
以下が第1版、第2版それぞれの目次です。

第1版

























第2版
























大きくは、
・Windows Azure Access Control Service
・SharePoint
・RESTful Web Service
・Windows Phone
といったキーワードに関する記述が新たに増えています。

現在開催中の//build/での Windows 8 の発表にあった Windows LiveID での OS ログインや、LiveID に絡めることで デバイス間でのトークンのローミングを実現する Credentials Vault など今後も色々な機能が続々とリリースされることになりそうなので、要注目です。

2011年8月23日火曜日

9/9 OpenID TechNight Vol.8 in 大阪 が開催されます!

これまで Identity 関連の技術セミナが大阪で開催されることは殆どなかったのですが、今回初めて東京で大好評の OpenID TechNight が開催されることになりました。

このブログでも LiveID の OpenID 対応のエントリや AppFabric ACS への OpenID Provider の登録に関するエントリなど、 OpenID に関連するトピックスを紹介してきました。

なかなかエンタープライズでの利用シナリオが想像されないま状態が続いていますが、 OpenID 自体は各種ソーシャル・サービスで浸透来ていることもあり、コンシューマ向けのサービス開発者の方々を中心にこの OpenID TechNight は毎回大好評だったイベントです。

また、最近は OAuth2.0 との親和性も手伝って OpenID Connect という新しい考え方もホットで、米国 OpenID Foundation 理事の @_natさんを中心に Microsoft の Mike Jones 氏など ws-* や SAML の仕様を策定していた方々が集まって日々スペックを書いているようです。

今回のイベントは 8/5 に東京で開催された OpenID TechNight Vol.7 に引き続き OAuth2.0 / OpenID Connect を中心としたトピックが満載の予定です。(東京での Vol.7 には 100名以上の参加があったようです)

私も実は登壇予定で、開発者向けということで Windows Identity Foundation / AppFabric ACS を中心に OAuth や OpenID に関連した具体的なコードやデモを紹介しようと思います。具体的には ACS 経由で取得した Facebook のアクセス・トークンを SAML トークンに変換したものを WIF で Windows Azure 上にデプロイしたアプリケーションに渡し、Facebook Graph API を使って、色々と Facebook を弄ぶ、などといったことを考えています。

参加申し込み方法は以下のイベント紹介文の中に載っているので、これまで「良さそうなイベントだけど東京だよね~~」と思っていた関西人の方は是非ともご参加ください。


======================================================================
毎回好評のID専門セミナーが初の大阪開催! いまやWeb APIに欠かせない
OAuth/OpenIDの最新動向から、実サービスへの適用まで学べます!
======================================================================

9/9(金)OpenIDファウンデーション・ジャパン主催で、技術者向け無料セミ
ナー "OpenID TechNight Vol.8 in 大阪" を開催いたします。仕様が策定中の
OpenID Connect と OAuth 2.0 の最新状況や、ID プロバイダーの取り組みにつ
いてご紹介します。

お申し込みは以下のいずれかのサイトからお願い致します。
http://atnd.org/events/19093
http://www.openid.or.jp/modules/news/details.php?bid=46
----------------------------------------------------------------------
■日時:
 2011年 9月 9日(金) 16:00 ~ 18:30(開場15:30 ~)

■場所:
 株式会社ケイ・オプティコム 16階 会議室
(大阪市北区中之島3-3-23 中之島ダイビル)
 http://www.k-opti.com/company/access/

■プレゼンテーション(予定):

・「OpenID Connect latest spec」 by @ritou
・「OAuth latest spec」 by @nov
・「Microsoft の Restful Identity」 by @phr_eidentity
・「eoID の OpenID 化について」 by K-Opticom

■対象:
・Restful な Identity 技術にご興味をお持ちの方。
・Twitter / Facebook / Google / mixi などの API を触ったことがある方、
 これから勉強してみたいと思っている方。

■インターネット中継:
 当日の模様は Ustream の以下の URL にて中継する予定です。
 http://www.ustream.tv/channel/openid-tech-night

■Twitterハッシュタグ:
 #openid #technight


■過去の模様はこちら:
・2011/08/05 OpenID TechNight Vol. 7
 http://atnd.org/events/18104
・2010/05/28 OpenID TechNight Vol. 6
 http://gihyo.jp/news/report/2010/06/0101

WIF Extension for OAuth CTP1 を試してみる

4月にリリースされてからしばらく時間がたちますが、Windows Identity Foundation Extension for OAuth CTP 1-4(WIF Extension for OAuth)の中に入っているサンプルを動かしてみたいと思います。


■サンプルの内容
このサンプルでは AppFabric ACS を OAuth の認可サーバとして利用し、Contoso Customer Information サービスから顧客情報をユーザの同意に基づき取得する、というシナリオです。













登場するコンポーネントは、

・ユーザ:ブラウザ
・コンシューマ:Fabrilam Information Portal(WIF Extension for OAuth を利用したクライアント)
・認可サーバ:ACS2.0
・リソースサーバ:Contoso Customer Information Service(WIF Extension for OAuth を利用した OAuth Protection モジュール)

の4つで、各コンポーネントのアクセスフローは以下の通りです。
1.ユーザがコンシューマへアクセスする
2.コンシューマはリソースサーバのログオンページへリダイレクトする
3.ユーザはIDとパスワードでリソースサーバで認証を受ける
4.ユーザはリソースへのアクセスに関する同意を行う
5.リソースサーバは認可サーバから認可コードを取得する
6.リソースサーバは認可コードをコンシューマへ渡す
7.コンシューマは認可コードを元に認可サーバからアクセストークンとリフレッシュトークンを取得する
8.コンシューマはアクセストークンをリソースサーバへ渡しリソースを取得する
9.コンシューマは取得したリソースをユーザへ返す

図示すると以下の様な形になります。
















■サンプルのセットアップ準備
早速ですがサンプルをセットアップしてみます。まずは必要物をそろえます。
現在 CTP 版のモジュールは connect サイトでダウンロードできます。

  ダウンロードURL:https://connect.microsoft.com/site1168/Downloads

また、前提となる環境は以下の通りです。
  PC(私は Windows 7 x64 を利用しました)
  ・IIS
  ・Visual Studio 2010
  Windows Azure AppFabric Access Control Service
  ・v2 で適当な名前空間を一つ


■サンプルのセットアップ
1.ACS へサービス ID を追加する
 ACS のサービスの設定 -> サービス ID よりサービス ID を追加し、以下の情報を設定します。

 サービス ID の設定
  名前:FabrikamClient
 資格情報の設定
  型:パスワード
  パスワード:FabrikamSecret






















2.ACS へ証明書利用者アプリケーションを追加する
 同じく ACS より Relying Party ( 証明書利用者アプリケーション ) を追加します。

 証明書利用者アプリケーションの設定
  名前:Customer Information Service
  領域:http://contoso/CustomerInformationService/
  戻り先URL:http://localhost/
  トークン形式:SWT
 認証の設定
  IDプロバイダー:チェックを外す
 トークン署名キー
  生成 をクリックして生成する









































3.Visual Studio でサンプル・ソリューションを開き編集する
 次は先ほどのダウンロードしたモジュールを解凍した中にある「OAuth with ACS.sln」を管理者として開き、以下の設定を行います。

・SamplesConfiguration.cs の編集
  ServiceNamespace : ACS の名前空間
  ManagementServiceIdentityKey : 管理サービスの ManagementClient の資格情報の対象キーの値
  RelyingPartySigningKey : 2で設定した証明書利用者アプリケーションのトークン署名キーの値
















・ソリューションエクスプローラから ConfigureAcsConsoleApplication を右クリックして「デバッグ -> 新しいインスタンスを開始」をクリック
  → コンソールが起動するので、 Press any key to exit と表示されたら何かキーを押してアプリケーションを閉じる
 ※このコンソールアプリケーションが ACS の IdP 設定などを行います。














・HTTPSでのアクセスを行う際のチェックを無効化する(そのままだとWeb例外「"基礎になる接続が閉じられました: SSL/TLS のセキュリティで保護されているチャネルに対する信頼関係を確立できませんでした"」が発生する)

 WebClient の Defalut.aspx.cs の GetAllInformation メソッドの初めに以下のコードを追加する
 if (System.Net.ServicePointManager.ServerCertificateValidationCallback == null)
 {
  System.Net.ServicePointManager.ServerCertificateValidationCallback += delegate(Object sender, System.Security.Cryptography.X509Certificates.X509Certificate certificate,System.Security.Cryptography.X509Certificates.X509Chain chain, System.Net.Security.SslPolicyErrors sslPolicyErrors)
  {
   return true;
  };
 }


・ソリューションをビルドする


■サンプルの実行
 いよいよソリューションの実行です。

1.ブラウザより https://localhost/WebClient/ へアクセスする
  画面が表示されたら Populate all data をクリックする











2.CONTOSO CUSTOMER INFORMATION SERVICE へログオンする
  ログオン画面へリダイレクトされるので
  ・User Name : john
  ・Password : password
  を入力してログインする


















3.リソースへのアクセスに関する同意を行う
  同意を求められるので Yes を選択し、Submit する












4.リソースの表示
  元の画面にリダイレクトされ、リソースが表示される















  同様にアクセストークン、リフレッシュトークンに関する情報も表示されます。











いかがでしょうか? SAML もそうですが、OAuth もやはり実際の動きを見てみないと動きのイメージがつかないものだと思いますので、イメージをつかむためにも一度実際に動くものを見てみるのが理解を早めると思います。一度是非試してみてください。