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 でも同じですものね 。。。
leave a comment