Geneva Whitepaper

Geneva Whitepaper が見つかりましたよ ～～～

やはり、David Chappell さんが書いていました。何となく、難しそうだなぁ という感じです。以下の URL からダウンロードできますので、ご興味ある方は ど～ぞ。

http://www.microsoft.com/downloads/details.aspx?FamilyID=9ca5c685-3172-4d8f-81cb-1a59bdc9f7e3&displaylang=en

それと、CardSpace を調べていたら、2006 年に InfoSpace 社を買収して、それが WinFX の一部として取り込まれたという、つまり .NET Framework 3.0 に入ってきたという経緯がわかりました。

さらに、以下の日本語文献も見つけました。2006年に、Vista のデビューに合わせて翻訳されたようです。InfoSpace から、CardSpace に名称変更された直後のホワイトペーパーのようで、とても上手に訳されていますが、大もとの文章が難解という感じがします。

Windows CardSpace の紹介
http://msdn.microsoft.com/ja-jp/library/aa480189.aspx

その原文は、こちらでして、やはり David Chappell さんです。

Introducing Windows CardSpace
http://msdn.microsoft.com/en-us/library/aa480189.aspx

こちらの原本と、新しい Geneva Whitepaper を見比べてみると、2006 年版をベースにして、2008 年版が作られている様子がわかります。

時間があったら訳してみたいのですが、、、 いまは チョッと忙しいのが残念です。

Access Control Service

Access Control Service って、これで合ってます?

Access Control Service ですが、Chappell さんのホワイトペーパーは難しいですよね。以下のような解釈でも合っているのでしょうか?  おそらく、Eugenio さんの Issue Tracker は、こんな感じのことを言っているのかと思います。

ーーーーーーーーーーーーー

不特定多数のユーザーがアクセスする、クラウド上のWebサービスでは正確で使いやすい認証のメカニズムが必要とされる。しかし、現状においては、オンプレミスとクラウドの認証が統一されることはなく、ユーザーが数個あるいは数十個の、IDとパスワードを管理せざるを得ないという問題が、あちらこちらで起こっている。こうした問題を改善し、IDの共通性を高めていくためのアプローチが、Azure では具体化されている。

たとえば、Active Directory を用いるオンプレミス･データセンターと Azure の間で、ID を共通化させるためのアイデンティティ･フェデレーションを利用し、社内ネットワーク用の AD の ID を用いることで、Azure 上のサービスなどへのアクセスが実現される。これも、クラウドとオンプレミスの対称性を考慮したアーキテクチャであり、安全性を保ちつつ、ユーザーの利便性を向上させるものとな～～～る。

ーーーーーーーーーーーーーー

それと、肝心の Security Token Service (STS) ですが、Terminal Services のドキュメントを読んでいたら、こんなことが書いてありました ↓

ーーーーーーーーーーーーーー

自身で証明書を発行する：TS Gateway がセキュア･ゾーンに配置される場合には、証明書はローカルで生成され、TS Gateway もしくは SSL ターミネータに配置される。続いて、コンパニオン証明書が、これから接続される個々のクライアントに配信され、インストールされなくてはならない。インフラストラクチャの設定は必要とされず、また、コストも発生しないが、すべてのクライアント･マシン上に証明書をインストールする作業は、相当量の手間になり得る。

外部のCAを利用する：たとえば VeriSign のような、証明書サービスを有料で提供する、 数多くの信頼できる証明機関（CA）がある。それらの CA  を利用する場合には、クライアントとサーバーは CA を信頼し、そこから提供される証明書を交換する。管理されていないクライアントが Terminal Services 環境に接続する場合には、クライアント･インストールが必要とされないため、この方式は極めて便利な実装となり得る。

証明サーバーを独自運用する：このケースにおいては、クライアントがアクセスするセキュア･ゾーンの外側に、証明書サーバーが配置される。そのため、ハードウェアとソフトウェアに対する投資が必要となり、また、セットアップ作業と継続したメンテナンスも発生する。 それに加えて、すべてのクライアントが、このサーバーを信用するとは限らないという可能性が残る。

ーーーーーーーーーーーーーー

この点は、Azure でも TS でも同じですものね 。。。

Azure Issue Tracker in CodePlex

Azure Issue Tracker が CodePlex に登場です。

http://www.codeplex.com/azureissuetracker

Issue Tracker が CodePlex に出てますよ～～～ との、N さんからの貴重な情報提供がありました。。。。。

（そのうち、日本語にしたいと思ってます ↓ ）

Introduction

This sample demonstrates a real-world SaaS architecture and scenario using the Azure Services Platform to perform federation and multi-tenancy. Technologies used include the Access Control service (part of .NET Services) as well as SQL Data Services (part of SQL Services).

Overview

Azure IssueTracker demonstrates a real-world ISV scenario where you want to create and host a SaaS application for your consumers. This sample is being releasede in two versions: Standard and Enterprise. The Standard version allows ad-hoc users to use LiveID federation with the .NET Access Control Service and authorize other LiveID users. This allows small groups of users to quickly provision projects and issue tracking capabilities.

The Enterprise version of IssueTracker uses the same claims-based authorization capabilities as the standard version, but allows greater control by customers over claims and authorization decisions. Additionally, the Enterprise version offers more premium capabilities like onsite configuration and monitoring in true S+S fashion.

The IssueTracker service itself is a very simple service – providing basic issue management and workflow capabilities. Because the service and the website are claims-aware applications, it allows for some interesting scenarios. Using a single set of claims and authorization logic, both active clients and passive web clients can consume the IssueTracker service. This architecture gives us the best of software on premises with rich UI capabilities as well as the broad reach of web clients – without changing a single line of code to support it.

Coming Features

Enterprise Version of IssueTracker which includes:
Federation with any SAML 1.1 compliant identity provider
MMC management tools – allows your customers to manage your service just like on-premises.
Integration with monitoring – customers can integrate with popular monitoring packages and monitor the health of the service

アイデンティティ･フェデレーションを理解するための貴重なリソースです。

それにしても頑張りますね、Eugenio さん！

.NET Services

もとはと言えば Biztalk Services

ネットワークとセキュリティは、繋いで切るという、コインの裏表です。

この2つの要素がバラバラに設計され、開発されるより、一体化したほうが良いというのは間違いのないところです。

.NET Framework ができたときから、それが意識されていたとは思えませんが、この .NET Services は美しくまとまっていますね。

 Access Control:

トークンと、その中に含まれる Claim を使って、アイデンティティ管理の共通性を高めます。アプリケーションは Claim に基づいて、対象となるユーザーに許可する行為を決定できるようになります。ただし、複数の企業をまたいで一連の処理を効果的に行うためには、単一の Claim を他の企業が受け入れためのアイデンティティ･ フェデレーションが必要となります。そのための Claim 変換が必要となる場合に、クラウドベースの機能が対応します。

Service Bus:

他のアプリケーションからのアクセスを可能とする、Web サービスのエンド ポイントを公開します。ただし、それぞれの公開されるエンド ポイントは URI として割り当てられるため、サービスの特定のために、また、サービスへのアクセスのために、それらを利用できます。また、サービス･バスがネットワーク･アドレス変換を行うため、アプリケーションごとに新しいポートをオープンする必要がなくなります。

Workflow:

アプリケーションの統合などにおいては、さまざまなコンポーネント間ののインタラクションを調整するためのロジックが必要とされます。そして、ロング･ランニング･プロセスをサポートする、ワークフローが最適なソリューションとなります。Windows Workflow Foundation上で構築されたワークフローサービスが、そのためのロジックをクラウド上で動作させます。