よくある質問・用語集

  • もっと調べる
  • どうやって使う?

シングルサインオン(SSO)とは

シングルサインオン(SSO; Single Sign On)とは、1度のユーザIDとパスワードの認証により、組織(管理ドメイン)を超えて様々なシステムの認証を行えるようにする技術です。一般的に、アプリケーションやクラウドサービスは、個別の方法で認証を行っています。そのため、ユーザは利用するアプリケーションやサービスごとにIDとパスワードを管理する必要があります。また、それぞれにログイン処理を行う必要があります。シングルサインオンを導入すると、ユーザ名とパスワードの入力はシングルサインオンのシステムに1回だけ行えば良くなります。そのため、ユーザは多くのパスワードを管理する必要がなくなり、ログインの手間も減ります。

OpenAMとシングルサインオン

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

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

シングルサインオン(SSO)のメリット

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

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

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

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

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

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

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

シングルサインオン(SSO)のデメリット

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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サービスでは、ユーザ数での月額課金です。そのため、ランニング費用が高くなる傾向があります。

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

また、オープンソースソフトウェアは、オンプレミスのシステムと、インターネット上のサービスの両方に対して、シングルサインオンの機能を提供することができることも、大きなメリットです。

ここでは、シングルサインオンの機能を提供するオープンソースソフトウェアを紹介します。

Keycloak

Keycloakログイン

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

OpenAM

OpenAMログイン

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

シングルサインオンを実現するサービス〜IDaaS〜

最近は、業務でもインターネット上の様々なサービスを利用することが多くなりました。そのため、こうしたインターネット上のサービスをシングルサインオンで利用できるようにする仕組みとしてIDaaSが注目されています。

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

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

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

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

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

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

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

  • 可用性の維持

    シングルサインオンのシステムを構築する場合には、障害によってシングルサインオンの管理サーバや認証サーバが停止したり、性能不足になることがないように、システムの冗長化や負荷分散等の対策を最初から考える必要があります。

  • セキュリティの向上

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

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

デージーネットでは、KeycloakやOpenAMを使ったシングルサインオンのシステムの構築を行っています。シングルサインオンのソフトウェアとしては、用途に合わせてKeycloakやOpenAMを提案します。デージーネットでは、以前からOpenLDAPRADIUSなどの認証システムActiveDirectoryとの連携、多要素認証の仕組みなどを構築するサービスを行っています。そのため、これらの経験を生かして可用性の高いシングルサインオンの仕組みを構築することを目指しています。

【カテゴリ】:認証  

  • もっと調べる
  • どうやって使う?

【Webセミナー】社員教育や営業でも利用できる!OSSの動画配信システムの導入セミナー

日程: 12月17日(木)Webセミナー「BigBlueButton」を使用します。
内容: テレワークで利用できるOSSセミナー第5弾!今回は、社内で撮った録画を保管・共有できるオープンソースソフトウェアをご紹介します!
ご興味のあるかたはぜひご参加ください。

セミナー申込

関連用語

シングルサインオン(SSO)に関連するページ(事例など)

シングルサインオン(SSO)とは先頭へ