シングルサインオン

読み：しんぐるさいんおん　／　英語表記：Single Sign-On

一度の認証の結果を利用して、複数のシステムへ繰り返しログインする手間を減らす仕組み。本人確認の連携と、各サービスのアクセス権限の判断は区別する。

イマシルちゃんの解説

建物の受付で身分を確かめてもらうと、いくつかの部屋で使える入館証をもらえるとするよ。
部屋を移るたびに、最初から身分を説明しなくてよくなるんだ。
ただし、入館証があっても、すべての部屋に入れるわけではないよね。
落としたときに使われない工夫や、期限を過ぎたら無効にする仕組みも必要なんだ。

SSOは、本人確認を済ませた結果を複数のサービスで活用する考え方である。すべてのサービスに同じパスワードを設定することとは異なる。共通のパスワードを毎回入力するだけでは、ログイン操作の連携にならない。

利用者が誰かを確かめる処理と、その利用者にどの操作を認めるかを決める認可は別である。本人確認が成功しても、管理者向け機能の利用が許されるとは限らない。

方式	連携の中心
リバースプロキシ方式	共通の入口で本人確認を行い、背後のアプリケーションへ結果を伝える
エージェント方式	各サーバの連携部品が共通の認証基盤へ問い合わせる
フェデレーション方式	SAMLなどの標準により、信頼した発行元の結果を検証する

どの方式でも、結果の発行者を信頼できることと、受け取った内容が正しいことを確認する必要がある。

リバースプロキシに本人確認を集約し、利用者がその入口を経由して各サービスを使う構成がある。背後のアプリケーションへ利用者名などをHTTPヘッダーで伝える場合は、外部から付けられた同名ヘッダーをそのまま信用してはいけない。

各Webサーバを異なるインターネットドメインへ配置することは、SSOの必須条件ではない。利用者の確認方法として、パスワードのほかにクライアント証明書を使用する構成もある。サーバ証明書を提示するだけでは利用者の本人確認にならない。

サーバはCookieを利用してセッションの識別情報をブラウザへ保存させ、以後の要求で返送させることがある。正当なログインを示す情報は、サーバ側で検証する。利用者が任意の値を生成して本人確認済みと主張できる設計にはしない。

送信先の範囲はDomainやPathなどの条件に従う。無関係なドメインへ同じ値を自由に送れるわけではない。異なるサイト間の連携は、認証先へのリダイレクトや検証可能な応答を用い、単純な保存値の共有と区別する。

観点	確認すること
認証基盤の停止	複数サービスへ影響するため、冗長化を検討する
セッションの流出	パスワードを知らなくても悪用され得るため、保存値を保護する
有効期間	各サービス側の状態も含めて管理する
ログアウト	一つのサービスの終了が、他のサービスの終了まで保証するとは限らない

CookieのSecure属性は保護された通信での送信に、HttpOnly属性はスクリプトからの読取り制限に関わる。これらだけで、すべての不正アクセスを防げるわけではない。再認証が必要な重要操作も決めておく。