1. 序章

シングルサインオンメカニズム（ SSO ）を使用すると、ユーザーはアプリケーションに1回ログインするだけで、関連するすべてのシステムに個別にログインしなくてもアクセスできます。 この記事では、SSOがどのように機能するか、およびその手法の長所と短所を定義します。

2. 基礎

前述したように、 SSOのおかげで、ユーザーはサービスに一度ログインすると、関連するすべてのアプリケーションに自動的にログインできます。例として、Googleアカウントについて考えてみましょう。 GmailなどのGoogleのサービスの1つにログインすると、ユーザーはYoutube、Google Play、Googleドライブなどの他のすべての独立したアプリケーションへのアクセスを許可されます。 さらに、これらの関連システム全体で同じクレデンシャルが使用されます。

組織では、従業員は毎日複数のアプリケーションを使用しています。 SSOは、それらに個別にログインする必要をなくします。 さらに、ユーザーは複数の資格情報を保存または記憶する必要はありません。 したがって、システム管理者は、システムへのアクセスを構成する作業が少なくて済みます。 その後、クレデンシャルを忘れたり機能しなくなったりする可能性が低くなり、処理が容易になります。 ご覧のとおり、SSOは組織内の複数のプロセスを改善できます。

2.1. フェデレーションID

まず、フェデレーションIDが処理する必要がある懸念事項を定義しましょう。

認証は、ユーザーのIDを確認するプロセスです。簡単に言えば。 それは、ユーザーが本当に彼または彼女が主張する人であることを保証します。 パスワード、ソフトウェアまたはハードウェアトークン、個人識別番号、指紋など、一般的な認証方法はたくさんあります。

承認プロセスは、ユーザーが特定のリソースにアクセスする権限を持っているかどうかを確認します。たとえば、オンラインショップの管理者は、製品の価格を更新するなど、購入者がアクセスしてはならないリソースにアクセスできます。 承認は常に認証後に行う必要があります。

ユーザー管理は、ユーザーアカウントの監視です。 したがって、一般的に言えば、それらを作成、保存、および変更します。

シングルサインオンは、認証プロセスにのみ関連しています。 したがって、それ自体はフェデレーションIDではなく、その一部にすぎません。 その使命は、ユーザーのIDを確認し、関連するアプリケーション間でその情報を共有することです。

SSOが実際にどのように機能するかを見てみましょう。

2.2. ワークフロー

SSOが解決する問題を簡単に紹介しましょう。 ユーザーがdomain1とdomain2で同じログインとパスワードでログインできるようにする必要があります。 さらに、ユーザーがすでにdomain1にログインしている場合は、domain2に自動的にログインする必要があり、その逆も同様です。 解決策は、ドメイン間でセッションデータを共有することです。 ただし、同一生成元ポリシーのため、Cookieをドメイン間で共有することはできません。 したがって、SSOは、ユーザーを認証し、さまざまな方法でセッションデータを共有することで救いの手を差し伸べます。

次のセクションでは、さまざまなSSO構成を紹介します。 一般に、ユーザーを識別し、セッションデータを共有する中央ドメインがあります（例： JWT ）。 SSOプロセスを大まかに説明しましょう。

  1. ユーザーがdomain1に入る
  2. domain1はセッションCookieがないことを確認するため、ユーザーをSSOシステムにリダイレクトします
  3. SSOシステムはセッションCookieがないことを確認するため、ログインページを表示します
  4. SSOシステムがユーザーを認証します
  5. SSOシステムはセッションCookieを設定します（認証が成功した場合）
  6. SSOシステムは、セッションデータを含むパラメーター（JWTなど）を使用してdomain1にリダイレクトします。
  7. domain1は、渡されたデータを使用してセッションCookieを設定します
  8. ユーザーがdomain2に入る
  9. domain2はセッションCookieがないことを確認するため、ユーザーをSSOシステムにリダイレクトします
  10. SSOシステムは、セッションCookieが存在することを確認します
  11. SSOシステムは、セッションデータを含むパラメーター（JWTなど）を使用してdomain2にリダイレクトします。
  12. domain2は、渡されたデータを使用してセッションCookieを設定します

上記の方法が最も一般的な方法です。 実装されているSSO構成とアーキテクチャによって異なる場合があります。 以下に、前述のプロセスを図で示します。

3. アーキテクチャ

SSOの実装に使用できるアーキテクチャは複数あります。

一般的なユースケースは、WEBSSOによって処理されます。 WEB SSOは、Webブラウザを使用してアクセスできるサービスのみを対象としています。 これにより、ユーザーは1回のログインでWebサーバーのグループにアクセスできます。 WEBSSOを実装するための主なアプローチは2つあります。

  • 認証プロセスを制御するWebベースのリバースプロキシを使用する
  • 特定の各サーバーにインストールされているエージェントを使用する

このアーキテクチャは通常、ユーザーの認証状態を追跡するためにCookieを使用します。 前のセクションで説明したSSOプロセスは、WEBSSOアーキテクチャに適用されます。

次のアーキテクチャは、エンタープライズシングルサインオン（E-SSO）と呼ばれます。 これはWEBSSOとは少し異なり、変更はエンドユーザーに対して透過的です。 ユーザーはE-SSOクライアントの単一の資格情報を持っており、一度だけログインします。 E-SSOは、関連するアプリケーションへのログインを処理します。 違いは、サービスが認証用に個別の資格情報を持つことができることです。 E-SSOクライアントによって維持されます。 さらに、アプリケーションはE-SSOクライアントについて知る必要はありません。 このアーキテクチャは、特に組織が既存の構成済みシステムにSSOを提供する場合に特に役立ちます。

SSOは、単一の組織内での使用を目的としています。 フェデレーションSSOアーキテクチャは、別々の組織間で信頼される認証データ（通常はトークン）を提供します。このアーキテクチャは、WS-Federation、 OAuth 、SAMLなどの一般的なプロトコルを使用してトークンを渡します。 SSOアーキテクチャは、複数の組織が協力している状況で特に役立ちます。

4. 長所と短所

SSOソリューションの長所と短所を分析してみましょう。

長所：

  • 複数のサービスを使用するエンドユーザーのログインプロセスを容易にします
  • 資格情報を忘れたり、機能しなかったりするケースを減らします。 したがって、ヘルプデスクのコストと作業負荷が軽減されます
  • 資格情報の管理を簡素化します
  • 資格情報の公開を減らすことでセキュリティを向上させます
  • 組織間の統合と協力を改善できる

短所：

  • SSOプロバイダーがダウンすると、すべてのアプリケーションにアクセスできなくなる可能性があります
  • SSOの実装には、時間とコストがかかる可能性があります
  • SSOクレデンシャルを盗むと、ハッカーは関連するすべてのシステムにアクセスできるようになります
  • 強力で複雑なパスワードの使用を強制する必要があります
  • 一部のSSOプロバイダーは、サードパーティとデータを共有します。 プロバイダーの条件とポリシーのしっかりとした調査が必要です

5. 結論

この記事では、シングルサインオンについて詳しく説明しました。 まず、SSOの基本とフェデレーションIDの主な懸念事項を紹介しました。 次に、一般的なSSOワークフローを示しました。 次に、さまざまなSSOアーキテクチャについて簡単に説明しました。 最後に、SSOソリューションの長所と短所の概要を説明しました。