シングルサインオンの仕組み

シングルサインオン（SSO）は、一組の資格情報を使用するだけで、ユーザを複数のアプリケーションとWebサイトでセキュアに認証できるようにする認証方法です。

SSOは、サービスプロバイダとして知られるアプリケーションとOneLoginなどのIDプロバイダの間に設定された信頼関係に基づいて機能します。この信頼関係は、多くの場合、IDプロバイダとサービスプロバイダの間で交換される証明書に基づいています。この証明書は、IDプロバイダからサービスプロバイダに送信されるID情報に署名するために使用できます。これによりサービスプロバイダは、証明書が信頼できるソースから発行されていることを把握します。SSOでは、このIDデータはトークンの形を取り、ユーザのEメールアドレスやユーザ名など、ユーザに関する識別情報が含まれています。

ログインフローは通常、次のようになります。

1. ユーザはアクセスしたいアプリケーションまたはWebサイト（サービスプロバイダ）を閲覧します。
2. サービスプロバイダは、ユーザを認証するリクエストの一環として、Eメールアドレスなど、ユーザに関する情報が含まれるトークンをSSOシステム（IDプロバイダ）に送信します。
3. IDプロバイダは、まず、ユーザが既に認証されているかどうかを確認します。認証済みの場合は、ユーザにサービスプロバイダのアプリケーションへのアクセスを許可し、ステップ5に進みます。
4. ユーザがログインしていない場合は、IDプロバイダが要求する資格情報を提供してログインするように求めます。これは単純にユーザ名とパスワードの場合もありますが、ワンタイムパスワード（OTP）など、他の形式の認証が含まれる場合もあります。
5. IDプロバイダは提供された資格情報を検証すると、認証が成功したことを確認するトークンをサービスプロバイダに送り返します。
6. このトークンは、ユーザのブラウザを介してサービスプロバイダに渡されます。
7. サービスプロバイダが受け取ったトークンは、初期設定の間にサービスプロバイダとIDプロバイダの間で設定された信頼関係に基づいて検証されます。
8. ユーザはサービスプロバイダへのアクセスを許可されます。

ユーザが別のWebサイトにアクセスしようとすると、新しいWebサイトではSSOソリューションによって設定された同様の信頼関係が必要になり、認証フローは同じステップに従います。

SSOトークンとは、SSOプロセス中に、あるシステムから別のシステムに渡される一連のデータまたは情報です。このデータは、ユーザのEメールアドレスや、トークンの送信元のシステムに関する情報などの場合があります。トークンはデジタル署名されている必要があります。これにより、受信側はトークンが信頼できるソースによるものであることを確認できます。このデジタル署名に使用される証明書は、初期設定プロセス中に交換されます。

この質問の答えは「場合によって異なる」です。

SSOがセキュリティを強化できる理由は多数あります。シングルサインオンソリューションを使用することで、ユーザと管理者はどちらも、ユーザ名とパスワードの管理を簡素化できます。ユーザはさまざまな資格情報を把握する必要がなくなり、より複雑な1つのパスワードを覚えておくだけで済みます。SSOでは、多くの場合、ユーザはアプリケーションにはるかに迅速にアクセスできます。

また、SSOによって、ヘルプデスクがパスワードを忘れたユーザに対応する時間を大幅に短縮できます。管理者は、パスワードの複雑さや多要素認証（MFA）などの要件を一元的に制御できます。ユーザが組織を離れたときも、管理者はその人の全社的なログイン権限を迅速に破棄することができます。

シングルサインオ���には欠点もあります。例えば、もう少しロックダウンしておきたいアプリケーションがあるかもしれません。この理由から、例えばユーザが特定のアプリケーションにログインする前に追加の認証要素を要求したり、これによりセキュアなネットワークに接続していないユーザが特定のアプリケーションにアクセスするのを阻止したりできるSSOソリューションを選択することが重要です。

SSOソリューションの詳細な実装方法は、使用しているSSOソリューションによって異なります。しかし、詳細な手順がどのようなものであるとしても、実装の明確な目的と目標を設定する必要があります。次の質問に答えられるようにします。

• どのような種類のユーザにサービスを提供しており、それぞれどのような要件がありますか?
• 探しているのはオンプレミスソリューションですか、それともクラウドベースのソリューションですか?
• このソリューションは、企業やあなたのニーズの変化に応じて調整できますか?
• 信頼できるユーザのみがログインできるようにするために、どのような機能が必要ですか? 例えば、MFA、適応型認証、デバイストラスト、IPアドレスのホワイトリストなどがあります。
• どのシステムと統合する必要がありますか?
• APIアクセスは必要ですか?

シングルサインオンとパスワードボールトまたはパスワード管理機能の違いを理解することが重要です。後者2つもSSOと呼ばれることがありますが、シングルサインオンではなく、Same Sign-on（同じサインオン）を意味します。パスワードボールトを使用すると、同じユーザ名とパスワードを使用できますが、別のアプリケーションやWebサイトに移動するたびに入力する必要があります。パスワード・ボールト・システムは、各種アプリケーションの資格情報を単純にすべて保存して、必要に応じて挿入します。アプリケーションとパスワード・ボールト・システムとの間に信頼関係は設定されません。

SSO（シングルサインオン）を使用すると、SSOソリューションを介してログインした後は、会社が承認したすべてのアプリケーションとWebサイトに、再度ログインする必要なくアクセスできます。これにはクラウドアプリケーションだけでなくオンプレミスアプリケーションも含まれ、多くの場合、SSOポータル（ログインポータルとも呼ばれます）から利用できます。

利用できるSSOのオプションを調査していると、SSOソフトウェア、SSOソリューション、SSOプロバイダなどの用語を目にすることがあります。多くの場合、その違いは企業が自身を分類する方法の違いにすぎません。ソフトウェアは、オンプレミスにインストールされるものを示唆します。通常、一連の特定のタスクのみを行うために設計されています。ソリューションは、コア製品の機能を拡張またはカスタマイズする機能があることを示唆します。プロバイダは、ソリューションを作成またはホストしている企業を指す方法です。例えば、OneLoginはSSOソリューションのプロバイダとして知られています。

シングルサインオン（SSO）について話すとき、多くの用語が使用されます。

• フェデレーションID管理（FIM）
• OAuth（特に最近のOAuth 2.0）
• OpenID Connect（OIDC）
• Security Access Markup Language（SAML）
• Same Sign On（SSO）

SSOは、実際にはフェデレーションID管理と呼ばれるより大きい概念の一部であるため、フェデレーションSSOと呼ばれる場合があります。FIMは、単に2つ以上のドメインまたはID管理システムとの間で作成された信頼関係を指します。シングルサインオンは、多くの場合、FIMアーキテクチャ内で利用可能な機能です。

OAuth 2.0は特定のフレームワークで、これもFIMアーキテクチャの一部とみなされる場合があります。OAuthは信頼関係に重点を置いて、ユーザのID情報がドメイン全体で共有されるようにします。

OpenID Connect（OIDC）は、シングルサインオン機能を提供するためにOAuth 2.0の上に構築された認証レイヤです。

Same Sign OnもSSOと呼ばれることがよくありますが、実際はシングルサインオンと同一ではありません。認証を行うエンティティ間の信頼関係が関与しないからです。システム間で複製される資格情報に依存しており、必要に応じてその資格情報を渡すだけです。シングル・サインオン・ソリューションほど安全ではありません。

シングルサインオンについて話し合うときによく出てくる特定のシステムもいくつかあります。Active Directory、Active Directoryフェデレーションサービス（ADFS）およびLightweight Directory Access Protocol（LDAP）です。

Active Directoryは、現在は特にActive Directory Directory Services（ADDS）を指しますが、これはMicrosoftの一元化されたディレクトリサービスです。一元管理を行うためにユーザとリソースがディレクトリに追加され、ADDSはNTLMやKerberosなどの認証プロトコルと連携します。したがって、ADDSに属するユーザは自分のマシンから認証して、ADDSと統合している他のシステムにアクセスできます。これはシングルサインオンの形式の1つです。

Active Directoryフェデレーションサービス（ADFS）は、フェデレーションID管理システムの一種で、やはりシングルサインオン機能を提供します。これはSAMLとOIDCの両方をサポートしています。ADFSは主に、ADDSと、Azure ADなどの他のシステムまたは他のADDSフォレストとの間の信頼関係を設定するために使用されます。

Lightweight Directory Access Protocol（LDAP）は単に、ディレクトリ情報を整理およびクエリするための方法を定義する業界標準です。LDAPを使用すると、ユーザやシステムなどのリソースを一元管理できます。ただし、LDAPはそれらのシステムへのログイン方法を定義しません。��まり、認証に使用される実際のプロトコルを定義しません。しかし、認証プロセスとアクセス制御プロセ���の一部として使用されることがよくあります。例えば、ユーザが特定のリソースにアクセスしようとしたときに、ユーザにそのリソースへのアクセス権があるかどうかを確認するために、LDAPを使用してそのユーザおよびユーザが属するグループをクエリする場合があります。OpenLDAPなどのLDAPソリューションは、Simple Authentication and Security Layer（SASL）などの認証プロトコルのサポートを通じて認証を提供します。

他の多くのアプリケーションがインターネット内での実行に移行したように、SSO機能も移行しています。OneLoginなど、クラウドサービスで実行するプラットフォームはSoftware as a Service（SaaS）SSOソリューションに分類できます。

最後に、App-to-App SSOまたはアプリケーション間SSOという言葉を聞いたことがあるかもしれません。これはまだ業界標準というわけではありません。ユーザのIDをエコシステム内の1つのアプリケーションから別のアプリケーションに渡すプロセスを説明するために、SAP Cloudによって使用される用語です。OAuth 2.0にいくぶん似ていますが、これは標準のプロトコルや手法ではなく、現在SAP Cloudに固有のものです。