Loading article…
シングルサインオン（SSO）とは、ユーザーが単一のIDで、関連性はあるものの独立した複数のソフトウェアシステムにログインできるようにする認証方式です。
真のシングルサインオンとは、ユーザーが一度ログインすれば、認証情報を再入力することなくサービスにアクセスできる仕組みです。
これは、軽量ディレクトリアクセスプロトコル（LDAP）と（ディレクトリ）サーバーに保存されたLDAPデータベースを使用して実現されることが多い、同一サインオン（ディレクトリサーバー認証）と混同してはならない。 [ 1 ] [ 2 ]
シングルサインオンのシンプルなバージョンは、サイトが共通のDNS親ドメインを共有している場合に限り、Cookieを使用してIPネットワーク上で実現できます。 [ 3 ]
明確にするために、ディレクトリサーバー認証（同一サインオン）とシングルサインオンを区別します。ディレクトリサーバー認証とは、各アプリケーションごとに認証を必要とするものの、ディレクトリサーバーから同じ認証情報を使用するシステムを指します。一方、シングルサインオンとは、単一の認証で認証トークンを構成済みのアプリケーションにシームレスに渡すことにより、複数のアプリケーションへのアクセスを提供するシステムを指します。
逆に、シングルサインオフまたはシングルログアウト（SLO）とは、サインアウトという単一の操作で複数のソフトウェアシステムへのアクセスを終了できる特性のことです。
アプリケーションやリソースによってサポートされる認証メカニズムが異なるため、シングルサインオンは、初期認証に使用された認証情報を内部的に保存し、異なる認証メカニズムに必要な認証情報に変換する必要があります。
OpenIDやOpenID Connectなどの他の共有認証方式では、ユーザーがリソースへのサインオン時に選択を行う必要があるサービスが提供されていますが、それらのサービス（ユーザーの同意など）を無効にすれば、シングルサインオンとして構成できます。Facebook Connectのようなフェデレーション型ソーシャルログオンは増加傾向にありますが、新しいリソースへの初回登録時にユーザーが同意事項を入力する必要があるため、厳密な意味でのシングルサインオンとは限らないものもあります。
シングルサインオンを利用するメリットは以下のとおりです。
SSOは、他のすべてのアプリケーションやシステムが認証目的で使用する集中認証サーバーを共有し、ユーザーが認証情報を複数回入力する必要がないようにする技術と組み合わせます。
シングルサインオンでは企業内のさまざまなレベルの安全なアクセスへの対応が非現実的であり、そのため複数の認証サーバーが必要になる場合があるという事実を反映するために、一部では縮小サインオン（ RSO）という用語が使用されています。[ 6 ]
シングルサインオンは、ユーザーが最初に認証されると多くのリソースへのアクセスを可能にするため（「城の鍵」）、認証情報が他の人に知られて悪用された場合の悪影響が増大します。したがって、シングルサインオンではユーザー認証情報の保護に重点を置く必要があり、スマートカードやワンタイムパスワードトークンなどの強力な認証方法と組み合わせるのが理想的です。[ 6 ]
シングルサインオンは、高可用性認証システムへの依存度も高めます。これらのシステムの可用性が失われると、SSO で統合されたすべてのシステムへのアクセスが拒否される可能性があります。SSO は、システム運用を維持するためにセッションフェイルオーバー機能で構成できます。[ 7 ] ただし、システム障害のリスクがあるため、セキュリティシステムや工場現場システムなど、常にアクセスを保証する必要があるシステムでは、シングルサインオンは望ましくない場合があります。
さらに、 Facebookなどのソーシャルネットワーキングサービスを利用したシングルサインオン技術を使用すると、生産性上の理由からソーシャルメディアサイトをブロックしている図書館、学校、職場などでサードパーティのウェブサイトが使用できなくなる可能性があります。また、中国とその「ゴールデンシールドプロジェクト」のような積極的な検閲体制を持つ国では、サードパーティのウェブサイトが積極的に検閲されていなくても、ユーザーのソーシャルログインがブロックされると事実上ブロックされるため、問題が発生する可能性があります。[ 8 ] [ 9 ]
2012 年 3 月、[ 10 ]研究論文で、ソーシャル ログインメカニズムのセキュリティに関する広範な研究が報告されました。著者らは、 OpenID ( Google IDおよび PayPal Access を含む)、Facebook、Janrain、Freelancer、FarmVille、Sears.comなどの著名な ID プロバイダーおよびリライング パーティの Web サイトに 8 つの重大な論理的欠陥を発見しました。研究者らは、欠陥の発見を公表する前に ID プロバイダーおよびリライング パーティの Web サイトに通知したため、脆弱性は修正され、セキュリティ侵害は報告されていません。[ 11 ]
2014 年 5 月に、 Covert Redirectという脆弱性が公表されました。[ 12 ]これは、シンガポールの南洋理工大学の数学博士課程の学生である発見者の Wang Jing 氏によって「 OAuth 2.0および OpenID に関連する Covert Redirect の脆弱性」として最初に報告されました。 [ 13 ] [ 14 ] [ 15 ]実際、ほぼすべてのシングル サインオン プロトコルが影響を受けます。Covert Redirect は、クロス サイト スクリプティング(XSS) またはオープン リダイレクトに脆弱なサードパーティ クライアントを利用します。[ 16 ]
2020年12月、連邦認証システムの欠陥が、 2020年の米国連邦政府のデータ侵害の際に攻撃者によって悪用されたことが判明した。[ 17 ] [ 18 ]
シングルサインオンの仕組み上、ログインしているウェブサイトにリクエストを送信してSSOトークンを取得し、そのトークンをログアウトしたウェブサイトにリクエストとして送信するため、トークンはHttpOnlyクッキーフラグで保護することができません。そのため、ログアウトしたウェブサイトにXSS脆弱性がある場合、攻撃者はトークンを盗み出し、セッションハイジャックを行うことができます。また、SSOに使用されるセッション（SSOトークンとは異なり、HttpOnlyクッキーフラグで保護できる）が盗まれた場合、攻撃者はSSOシステムを使用しているすべてのウェブサイトにアクセスできてしまうというセキュリティ上の問題もあります。
KerberosとSAMLで最初に実装されたシングルサインオンでは、ユーザーがアクセスする新しいリソースごとに個人情報を公開するかどうかをユーザーに選択させることはできませんでした。これは、Kerberosが発明されたMITのような単一の企業内、またはすべてのリソースが内部サイトである大企業内では十分に機能していました。しかし、Active Directory Federation Servicesのようなフェデレーションサービスが普及するにつれて、ユーザーのプライベート情報は、ユーザーからデータを収集した企業の管理下にない関連サイトに送信されるようになりました。GDPRのような法律でプライバシー規制が厳しくなっているため、 OpenID Connectのような新しい方法がより魅力的になり始めています。たとえば、Kerberosの起源であるMITは現在OpenID Connectをサポートしています。[ 19 ]
理論上、シングルサインオンは、電子メールアドレスなどの識別情報をリライングパーティ（認証情報コンシューマー）に開示することなく機能できますが、多くの認証情報プロバイダーは、認証情報コンシューマーに渡される情報をユーザーが構成することを許可していません。2019年現在、GoogleとFacebookのサインインでは、ユーザーが電子メールアドレスを認証情報コンシューマーと共有する必要はありません。iOS 13で導入された「 Appleでサインイン」では、ユーザーが新しいサービスにサインアップするたびに固有のリレー電子メールアドレスを要求することができるため、認証情報コンシューマーによるアカウントリンクの可能性が低くなります。[ 20 ]
Windows環境の場合、Windowsログイン時にTGT（チケット保証チケット）が取得されます。Active Directory対応アプリケーションはサービスチケットを取得するため、ユーザーは再認証を求められません。
Unix / Linux環境 - Kerberos PAMモジュール経由でログインすると、TGTが取得されます。Evolution 、Firefox、SVNなどのKerberos認証対応クライアントアプリケーションはサービスチケットを使用するため、ユーザーは再認証を求められません。
モバイル環境 - Apple はIOS 13でネイティブ Kerberos サポートを追加しました。 [ 21 ] Androidでは、モバイルデバイス管理サービスが Kerberos のサポートを追加できます。[ 22 ]
初回サインオン時には、スマートカードの提示が求められます。追加のソフトウェアアプリケーションもスマートカードを使用するため、ユーザーに認証情報の再入力を求める必要はありません。スマートカードベースのシングルサインオンでは、スマートカードに保存されている証明書またはパスワードのいずれかを使用できます。
統合Windows認証は、 Microsoft製品に関連する用語でMicrosoft Windows 2000で導入され、その後のWindows NTベースのオペレーティングシステムにも搭載されたSSPI機能に関するSPNEGO、 Kerberos、およびNTLMSSP認証プロトコルを指します。この用語は、Microsoft Internet Information ServicesとInternet Explorer間の自動認証接続を指す場合によく使用されます。クロスプラットフォームのActive Directory統合ベンダーは、統合Windows認証のパラダイムをUnix（Macを含む）およびLinuxシステムにも拡張しています。
セキュリティアサーションマークアップ言語（SAML）は、SAML IDプロバイダとSAMLサービスプロバイダ間でユーザーのセキュリティ情報を交換するためのXMLベースの方法です。SA ML 2.0は、 W3C XML暗号化とサービスプロバイダが開始するWebブラウザのシングルサインオン交換をサポートしています。 [ 23 ] SAMLベースのシングルサインオンでは、ユーザーエージェント（通常はWebブラウザ）を使用するユーザーがサブジェクトと呼ばれます。ユーザーは、SAMLサービスプロバイダによって保護されているWebリソースを要求します。サービスプロバイダは、ユーザーのIDを知りたい場合、ユーザーエージェントを介してSAML IDプロバイダに認証要求を発行します。IDプロバイダは、ユーザーの資格情報を提供するものです。サービスプロバイダは、 IDプロバイダからのユーザー情報を信頼して、サービスまたはリソースへのアクセスを提供します。
モバイルデバイスをアクセス資格情報として使用する、シングルサインオン認証の新しいバリエーションが開発されました。ユーザーのモバイルデバイスは、OpenID ConnectやSAML [ 24 ]などの認証方法と、モバイルデバイスをアクセスサーバーに識別するために使用されるX.509 ITU-T暗号化証明書を組み合わせて使用することにより、建物のアクセス制御システムやコンピュータシステムなどの複数のシステムに自動的にログインするために使用できます。
モバイルデバイスは「所有物」であるのに対し、パスワードは「知識」であり、生体認証（指紋、網膜スキャン、顔認識など）は「本人」である。セキュリティ専門家は、最高の保護のために、これら3つの要素のうち少なくとも2つ（多要素認証）を使用することを推奨している。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク){{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)