シングル・サインオンをクラウドに拡張する

シングル・サイオンオンを企業からクラウドに拡張する方法のコアとなる概念を理解する

シングル・サイオンオン (SSO) により、企業はさまざまなアプリケーションに対して一貫性のある方法でアクセス制御ポリシーを施行することができます。SSO を企業からクラウドに拡張する方法のコアとなる概念について説明するこの記事では、データ・センターで実行する従来のアプリケーションと SaaS アプリケーションとの間で SSO を実現するためのいくつかの異なるメカニズムを紹介します。この記事で取り上げるトピックには、SAML、OAuth、従来のエージェント・ベースの SSO なども含まれますが、特に SaaS (Software as a Service) プロバイダーによって標準をサポートするレベルが異なるために SSO の実装が複雑になることに焦点を当てて概括します。

Kunal Mittal, Executive Director, IT, Sony Pictures Entertainment

Kunal MittalKunal Mittal は Sony Pictures Entertainment の Executive Director of Technology であり、SOA、ID 管理、コンテンツ管理のプログラムを担当しています。彼は中央の技術部門としてさまざまな業務系統に技術サービスを提供しており、また Sony Pictures Entertainment の IT 環境への新しいプラットフォームや技術の導入を指揮しています。彼は J2EE、クラウド・コンピューティング、モバイル技術に関して何冊かの本や記事を執筆、編集しています。彼はソフトウェア工学の修士号を持ち、また計器飛行資格を持ったプライベートのパイロットです。



2012年 11月 22日

シングル・サイオンオン (SSO) は多くの大企業がユーザー (従業員、パートナー、顧客、請負業者など) に提供している重要なサービスです。IT セキュリティーに対する規制が強まる時代の中で、企業は SSO 技術を使用することにより、さまざまなアプリケーションに対して一貫した方法でアクセス制御ポリシーを施行することができ、全体としての実装コストを削減することができます。これらのポリシーには、パスワードの長さ、パスワードの複雑さ、パスワードの有効期限、以前使用されたパスワードの再利用などに関する規定を含めることができます。アプリケーションが遵守しなければならないルールやポリシーがどのようなものであっても、一度それらのルールやポリシーを実装すれば再利用することができます。この SSO インフラストラクチャーを活用するシステムは、認証や監査も効率化することができます。

SSO を利用すると、IT のコンプライアンスを実現できるだけでなく、リスクを大幅に低くすることもできます。皆さんはデスクがパーティションで仕切られたオフィスの中を歩いていて、パスワードが書かれた付箋紙がパーティションに貼り付けられているのをどれくらい見かけたことがあるでしょうか?また、エンタープライズ・システムのそれぞれに対して設定した、非常に沢山ありそうなパスワードを覚えるために、皆さんが個人で行っているのはどのような方法でしょうか?エンタープライズ・システム全体に対して SSO を採用すると、エンタープライズ・システムのユーザーは 1 つのパスワードのみを覚えておけばよく、パスワードが書かれた付箋紙がいくつもパーティションに貼り付けられた危険な状態になる可能性が低くなるだけでなく、パスワードを他人に漏らす危険性も低くなります。e-メール、人事・福利厚生システム、その他のシステムですべて同じパスワードを使用すれば、ユーザーがそのパスワードを同僚に漏らす可能性は低くなります。

コストの削減に関して言えば、SSO に投資することで、ヘルプ・デスクへの電話の本数が減るという直接的な効果が得られることが実証されています。異なるパスワードの数が少なくなれば、パスワードを忘れてしまったためにヘルプ・デスクへ電話をする回数も少なくなります。この SSO への投資によって電話の本数が減る効果は、いくつものインターネットの記事で取り上げられている数字や、Gartner および Forrester Research のような会社が発表する数字によれば、40% から 70% にも上るとされています。

SSO の構成要素

ではまず、SSO をサポートするために必要な基本技術要素について見ていきましょう。SSO には以下のような要素が関与します。

  • ユーザー: ログインしようとするユーザー
  • Web アプリケーション: ユーザーがログインする対象となるアプリケーション

    この記事で対象とするアプリケーションは、Java、Microsoft .NET、PHP による任意の Web アプリケーション、または SalesForce.com、Google Apps、Microsoft Office 365、Concur、ServiceNow、Workday などの SaaS (Software as a Service) アプリケーションです。

  • Web アプリケーション・エージェント: 企業のデータ・センターで実行される SaaS 以外のアプリケーションに対するエージェントであり、通常はそのアプリケーションをホストする Web サーバーやアプリケーション・サーバーにインストールされます。
  • ポリシー・サーバー/SSO サーバー: SSO を実現するために必要なすべての機能と能力を提供するソフトウェア
  • ディレクトリー: ユーザー名、パスワードをはじめとする、ユーザーに関する属性を格納するリポジトリー

    ほとんどの組織では、Active Directory Domain Services、または LDAP (Lightweight Directory Access Protocol) を実装する他のディレクトリー・ソフトウェアが使用されています。ベスト・プラクティスではありませんが、リレーショナル・データベースのテーブルを使用することもできます。

これらのコンポーネントの実際を示したものが図 1 です。

図 1. SSO を構成する主な要素
SSO を構成する主な要素

この記事では、デスクトップ・アプリケーションの SSO やエンタープライズ・アプリケーションの SSO ではなく、Web ベース・アプリケーションのための SSO に焦点を絞ります。基本レベルでは、Web ベースの SSO が機能する仕組みは、図 1 に示すアーキテクチャーのとおりですが、以下で 1 つの例をとおして、この図をもっと具体的に説明します。

SSO には、ポリシー・サーバーまたは SSO サーバーと、Web アプリケーション・エージェントという 2 つの主要構成要素が必要です。ポリシー・サーバーまたは SSO サーバーは「ID 決定点 (Identity Decision Point: IDP)」と呼ばれることがよくあります。IDP は、ユーザーのクレデンシャル (ユーザー名/パスワード) が正しいかどうか、またユーザーがログインできるかどうかを「決定 (判断)」します。大手のエンタープライズ・ソフトウェア・ベンダーはいずれも、この分野の何らかの技術または製品をおそらく提供しています。現在この分野に提供されている最高の技術には、IBM Security Access Manager for Enterprise Single Sign-On、CA SiteMinder、Oracle Access Management などがあります。また、多くのオープンソース製品や SaaS 製品 (OpenAM、Okta、DirectAxs、Ping Identity など) が市場に登場しており、前述の商用製品に対する本格的な競合製品となりつつあります。

上記の製品にはすべて独自のエージェントが同梱されています。このエージェントを、保護および SSO 実現の対象にしようとしているアプリケーションをホストする Web サーバーやアプリケーション・サーバーにインストールする必要があります。一般に、ほとんどの主要なオペレーティング・システム、Web サーバー・ソフトウェア、アプリケーション・サーバー・ソフトウェアにはエージェントがあります。エージェントの役割は、アプリケーションに対するログイン・リクエストをインターセプトし、そのリクエストを SSO サーバーに渡して決定させることです。そのため、このコンポーネントは「ID 実行点 (Identity Enforcement Point)」と呼ばれることが

よくあります。


SSO をクラウドに拡張する

企業は、採用する SaaS ベースのアプリケーションが増えるのに伴い、SSO の機能をそれらの SaaS アプリケーションにまで拡張することを望むようになってきています。これはつまり、ユーザーは企業アプリケーションや e-メール、さらにはデスクトップ・アプリケーションに毎朝ログインするために使用しているのと同じクレデンシャルを使用して、SaaS アプリケーションにもログインできるということです。

SaaS ベンダーはこうしたニーズを認識し、その容易な実現を支援するメカニズムを提供しています。また、SaaS アプリケーションへの SSO の統合を数時間、あるいは数日で行えるようにするための標準も数多く登場しています。この点は重要です。この統合のために、すべての SaaS ベンダーが独自の手段を提供したらどうなるかを想像してみてください。さらに悪い状況として、それぞれの SSO サーバー・ベンダーが独自の技術を提供したらどうでしょう。そうなれば多額の費用がコンサルティングにかかるのは確実です。

SaaS プロジェクトは通常、ビジネス部門主体で進められます。IT 部門も関係しますが、調達サイクルの後の方になって IT 部門が関係する場合があります。基幹業務 (LOB) の担当 IT 幹部が ID 管理 (Identity Management: IDM) プログラムのマネージャーに電話をし、ビジネス部門が新しい SaaS ベンダーを選択したこと、そして SSO の導入を希望していることを伝えます。SaaS ベンダーは、移行作業は 1 日あれば終わると言っていますが、IDM チームは SSO の統合作業を来週までに完了できるでしょうか?

皆さんは IDM プログラムのマネージャーとして、その件を検討して LOB 担当幹部に返事をすることに同意します。皆さんはその SaaS ベンダーについて調べ、SSO に関する彼らの資料を読みます。皆さんはアーキテクトと短い会話を交わし、すべては簡単に済むはずのように思えます。

そして今度は技術者達が統合の作業を開始します。しかし彼らはすぐに、解決が必要な多くの問題があること、そして統合作業が 1 日や 2 日で終わるようなものではないのは確実で、おそらく 2、3 週間ぐらいかかることを認識します。このような場合に明らかになる可能性のある問題としては、以下のような例があります。

  • 標準がサポートされていない。稀に、SaaS ベンダーが SAML (Security Assertion Markup Language) すらサポートしていないケースがあります。よくあるケースとしては、皆さんの SSO サーバーの現在のバージョンが SAML をサポートしていない場合や、ベンダーが SAML パックを別の SKU (製品ラインアップ) として持っている場合があります。そうした場合にはすぐに調達サイクルに取り組まなければなりません。
  • 標準はサポートされているものの、機能しない。上述の最初の問題をパスできたとしても、ある仕様の特定のバージョンを両者 (SSO サーバーと SaaS ベンダー) が完全にサポートしていると主張しているにもかかわらず、統合しようとすると何らかの問題に直面する場合があります。これらの問題は通常は些細なものであり、対処することができますが、そのためには双方のサポート・チームと皆さんの IDM 技術者が電話会議を行う必要があります。
  • 独自技術。一部の SaaS ベンダーは SSO に代わるメカニズムとして、Web サービスやディレクトリー同期機能を提供しています。これらの代替メカニズムは有効なものですが、追加の開発作業が必要となり、またネットワーク・セキュリティーやファイアウォールなどの問題にも対処する必要があるため、プロジェクトに要する期間が長くなります。

ポイントは明確で、要は注意深く要求を規定することです。SaaS SSO プロジェクトは 24 時間から 48 時間で終わる作業ではありません。実際の作業自体がこの時間を上回ることはないかもしれませんが、あらゆる調整が必要になるため、全体としての時間はすぐに 2、3 週間かかってしまう可能性があります。


設計パターン

このセクションでは、データ・センターでホストされる従来のアプリケーションと SaaS アプリケーションとの間で SSO を実現するための 3 つの設計手法について説明します。皆さんはおそらく、上述の問題を考慮して実装されたパターンを見たことがあるはずです。

設計パターン 1: カスタム Web アプリケーション

SaaS プロバイダーまたは SSO ソフトウェアが SAML をサポートしていない場合、この設計パターンを使用することができます。また、この設計パターンを使用して Web サービスを利用することや、独自の統合を別に行うこともできます。さらには、SaaS プロバイダーが SAML をサポートしているものの、SSO サーバーが SAML をサポートしていない場合に、この設計パターンを使用することができます。(推奨はできませんが) 最終的にカスタムで SAML を実装することになった場合、その設計パターンはここで説明したパターンと似たものになります。

基本的に皆さんは、SSO ソフトウェアが提供する通常の Web エージェントによって保護された Web アプリケーションをデプロイすることになります。このアプリケーションにはログイン・ページがあり、皆さんの SSO サーバーに対して認証を行います。またこのアプリケーションには SaaS アプリケーションにクレデンシャルを渡すためのコードが含まれています。ユーザーが認証されると、アプリケーションは SaaS アプリケーションに認証情報を渡します。当然ですが、このデータを必ず暗号化し、Secure Sockets Layer で送信する必要があります。SaaS プロバイダーが SAML をサポートしている場合には、カスタムの SAML 実装を使用して SAML を生成することができます。あるいは SaaS ベンダーが提供する Web サービスを利用するコードをアプリケーションに含めることもできます。最も望ましくないながらも有効な技術的方法として、SaaS アプリケーションがユーザーを認識できるような何らかの基本情報を HTTP POST で送信する方法があります。

このパターンのバリエーションとして、SaaS プロバイダーが実際にこの Web アプリケーションを提供する場合があります。基本的に、この Web アプリケーションは SSO サーバー製品からインストールされるエージェントと何も違いはありません。そのため、SaaS プロバイダーが提供する Web アプリケーションを利用するのが、カスタムの Web アプリケーションを構築するための望ましい方法の 1 つかもしれません。

設計パターン 2: SAML ベース

このパターンは理想的なソリューションであり、SAML を使用して SaaS アプリケーションと SSO サーバーとの間で SSO 情報を送信します。両者が完全に SAML をサポートしている場合は、SAML のセットアップとテストは通常は数時間ですみます。

このパターンの場合、さまざまな SSO サーバー製品がまだ成熟途上にあります。製品が進化するにつれ、統合作業が場合によっては 5 分程度で済むような、ほぼそのまま使用できる機能を目にするようになってきています。例えば、私は SalesForce.com、Google Apps、Facebook と 1 つの SSO サーバー製品とを 1 時間で統合することができました。図 2 に示すように、このパターンの動作は以下のとおりです。

  1. ユーザーが SaaS アプリケーションにログインします。
  2. ログイン・リクエストが SAML リクエストの形で IDP (SSO サーバー) にリダイレクトされます。
  3. SSO サーバーが SAML の暗号を復号し、ユーザーを認証します。
  4. SSO サーバーが SAML レスポンスとして成功または失敗という結果を SaaS アプリケーションに返します。
  5. ユーザーがログインするか、該当するエラー・メッセージがユーザーに表示されます。

このプロセスをセットアップするための一般的なステップは以下のとおりです。

  1. SaaS プロバイダーの管理コンソールにログインし、クレデンシャルとともに SSO サーバーの URL を指定します。
  2. SaaS サーバーと SSO サーバーの両方で、暗号化メッセージ用の SSL 鍵を設定します。
  3. SSO サーバーでポリシーを作成し、そのポリシーを SAML 通信に対して有効にします。
  4. カスタムのログイン・ページやエラー・ページ、タイムアウトなど、必要な他のパラメーターを調整します。

すべてが順調に進めば、非常に単純です。

図 2. SAML ベースの SSO
SAML ベースの SSO のプロセスを示す図

設計パターン 3: 自動プロビジョニング

自動プロビジョニングは、ディレクトリーを同期させる設計パターンに多少意匠を凝らしたものです。このパターンの動作を示したものが図 3 です。オンボード・プロセス、転送プロセス、終了プロセスの間、IDM ツールはユーザー ID に対する変更をツール自身のデータ・ストア (通常はディレクトリー・ソフトウェア) に書き込みますが、IDM ツールはその情報を (通常は Web サービスを呼び出すことによって) SaaS アプリケーションにも書き込みます。ユーザーの追加、終了、そしてパスワードの変更はすべて SaaS アプリケーションに送信され、内部ディレクトリーとの同期が保たれます。

ユーザーは、ログインする際に、会社のクレデンシャルを使用することができます。この設定により、少し異なる種類の SSO、つまり Single Sign-On (シングル・サインオン) ではなく Simple Sign-On (シンプル・サインオン) を実現することができます。Simple という理由は会社のシステムと同じユーザー名とパスワードを使用するからですが、これはシングル・サインオンではありません。ユーザーは別途 SaaS アプリケーションにログインする必要はないのです。

このパターンは、カスタムの Web サービスを実装する方法で実装することや、使用される技術が、ユーザーによるこの種のプロビジョニング・アクティビティーに対し、SPML (Service Provisioning Markup Language) 標準をサポートしている場合に実装することなどができます。

図 3. 自動プロビジョニング
自動プロビジョニングのプロセスを示す図

まとめ

十分に計画を立てて実行すれば、SaaS プロバイダーとの間で比較的容易に SSO を構築することができます。ただしいくつか注意すべき点があり、またプロジェクトを確実に成功させるには、プロセス全体に対して適切にプロジェクト管理や要求事項の設定を行えるスキルが必要です。SaaS ベンダーは SSO をサポートしていますが、すべての SaaS ベンダーが SAML をサポートしているわけではないことを忘れないでください。つまり、計画または調達サイクルの最初に、SSO に関して技術的な議論をすることが重要で、双方が互いの技術的な制約を認識する必要があります。

同様に、カスタム・ソリューションを構築する場合には、それらのソリューションのセキュリティーや暗号化レベルを非常に高くする必要があります。また、必ずすべてをログに記録するようにします。何か問題や懸念事項が発生して、ログイン・トランザクションに時間がかかりすぎている場合、ログを信用する必要があります。一般には、詳細なログをとることにより、最初にサポートの問題で費やした時間に見合うだけのメリットを得ることができます。

皆さんの IT 環境で SaaS が従来以上に重要な役割を果たすと思える場合には、あらかじめ計画を立てる必要があります。しかるべき技術への投資は遅らせることなく、すぐに行うようにしてください。また、SaaS ベンダーや商用の既製製品が提供するサービスは常に進化しているため、リファクタリングや再評価の計画を立てることも重要です。

参考文献

学ぶために

  • ウィキペディアは SSO の概念や SSO に関連した IDM の概念の背景について的確に解説しています。
  • SAML について、また SaaS SSO で SAML が果たす役割についての解説を読んでください。
  • Web ベースのアプリケーションに対する SAML ベースの SSO を実装してください。
  • developerWorks でクラウド開発者のためのリソースを調べてください。クラウドにデプロイするためにプロジェクトを構築しているアプリケーション開発者やサービス開発者の知識や経験を発見し、共有することができます。
  • IBM SmarterCloud Enterprise にアクセスする方法を学んでください。

製品や技術を入手するために

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=846539
ArticleTitle=シングル・サインオンをクラウドに拡張する
publish-date=11222012