HP IceWall SSO

シングルサインオンとは

通常ユーザは、ひとつひとつのアプリケーションやOSに対し、まずログインの手続きを行ってから使用を開始することになります。
ログイン時にユーザIDとパスワードなどの文字列を組み合わせて入力するケースが多く、その情報がシステム側に正しいと判断されることによって、はじめてユーザが「認証」されることになるのです。

ところが逆に、こうした認証機能やログイン作業がユーザの負担になってしまうケースも少なくありません。
特に、様々なプラットフォームを組み合わせ、多くのアプリケーションを使っている企業の場合は、度重なるログイン作業や多くのIDやパスワードを管理する手間が煩わしく感じられることも、多々あることでしょう。
また、IDやパスワードの管理が複雑になると、それらを手帳やメモなどに書き留めてしまうというリスクも発生します。 しかし、セキュリティを確保する上で、パスワードのメモは決して好ましいとはいえません。
セキュリティを高めるためにIDやパスワードを厳格に管理することは重要ですが、必要以上にユーザの負担を重くすると逆効果になってしまいます。

そこで役に立つのが、シングルサインオンというシステムなのです。
シングルサインオンによってユーザは複数のIDやパスワードを覚えておく負担から解放されます。パスワードをひとつ覚えておくだけで、厳格なパスワード管理も現実的なものとなり、より高いセキュリティを実現することが可能になるのです。

シングルサインオンは現在、多くの企業にとって欠かせないものになっています。
個人情報の漏洩防止やセキュリティ対策といった観点からも、企業を守るために今や必須の機能といっても過言ではないでしょう。

リバースプロキシ型シングルサインオンの構造

これは通常のプロキシサーバと目的は逆ですが、構造は同じです。
つまりリバースプロキシ型のシングルサインオンとは、アプリケーションプロトコルレベルのゲートウェイと考えることが出来るため、ファイアーウォールの一種にも分類されます。
クライアントからはリバースプロキシサーバが見えているのみであり、コンテンツを保持するWebサーバはクライアントからは隠蔽されています。
クライアントからのリクエストは必ずリバースプロキシサーバを経由することから、リバースプロキシサーバはユーザが現在ログインしているか、またリクエスト先のWebサーバにアクセス可能であるかを認証サーバに問い合わせ、中継を行ないます。

エージェント型シングルサインオンの構造

リクエストはWebサーバ自体で受け付け、呼び出されたエージェントモジュールがユーザのログイン状態とアクセス権限を認証サーバに問い合わせ、呼び出したWebサーバに結果を返します。
Webサーバはその結果によりコンテンツを返すかエラーページ等を表示するかの動作を伴います。
Webサーバ自体がクライアントから見えていることから、ファイアーウォールの機能はありません。
また、コンテンツ保持しているWebサーバ自身がアクセス制御も行なう事がリバースプロキシ型と大きく異なる点です。

リバースプロキシ型は、ブラウザのログイン電文をエミュレーションする機能*1を備えているものがあります。この機能を利用することでWebアプリケーション側をカスタマイズすること無しに接続することが可能です。
*1　HP IceWall SSOの場合には、48通りのログイン方式に対応しています。

リバースプロキシ型では
カスタマイズが不可能なWebアプリケーションも接続可能

エージェント型ではWebアプリケーションにカスタマイズが必要です。
導入ご検討の際の判定ステップを下記にご紹介します。下記全てがYESの場合、エージェント型での導入が可能です。

1. アプリケーションのOS、Webに対応するエージェントモジュールが提供されているか確認する。
2. アプリケーションの認証機能が撤去できるか確認する。
3. アプリケーションがエージェントモジュールより先に動作しないか確認する。
4. アプリケーションがHTTPヘッダから認証情報を取得できるようにカスタマイズできるか確認する。

エージェント型ではWebアプリケーション側のカスタマイズが必要

シングルサインオンの型を組み合わせたシステム構成例

※図内「エージェントプロキシ型」について
HP IceWall SSOの場合には、エージェント型とリバースプロキシ型の中間型も採用しています。
詳細は技術レポートをご覧ください。