.net servicesチームは、.net servicesの提供内容についての計画の詳細を公開した。これらのサービスはAzure services platformの一部分だ。.NET Servicesにはアクセス制御の仕組みが含まれている。これは、開発したアプリケーションとAzure services platform上のサービスの間に安全なコネクションを確立するのに役立つ。さらに、ネットワークや組織の境界を超えた通信するための service busとも安全なコネクションを確立する。
.NET Servicesとソフトウエア開発キット(SDK)の次のCommunity Technology Preview (CTP)バージョンのリリースは10月の予定です。このリリースは実際に商用版としてローンチするサービスと極めて似たものになるでしょう。Microsoft® .NET Service Busは現在のCTPバージョンと比べても、特徴に大きな違いはありません。一方で、Microsoft® .NET Access Control Serviceは、実際にローンチされる.NET Servicesの特徴を盛り込んだものにしていくために、変更点が生まれるでしょう。
興味深いのは、このブログの記事によると、.net servicesへRESTfulにアクセスすることは、Webの開発者の間でもエンタープライズの開発者の間でも、徐々に一般的になっているということだ。この記事では既存のID管理ソリューションにある“欠点”が指摘されている。それは特にアクセス制御と関係がある。
現在、REST形式のWebサービスの開発者には、自身が開発しているWebサービスを保護する簡単な方法がありません。[…] 開発者には、IDとアクセス制御を管理できるRESTと相性のいい方法を、堅牢で再利用可能なパターとして実現することができません。エンタープライズ分野で、開発者がRESTを使おうすれば、セキュリティを強化しなければならないと次第に考えるようになるでしょう。開発者は、エンタープライズ分野の顧客が抱くしっかりと整備されたセキュリティに対する関心や、エンタープライズ製品に必要な複雑なID管理を取り扱いたいと考えるでしょう。そして、このような要求をRESTと統合できる単純な方法で実現したいと思うでしょう。
鍵になるのは、エンタープライズ分野の開発者へ提供するサービスの照準を調整し直すことだ。この記事には鍵になるシナリオが幾つか紹介されている。これらのシナリオは来たるリリースで実現される予定で、開発者のマインドシェアを捉える狙いがある。
.NET Access Control ServiceはWebアプリケーションに対して簡単なアクセス制御を提供します。さらに、Windows Live IDのようなWeb上の認証システムや企業内のディレクトリサービスのような、標準化された認証機構とも統合できます。権限付与の仕組みをアプリケーション内部から取り出し、宣言的なルールの集合として定義して、その一連の定義を使って、やってくる認証要求をアプリケーションが理解できる要求に変換することができるのです。
アクセス制御サービスの実際の商用ローンチで盛り込まれる予定の機能の利用シナリオは、
- トークンを交換できるふたつのエンドポイント: REST形式で対称キーを利用する方法とREST形式でSAML拡張を利用する方法
- Claims Transformation Engine: 設定変更可能なルールを使って入力された要求を変換して出力する
- Security Token Service: REST形式のトークンを使って要求をまとめて出力する
発表によると、将来のリリースではWS-*のエンドポイントを通したアクセスもサポートする。これがサポートされれば、Web上でのシングルサインオンのようなシナリオも実現でき、包括的なサービスとなるだろう。
具体的に言うと、現在サポートされているWS-*との統合機能は、我々がREST形式のWebサービスの認証基盤の強化に注力している間は、一時的に利用できなくなるということです。この認証基盤が完成すれば、将来のバージョンの.NET Servicesの機能について作業が行えます。それは、例えばWeb上でのシングルサインオンやWS-*をサポートするための機能です。将来のリリースでは、the WS-*のプロトコルを完全にサポートしようと考えています。もちろん、Web上でのシングルサインオンもサポートします。.NET Access Control Serviceの提供する機能でREST/SOAPの領域をサポートしたいと考えています。
PluralsightのKieth Brown氏はこの発表を考察している。
ACS [access control service]をWS-*や受動的なID連携を通して使おうと思っていた開発者は、RTM版が出たらすぐに考えを変えなければならないかもしれない。
クラウドサービスの一般化に伴い、Microsoftを含むサービスベンダが戦略変更を迫られているのは興味深いことだ。我々は、以前にもgoogleがWS-*を使った検索APIを非推奨にし、サポートを停止したことを報じた。このような変化を起こしているのは、RESTfulなサービスが利用しやすく、様々なプラットフォームやテクノロジからアクセスできるという点なのだろうか。それとも、WS-*が提供するサービスとは対照的に、RESTfulなサービスが拡張しやすいからだろうか。発表の原文を読んで詳細を理解し、ぜひ.NET Services Technical Discussion Forumで.net servicesチームにフィードバックを送ってほしい。