シングル・サインオン製品の必要性と製品選択のポイント

シングル・サインオン導入の意味

前ページで述べた問題を踏まえた上で、シングル・サインオンを導入することによるメリットとして以下が挙げられます。

• 一つのユーザーID・パスワードでの運用により、エンドユーザーに利便性を与える
• Webアクセス管理を徹底して、リスクを軽減、IT統制の取れた環境を維持する
• 単体アプリケーション、単体ユーザーストアのメンテナンスから統合された管理へ移行し、運用・管理の負荷を軽減する

シングル・サインオンは、セキュリティ層を一つにして、その下で稼働するアプリケーションに対しては一元管理を与えるソリューションです。

このセキュリティ層によって、次のことが実現できるようになります。

• エンドユーザーに利便性を与える
• Webアクセス管理を徹底する
• 運用・管理の負荷軽減

この統合基盤を導入した際に得られるメリットとして、製品によっては、新規アプリケーション開発でこのセキュリティ層を活用できることもあります。

アプリケーションの中でセキュリティを組み込まなくても、セキュリティ層がアクセス管理の部分を担うことができます。開発コストの削減も見込めますし、その分スムーズにアプリケーション・リリースを迎えることができます。

管理も一元化されているため、運用コストもシングル・サインオン導入前と比較すると、削減されることになります（図1）。

シングル・サインオン製品の種類　－リバース・プロキシとエージェント

Webシングル・サインオン製品には2つのタイプがあります。一つはすべての認証要求をいったんサーバーで受け付けるリバース・プロキシ型。もう一つはそれぞれのWebシステムが導入されているWebサーバー上にエージェントを配置して認証要求を受け付けるエージェント型です。

リバース・プロキシ型は、既存アプリケーションにエージェントを導入する必要がない代わりに、アクセスが集中するためにパフォーマンスの確保は難しくなります。エージェント型は、アクセスが各Webサーバーに分散されるため、パフォーマンス要件は満たしやすいですが、各Webサーバーにエージェントをインストールする必要があります。

これらを比較して、自社環境に合わせた方式を選ぶことが重要です。

最近では多くの製品が、リバース・プロキシとエージェントのどちらのタイプもサポートしています。また、混在させて使える製品もあります。特にシステム規模が大きくなると、パフォーマンスを求めるシステムにはエージェント型で対応し、リバース・プロキシ・サーバーにより携帯端末などPC以外からのアクセスに対応したいシステムにはリバース・プロキシ・サーバーを活用するなど、両タイプが必要になるケースもあります。

導入時の製品選定ポイント

製品を選択し、いざ運用開始という段階になってから余計なコストが生じたり、ビジネスの成長へ追従できない柔軟性のないシステムになってしまうという可能性をなくすため、シングル・サインオン製品選択時に考えておくべきポイントがあります。

では、具体的な考慮ポイントとはいったいどのようなものなのでしょうか。ここでは、構築視点および運用視点あわせて4つのポイントを挙げてみます。

1. 構築時に既存システム資産を最大限に生かせるか
2. 既存アプリケーションへの変更が最小限度で済むか
3. 運用の集中化、権限委譲が可能か
4. 将来のアクセスの増加、Web資産の増加に対応できるか

１．構築時に既存システム資産を最大限に生かせるか

Webシングル・サインオン製品の導入は、選択する製品によっては全社的なWebシステム環境の再構築が求められる場合があります。そのため、可能な限り自社のIT資産を生かした形で大幅な変更をすることなく、システムを構築できることが求められます。

IT資産を生かすためのポイントとしては、まず自社のシステムに合ったWebシングル・サインオンのタイプ（リバース・プロキシ型かエージェント型か）を選択することです。そして、「認証ディレクトリの整備」を挙げることができます。

認証の中心となるIDやパスワード、個人属性情報を含む認証ディレクトリ、もしくはデータベースが既に存在すればプロジェクトの短縮化が図れますが、実際のところは統一化されているケースの方が珍しいといえます。

Webシングル・サインオン製品では指定されたディレクトリに情報を集約する必要があるものが多く、アプリケーションごとに所有するID情報の集約、いわゆるディレクトリ統合の作業は構築時の大きな負担となります。

製品によっては、現在存在する複数のディレクトリを認証ディレクトリとして利用可能なものが存在します。それぞれのディレクトリへユーザーIDなどで紐付けを行い、あたかも一つの統合ディレクトリとして扱うことができます。　また、本人認証（Authenticate）はAディレクトリで行い、アクセス許可（Authorize）はBディレクトリで行う、という運用が可能な製品も存在しています。これにより、既に存在する環境に変更を加えることなく、Webシングル・サインオン環境が整えられるのです（図2）。