２．既存アプリケーションへの変更が最小限度で済むか

シングル・サインオンを導入すると、認証をすべて製品に任せる形となるため、既存のアプリケーションの認証は利用しないのが一般的です。

ただし、利用しないといってもポータル製品やパッケージのアプリケーション、自社開発のアプリケーションにおいてもIDや個人情報をキーとして独自にアクセス・コントロールを行っているケースもあるため、シングル・サインオン製品から情報を送付し、それを受け取るためのアプリケーション側の改変が必要になる場合もあります。

製品選定時には、どの程度改変が必要か、開発が発生するか、情報を引き渡す手段はあるのかを見極める必要があります。製品によって、かなり差が現れてくるポイントでもあります。

保護したいコンテンツが存在する場合、開発は必要なく保護したいURLを指定し、誰がアクセスできるのかという設定をするだけで保護ができる製品、また、ERPアプリケーションなども専用エージェントを用意しているため改変の必要がない製品も存在します。

既存のアプリケーションへの情報連携に関しては、認証成功後、ユーザー・リポジトリより必要なユーザー属性を取り出し、HttpヘッダーやCookie等でユーザーIDや属性などをアプリケーションへ引き渡すことが可能な仕組みがあれば、アプリケーション側ではそれを受け取り、自身のアクセス制御として利用できます。

３．運用の集中化、権限委譲が可能か

シングル・サインオン導入によって、管理下のすべてのWebシステムに対する認証、アクセスの管理を集約することができます。これにより管理ポイントが一つとなり運用コストの大幅な削減が見込まれます。

しかし、実運用においては事業部や部署ごとに管理者を設置する方が一般的です。IT部門の管理者はシングル・サインオン・システムのメンテナンスのみを担います。こうすることでセキュリティポリシー通りの運用ができるようになり、常にポリシーに沿った状態を継続することになるため、セキュリティ確保と運用効率がさらにアップします。権限委譲をシングル・サインオン・システムの中で実現できる様になっていることも運用では必須なのです。

４．将来のアクセスの増加、Web資産の増加に対応できるか

例えばオンライン・バンキングなどのBtoCサービスであればユーザー・アクセスが短期間に数倍、数十倍と増加していくことも珍しくありません。Webシングル・サインオン製品には、こういったビジネスの成長に対応できる拡張性も必要です。この処理能力の増強に大掛かりな作業が発生し時間が掛かるようでは、ビジネスの成長を阻害する要因となってしまいます。選定の際にはぜひチェックしたい項目です。

対応のために追加のSI工数が掛かる、カスタマイズが必要、それとも製品の設定レベルで終わるのかでは、コストが大きく異なります。

シングル・サインオン製品では、負荷増大の際には特に認証サーバー（=ポリシーサーバー）のキャパシティ・プランが必要です。ハードウエアの追加による処理能力増強一つを取ってみても、追加／変更を設定レベルで行うだけで面倒な作業がない製品もあれば、一から設定しなければならない場合もあります。またロードバランシング／フェイルオーバーの設定を人の頭で考えて、導入しなければならない製品もあれば、GUI画面より容易に設定できる製品も存在するのです（図3）。

図3：アクセスの増加、Web資産の増加にも設定レベルで対応する（クリックで拡大）

新サービスをいかに早くサービスインするかもポイントです。サービス提供時には、毎回認証の部分を作りこむ必要があり、脆弱性はないか等をテストするなど、開発工数が掛かります。結果的に新サービス公開するまでのリードタイムも大きくなりがちです。

構築視点の一つ「既存アプリケーションへの変更が最小限度で済むか」で紹介したように、認証をすべてシングル・サインオン・システム（統合認証基盤）に移管することができれば、新規に用意するアプリケーションは認証の作りこみを行わず、コンテンツのみを開発するだけで済みます。セキュリティも保たれた新サービスは、作成と同時に公開され、セキュアな状態でサービスインを迎えることができます。

まとめ

以上、4つのポイントを挙げましたが、皆さまの企業ではどこに注力するでしょうか。必要となるポイントはその企業によって異なるでしょうが、この4つすべてを事前に比較検討しておくことをお勧めします。そうすることにより、後で課題を抱えるリスクを最小限にし、ユーザーからも評価されるシングル・サインオンを社内に展開できるはずです。