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サポート／ソリューションをより求められるようになってくるであろう。