WindowsドメインからAmazon EC2へのシングルサインオン・アクセスのソリューション

作者 Abel Avram , 翻訳者 能仁 信亮 投稿日 2010年2月7日

セクション

運用/インフラ,

デベロップメント,

設計/アーキテクチャ

トピック

セキュリティ ,

.NET ,

Architecture ,

クラウドコンピューティング ,

マネジメント

タグ

Windows ,

Active Directory ,

EC2

原文(投稿日：2010/01/21)へのリンク

Chappell & Associatesの代表であるDavid Chappell氏が、WindowsドメインからAmazon EC2にデプロイされたアプリケーションに対して、シングル・サイン・オン(SSO)でアクセスするいくつかの解決策をまとめたホワイトペーパーを発表した。InfoQは、それぞれのソリューションを詳細に調べ、各々の利点とトレードオフを探った。

Providing Single Sign-On To Amazon EC2 Applications From An On-Premises Windows Domain(オンプレミスのWindowsドメインからAmazon EC2アプリケーションへシングル・サイン・オンを提供する方法)(PDF)というタイトルのChappell氏のホワイトペーパーは、WindowsドメインからAmazon EC2にデプロイされたアプリケーションに対してSSOアクセスを行う際に、取り得る方式をいくつか取り上げている。

• Windowsドメインを制御するのと同じエンティティに属するAmazon Machine Instance(AMI)にアクセスする
  • Amazon Virtual Private Cloud(VPC)の中のAMIにVPNを使ってアクセスする
  • Active Directory Federation Services(ADFS)を使って、パブリックなEC2クラウドの中のAMIにアクセスする
• サードパーティに属するアプリケーションにアクセスする

Windowsドメイン - Amazon VPC

企業が独自のアプリケーションをAmzon EC2にデプロイし、VPNが利用可能なときには、Chappell氏はそのアプリケーションをAmazon VPCにデプロイするように推奨している。VPC内のAMIはオンプレミスで所有しているのと同様に振る舞い、SSOを提供するためにActive Directory Domain Services (ADDS)と連携する3つの取り得る方式がある。

• VPC内部のAmazon EC2インスタンスを既存のオンプレミスのWindowsドメインおよびサイトの一部に設定する。この選択肢では、VPCの中でドメイン・コントローラを実行させる必要がない。
• VPC内部のAmazon EC2インスタンスを既存のオンプレミスのWindowsドメインの新しいサイトとして設定する。この選択肢では、Amazon EC2内でADDSを実行させる必要がある。
• VPC内部のAmazon EC2インスタンスを既存のオンプレミスのWindowsフォレストの新しいドメインとして設定する。この選択肢でも、Amazon EC2内でADDSを実行させる必要がある。

これらのすべての場合で、認証および認可はオンプレミスでのアプリケーションへのアクセスと同様に動作する。ユーザはADDSサーバにアクセスし、認証をうけ、Kerberosチケットを受け取る。そのチケットはクラウド上のアプリケーションに転送され、チケットに含まれる証明書に基づいてアクセスが許可される。

ADFSを利用したWindowsドメイン – Amazon Public Cloud

VPNが望ましくない状況では、企業はAFDSを使ってWindowsドメインからAMIにSSOアクセスをするように設定することができる。Chappell氏は、使用するバージョンがAFDS 1.1なのかAFDS1.2かに応じて2つのソリューションを提案している。それらは大部分共通なのだが、いくつかの違いがある。

ADFS 1.1

この場合、ADFS 1.1サーバーはWindowsドメインのなかでオンプレミスで実行させる必要がある。AMIには、ADFS 1.1 Web Agentを載せる必要がある。ユーザがブラウザ経由でクラウド・アプリケーションにアクセスしようとした際に、リクエストはWeb Agentで受信され、ADFS 1.1サーバにリダイレクトされる。ADFS 1.1サーバでは、ユーザを認証し、Web Agentにブラウザが戻すトークンを生成する。Web Agentはトークンに含まれるクレームに基づいてアプリケーションへのアクセスを許可する。一連の認証と認可の操作はカーテンの裏側で行われ、ユーザが関わることはない。

このアプローチはAMIがWindowsを実行していない場合でもうまく動作する。必要なのは、WS-Federationプロトコルを実装したWeb Agentだけだ。ホワイトペーパーでは、Linux用のWS-Federationエージェントを提供している会社として、Quest Software社とCentrify社をあげている。

このアプローチには、いくつかの難点がある。ひとつは、ブラウザにしか適合しないという点だ。その他に、MicrosoftやIBMなどが推進している、より一般的なアプローチであるクレームベースの認証の信頼できる基盤として求められるもののいくつかがADFS 1.1には欠けているという点があげられる。

AD FS 2.0

ADFS 1.1に対して言及した難点は、ADFS 2.0では解消されている。ADFSサーバは2.0サーバであり、Web AgentはWindows Identity Foundation (WIF)エージェントで置き換えられる。SSOアクセスは1.1を使ったときと同様に機能する。

ADFSを使ったWindowsドメイン – Amazon Public Cloud上のサードパーティAMI

上で述べた内容は、クラウド上のAMIがWindowsドメインの同一エンティティに属している時に機能する。AMIが同一条件でオペレーションしていないサードパーティのものであるときには、状況は変わってくる。AMIがユーザのものとは異なった独自のADFSサーバをもったWindowsドメインに属している場合だ。この場合も、利用しているADFSのバージョンが1.1なのか2.0なのかによって、2つの取り得るソリューションがある。

ADFS 1.1

ブラウザがクラウド上のアプリケーションに接続しようとする際、リクエストはクラウド上のWindowsドメインADFSサーバにリダイレクトされ、SAMLトークンが生成されブラウザ経由で、企業内のドメインに属するADFSサーバにリダイレクトされる。サーバは、別のトークンを生成し、リモートのADFSサーバにリダイレクトされ、そのトークンが示される。次にリモートADFSサーバがブラウザがアプリケーションにアクセスするために利用するトークンを発行する。

ADFS 2.0

このケースは、ADFS1.1を利用した場合と似ているが、WebエージェントがWIFで、1.1サーバが新しいバージョン2.0でそれぞれ置き換えられる。

ユーザによって作成されたオンプレミスおよびインターネットのアカウントの数が増大し、それらを管理することが難しなってくると、SSOは重要な機能となる。SSOによりユーザは作業がより単純になり、管理コストを削減できるので、ソフトウェアベンダは、SSOサポート／ソリューションをより求められるようになってくるであろう。

• 次へ >