株式会社セシオス

必須となったシングルサインオン

システムで、複数のアプリケーションを運用していくにあたり必須となる技術が、シングルサインオンでしょう。いうまでもなく、アプリケーションの認証に一組だけのユーザーIDとパスワードを使用する仕組みです。

利用するシステム数が多くなると、ユーザーIDやパスワードといった認証情報の適切な管理が難しくなります。複数システムの認証情報をユーザー個々に管理させることは、セキュリティの問題が発生しがちになります。管理を厳密に行おうとすれば、ユーザーの負担増大につながります。

こういった問題を解決するシングルサインオンについて、それを実現する製品が多数世に出ていますが、代表的な認証モデル4種類について、概要と特徴を説明していきます。

エージェント型

「エージェント型」は代表的なシングルサインオンの実現方法です。エージェントとは、仲介者を意味します。ここではアプリケーションの利用認証を仲介する、サーバー側にあるモジュールのことをいいます。

ユーザーがWebサーバーにリクエストを送信すると、Webサーバー内の「エージェント」がユーザーのログイン状態、アクセス権限といった、アプリケーションの利用に必要な情報を認証サーバーに問い合わせます。認証サーバーはWebサーバーに回答を返却、利用OKという結果ですと、コンテンツが表示されます。

なお、エージェント型は同一ネットワーク内での、シングルサインオンを実現するものです。導入には、アプリケーション側のカスタマイズが必須になります。

リバースプロキシ型

もうひとつ、よく知られたのが「リバースプロキシ型」です。ネットワーク環境では必ずといっていいほど使われる、プロキシサーバーと構造的には同じものになります。

もちろん、語頭に「リバース」とついていますので、働き方は一般的なプロキシサーバーとは逆です。ユーザーはまず、リバースプロキシにアクセスし、リバースプロキシはWebサーバーにアクセスを中継します。認証は、リバースプロキシが認証サーバーに対して行います。

リバースプロキシ型はエージェント型と同様で、同一ネットワーク上でのシングルサインオンを実現するものです。エージェント型にはない利点として、Webサーバーをユーザーから隠蔽できることがあります。導入するリバースプロキシによっては、Webアプリケーション側のカスタマイズが不要になります。

クライアント型

「クライアント型」は、クライアントエージェント型とも呼ばれます。クライアントに導入したエージェントソフトが、アクセス対象となるシステムのユーザーIDとパスワードを、ユーザーに代わって入力してくれるというものです。

エージェントソフトを利用するという意味で、エージェント型と間違えそうですが、明確に別物です。一般的なエージェント型は、認証に認証サーバー(ディレクトリ・サービス)を使用します。クライアント型の場合、サーバーサイドのサービスを認証には使用しません。

システムの利用が想定されるクライアント全部に、エージェントソフトをインストールする必要があります。しかし、製品によっては、クラウドサービスなどの外部アプリケーションまで、シングルサインオンの適用が可能になります。

フェデレーション型

「フェデレーション型」は、連携型という別名を持ちます。異なるサービスで、共通のユーザーIDとパスワードを用いることで、シングルサインオンを実現する方式です。

新しいインターネットサービスサービスの利用登録の際、他のサービスのログインIDとパスワードを使って利用が可能になるという内容を表示した画面を、ご覧になった方も多いでしょう。

これがまさに認証連携、フェデレーション型のシングルサインオンの例となります。

フェデレーション型認証を有効にする技術としてよく知られているのが、SAMLやOpenIDです。これらは標準化されていますので、イントラネット側に組み込むことが可能です。結果、シームレスな認証とアクセスが可能になるのです。

進化するシングルサインオン

イントラネットの利用のみでしたら、エージェント型あるいはリバースプロキシ型の利用が可能になります。クラウドなど、インターネットサービスもシングルサインオンの範囲に含めたい場合は、フェデレーション型を検討することになるのではないでしょうか。

システム利用による利便の享受と、安全性確保の両立は困難な面はあるものの、今や必須事項といえるでしょう。シングルサインオンは、その課題解決への効果的なアプローチとなるはずです。

(画像は「Pixabay」より)