シングルサインオン（SSO）とは

シングルサインオン（SSO; Single Sign On）とは、1度のユーザIDとパスワードの認証により、組織（管理ドメイン）を超えて様々なシステムの認証を行えるようにする技術です。一般的に、アプリケーションやクラウドサービスは、個別の方法で認証を行っています。そのため、ユーザは利用するアプリケーションやサービスごとにIDとパスワードを管理する必要があります。最近は、一人の人が使うサービスやツールが増加し、たくさんのIDとパスワードを覚えることが必要になっています。さらに、最近では総当たり攻撃を防ぐために、複雑なパスワードを設定することが求められています。加えて、安全のためにサービスごとに異なるパスワードを都度登録することが好ましいとされています。ユーザは、こうした個別のパスワードを覚え、それぞれにログイン処理を行う必要があるのです。

シングルサインオンを導入すると、ユーザ名とパスワードの入力はシングルサインオンのシステムに1回だけ行えば良くなります。そのため、ユーザは多くのパスワードを覚えることが不要になり、ログインの度に発生する手間も軽減されます。

ただ、各種アプリケーションやサービスの認証は、個別に開発されているため、実現方式もログイン方法も違います。そのため、シングルサインオンの実装には、技術的な難易度が高いという大きな課題があります。

なお、シングルサインオンによく似た用語として、フェデレーションと呼ばれる用語も使われます。フェデレーションは、複数のWebサイト間でアカウントを連携し、シングルサインオンを実現する手法のことです。

シングルサインオン（SSO）のメリット

ここでは、シングルサインオンを導入すると得られる効果について解説します。

シングルサインオンを導入すると、利便性が向上する

例えば、社員一人ひとりがたくさんのIDやパスワードを抱えることになれば、IDパスワードを忘れた際にIDパスワードの再発行やアカウントロックが起きた時の処理に手間がかかります。また、パスワードが増えると、複数のパスワードを管理する側にも大きな負担となります。シングルサインオンを導入すると、ログイン処理の回数が減り、管理すべきパスワードの数も減ります。そのため、ユーザの利便性は飛躍的に向上し、管理者の作業負担の軽減にもつながります。

シングルサインオンのシステムで、アクセスの集中管理ができるようになる

シングルサインオンのシステムで、ユーザがどのサービスにアクセスできるかを管理することができるようになります。また、利用時間を制限したり、ログを取得することで、誰が、いつ、どのシステムを使っていたのかを管理することができるようになります。

複雑なパスワードの利用を促進する

ユーザは、複数のパスワードを覚える必要がなくなります。そのため、シングルサインオン用に1つの複雑なパスワードを設定しても記憶できます。そのため、複雑なパスワードの設定を促進することができ、安全性が強化できます。

シングルサインオン（SSO）のデメリット

実現すると非常に便利なシングルサインオンの仕組みですが、導入にはいくつかのデメリットがあります。

シングルサインオンは、導入が難しい

既存のシステムに、シングルサインオンを導入する場合、既存システムの一つ一つに対して、シングルサインオンの実現方法を検討する必要があります。対象となるアプリケーションが多ければ、導入の難易度も高くなります。また、対象のアプリケーションに合った認証方式がない場合には、アプリケーションの修正したり、シングルサインオンの対象から外すなどの対応も必要になるかもしれません。こうした理由から、シングルサインオンのシステムの導入は難易度が高く、追加の費用も発生しがちです。

シングルサインオンを導入したシステム全体のセキュリティの問題

シングルサインオンのシステムの場合には、万が一ユーザIDとパスワードが流出または漏洩すると、すべてのシステムにログインでき不正アクセスされてしまうリスクがあります。組織内のシステムの場合には、機密情報や個人情報の漏洩などの重大事故につながるかもしれません。また、インターネット上のシステムの際には、様々な個人情報が漏洩したり、SNSが改竄されたりという被害につながる可能性があります。

シングルサインオンのシステム障害時の影響

シングルサインオンのシステムでは、認証を一つのサーバで行います。そのため、そのサーバが停止すると、ユーザはすべてのサービスにアクセスできなくなってしまいます。そのため、システムの冗長化などを考慮する必要があります。

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

シングルサインオンを実現する方法には、以下のようにいくつかの種類があります。

• 証明書認証によるシングルサインオン
• エージェントによるシングルサインオン
• リバースプロキシによるシングルサインオン
• 代理認証によるシングルサインオン
• SAMLによるシングルサインオン
• OpenIDによるシングルサインオン
• Kerberos認証によるシングルサインオン

これらの方法は、それぞれに長所や短所があります。また、どの方式も万能ではなく、シングルサインオンに組み込みたいアプリケーションによって、適用できるものとできないものがあります。そのため、対象となるシステムに合わせて、複数の方式を組み合わせて利用するのが一般的です。

証明書認証によるシングルサインオン

通常のユーザ名とパスワードを使った認証ではなく、通信端末に設定されたクライアント証明書を用いてシングルサインオンを実現する方法です。証明書によって、ユーザとパスワードによる認証よりも強固な認証が行われ、ユーザ名とパスワードの入力を省くことができます。利用者は、証明書に設定されたパスワードを入力するだけで、すべてのシステムが使えるようになります。この方法は、アプリケーションやサーバが、TLS/SSL通信に対応し、証明書認証ができるようにする必要があります。WebサーバのApacheやNginxは、証明書認証に対応しています。Windowsシステムの場合には、Active Directoryにアカウント情報を集約し、ケルベロス認証や統合Windows認証を行う場合もあります。また、ベーシック認証など、Webサーバの認証機能をそのまま利用するタイプのアプリケーションでは、サーバの設定変更だけで容易に導入することができます。一方、全クライアントに証明書を配布する必要があります。セキュリティのレベルは高いですが、導入の手間がかかるといった点が短所となります。また、独自に認証を行っているアプリケーションでは、認証方法の改修が必要になります。

エージェントによるシングルサインオン

シングルサインオンの対象となるサイトやアプリに、認証用のエージェントを組み込む方法です。Webサーバは、リクエストを受けとると、シングルサインオンを管理するサーバにログイン状態を問い合わせて認証状態を確認します。シングルサインオンを管理するサーバがログイン状態やアクセス権限をチェックし、既に認証済みであれば、認証OKとします。まだ認証していなければ、認証画面を表示して認証を促します。

この方法は、すべてのアプリケーションやサービスに対して専用のエージェントを導入する必要があります。独自に認証を行っているアプリケーションでは、認証方法の改修が必要になるケースがあります。

リバースプロキシによるシングルサインオン

シングルサインオンの対象となるサービスやアプリケーションに対して、リバースプロキシを中継してアクセスするようにする方法です。リバースプロキシが、シングルサインオンを管理するサーバにログイン状態を問い合わせて認証状態を確認します。シングルサインオンを管理するサーバがログイン状態やアクセス権限をチェックし、既に認証済みであれば、認証OKとします。まだ認証していなければ、認証画面を表示して認証を促します。この方法は、エージェントによるシングルサインオンとまったく同じ考え方で実現されています。シングルサインオンの対象となるサービスやアプリケーションに対してエージェントを導入する代わりに、同じ機能をリバースプロキシに組み込む方法です。

この方法は、アプリケーションやサービスに対してエージェントを組み込む必要がなくなります。しかし、リバースプロキシに通信が集中するため、万一リバースプロキシが故障すると、すべての認証が行えなくなります。そのため、スループットの問題や、冗長性の問題などを考慮する必要があります。

代理認証によるシングルサインオン

プロキシサーバが、サービスやアプリケーションに代理でユーザ名とパスワードを送信し、認証を代行する方法です。サービスやアプリケーション側では変更がまったく必要がないところがメリットです。一方で、サービスやアプリケーション毎の代理認証プログラムを用意する必要があります。そのため、対象サービスやアプリケーションに合わせて調整や開発を行う必要があります。また、リバースプロキシと同様に、スループットの問題や冗長性の問題を考慮する必要があります。

SAMLによるシングルサインオン

シングルサインオン用のプロトコルである、SAMLを使ってシングルサインオンを実現する方法です。SAMLに対応したアプリケーションやサービスしか対象にできないのが最大の欠点ですが、徐々に対応するサービスやアプリケーションは増えています。SAMLでは、認証だけでなくユーザの属性情報等も共有することができます。そのため、認証だけでなくユーザの部署やメールアドレスなどの情報も含めて、サービスやアプリケーションに引き継ぐことができます。

OpenID ConnectやOAUTHによるシングルサインオン

シングルサインオン用のプロトコルである、OpenID ConnectやOAUTHを使ってシングルサインオンを実現する方法です。OpenID Connectに対応したアプリケーションやサービスしか対象にできないのが最大の欠点ですが、徐々に対応するサービスやアプリケーションは増えています。シングルサインオンを行う認証の機能に特化していますので、SAMLのようにユーザの属性を伝達することはできません。

ケルベロス認証によるシングルサインオン

ケルベロス（Kerberos）認証は、WindowsのActive Directoryに採用されている認証方式です。Linux系のディストリビューションでも利用することができます。この認証方式をつかうと、WindowsログオンやLinuxへのログインと組み合わせたシングルサインオンが可能になります。つまり、Windowsにログオンすれば、他のサービスにパスワードなしでログインできるような環境を実現することができます。

シングルサインオンのための認証規格

シングルサインオンを実現するためには、様々な試みが行われています。その一つが、認証方式の統一です。インターネット上では、Google認証やFacebook認証など、SNSの認証を利用した認証方式が利用されています。これらの認証方式はシングルサインオンに対応するための独自の認証規格に基づいています。最近ではクラウドサービスの普及に伴って、これらの規格の利用が推進され、シングルサインオンが利用しやすくなっています。

そのため、これから新規にシステムの導入を検討する場合には、シングルサインオンに対応した認証方式を使っているサービスやアプリケーションを選ぶことで、シングルサインオンに対応しやすくなります。

ここでは、シングルサインオンに対応するための3つの規格を紹介します。

SAML

SAML（Security Assertion Markup Language）とは、インターネットの異なるドメインの間でユーザ認証を行うための標準規格です。XMLをベースにして規格が定められています。SAMLでは、認証を行おうとする各アプリケーションやサービスは、サービスプロバイダ（Service Provider）とよばれます。サービスプロバイダは、IdP（Identity Provider）に認証要求をリダイレクトし、認証が行います。IdPによる認証が行われると、IdPはユーザ（ブラウザ）にSPへのリダイレクト先を通知します。ユーザがリダイレクト先へアクセスすることで、認証が完了します。

SAMLでは、認証だけでなく、アクセス制御や認証情報をSPへ伝達する仕組みも含まれています。一方で、仕様が複雑でアプリケーションの開発の難易度が高いといわれています。

OAuth 2.0

OAuth 2.0では、認証を受けるクライアントは、リソースオーナーにアクセストークンを発行してもらいます。アクセストークンには、権限の範囲と期間が設定されています。このアクセストークンをアプリケーションやサービスに渡すことで、認証を行います。OAuth 2.0は認証だけを扱います。そのため、ユーザの個別情報を伝達する仕組みがありません。

OpenID Connect

OpenID Connectは、OAuth2.0を拡張した仕組みです。信頼できる認証プロバイダが証明書（OpenIDトークン）を発行します。各アプリケーションやサービスは、この証明書を検査し利用の可否を判定します。証明書の作成のためには、SSL/TLSで使われているのと同じ非対称暗号化方式が使われます。汎用的な暗号方式をの仕組みを使っていることから、導入のハードルが低く、インターネット上の様々なサービスでも利用されています。OAuth 2.0にくらべて、ユーザの個別識別情報を引き渡す仕組みが含まれているのが特徴です。

シングルサインオンを実現するOSS

シングルサインオンを導入する方法は、オープンソースソフトウェア、製品、IDaaSサービスなどがあります。製品のほとんどは、ユーザ数ライセンスを採用をしています。そのため、利用者数が多いと導入のための初期費用が高くなる傾向があります。また、IDaaSサービスでは、ユーザ数での月額課金です。そのため、ランニング費用が高くなる傾向があります。

これに対して、オープンソースソフトウェアは、製品のようなユーザ数でのライセンス料金が必要ありません。その分、システムの冗長化や運用時のセキュリティの確保など、本当に必要な部分で資金を活用することができます。

また、オープンソースソフトウェアを使うと、自社内にシングルサインオンの認証サーバを配置することができます。それにより、オンプレミスの自社システムと、社外にあるクラウドサービスの両方に対して、シングルサインオンの機能を提供することができるようになります。これも、たいへん大きなメリットです。

ここでは、シングルサインオンの機能を提供するソリューションの中から、オープンソースソフトウェアのOpenAMとKeycloakを紹介します。

Keycloak

Keycloakは、OpenAMと比較しても新しいシングルサインオンのソフトウェアです。RedHatが開発し、商用版のRedHat SSOとしても販売されています。エージェント型の認証やSAMLやOpenID Connectなどに対応しています。また、連携可能なサービス/ソフトウェアとしてはOffice 365、AWSコンソール、Google Gsuite、Slackなどがあります。主要なネットサービスとの連携が可能なため注目されています。

「Keycloak〜シングルサインオンを実現する注目のOSS〜」へ

「Keycloakサービス連携調査報告書」へ

OpenAM

OpenAMは、もともとSun Microsystemsが開発したOpenSSOのフォークとして開発されたオープンソースのシングルサインオンを実現するソフトウェアです。様々な認証方式に対応することができるシングルサインオンのソフトウェアで、事実上のデファクトスタンダードです。しかし、現在はコミュニティが閉鎖され、いくつかのベンダーが維持管理を行っている状態です。

「OpenAM〜シングルサインオン〜」へ

シングルサインオンのサービス〜IDaaS〜

最近は、業務でもインターネット上の様々なWebサービスを利用することが多くなりました。そのため、こうしたインターネット上のサービスをシングルサインオンで利用できるようにする仕組みとしてIDaaSが注目されています。IDaaSは、Identity as a Serviceの略で、IDの管理をクラウド上で行うSaaS（Software as a Service）の一種です。

IDaaSは、利用するアプリケーションが対応していれば、比較的簡単に導入することができます。

しかし、ほとんどのIDaaSは、組織内の環境にあるオンプレミスの仕組をシングルサインオンにすることはできません。また、もしできるとしても、組織の内部で利用している認証情報を組織の外部に預けることはセキュリティの観点から好ましいものではありません。そのため、インターネット上だけでなく、組織内のシステムにもシングルサインオンを適用したい場合には、KeycloakやOpenAMなどを使ってシングルサインオンの仕組みを構築するのが一般的です。

なお、IDaaSでは、ユーザが入力したユーザ名やパスワードの情報は、IDaaSを提供する事業者に筒抜けです。これは、その事業者に合鍵を預けるのと同じで、非常に危険な面があります。そのため、その事業者が、本当に信頼のできる相手なのかを確認することが必須です。相手事業者の所属国の法律、契約約款、管理者の就業形態、コンプライアンスに対する考え方などを十分に確認して事業者を選ぶ必要があります。

「シングルサインオン（SSO）を構築するおすすめOSSとIDaaSの機能比較」へ

シングルサインオンの導入の注意点

こうした長所や短所のため、シングルサインオンのシステムの導入にあたっては、次のような課題について注意深く検討しておく必要があります。

• 連携できないサービスの検討

  シングルサインオンのシステム導入時に、どうしても適応できないアプリケーションやサービスが出てくることがあります。その場合には、アプリケーションにあわせた独自の認証モジュールの開発などが必要になるかもしれません。当然、追加でコストが掛かります。そのため、適用が難しいアプリケーションをどうするのかという課題について事前に検討した上で、導入する必要があります。

• 可用性の維持

  シングルサインオンのシステムに障害が発生すると、連携しているすべてのサービスが利用できなくなります。このように、その箇所が停止するとシステムの全体が停止するような箇所のことを単一障害点（Single Point of Failer：シングル・ポイント・オブ・フェイラー）と呼びます。シングルサインオンを提供するサーバは、単一障害点になりやすいため、障害や性能不足が発生しないように、冗長化や負荷分散等の対策を最初から考える必要があります。

• セキュリティ対策の向上

  シングルサインオンのシステムの導入にあたっては、セキュリティ向上策について一緒に考える必要があります。一般的には、ユーザ名とパスワードが漏えいするリスクに備えて、パスワードとパスワード以外の別の要素を組み合わせて認証を行う多要素認証の導入を検討します。また、万一、PCの盗難やパスワードの漏洩が発生した場合の対処方法について、事前に検討しておく必要があります。

デージーネットの取り組み

デージーネットでは、KeycloakやOpenAMを使ったシングルサインオンのシステムの構築を行っています。シングルサインオンのソフトウェアとしては、用途に合わせてKeycloakやOpenAMを提案しています。特に最近は、OpenID ConnectやSAMLに対応したOSSが増加したこともあり、Keycloakの導入事例が 増加しています。デージーネットでは、以前から認証のデータ共有のためにOpenLDAPやRADIUSなどの認証システムを構築してきました。また、最近では、ActiveDirectoryとの連携、多要素認証の仕組みなどを構築するサービスを行っています。そのため、これらの経験を生かして可用性の高いシングルサインオンの仕組みを構築することを目指しています。

なお、Keycloakのインストールや設定の詳細についてまとめた「Keycloak調査報告書」が次のリンクからダウンロードできます。

「Keycloak調査報告書」へ