TOP>製品/サービス>課題から探す>シングルサインオン(SSO)の選び方と仕組みの解説

シングルサインオン(SSO)の選び方と仕組みの解説

組織で利用するアプリケーションやシステムが増えるとともに、シングルサインオン(SSO)の需要も増えています。このページでは、対象システムに合わせて最適なSSOを選べるよう、方式の種類とその違い、仕組みについて解説します。

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

シングルサインオン(SSO)とは、1回の本人認証で、複数の異なるアプリケーションやシステムを利用できる認証の仕組みのことです。

システム毎のログインの手間やパスワード忘れに伴う負荷を最小限に減らせるので、利便性を求めるエンドユーザーからの実装要望が多いだけでなく、管理者にとっても、複数パスワードを覚えきれないユーザーへの対応負荷や、パスワードのメモ書きによる流出といったリスクを低減する効果が期待できます。

SSOの選び方とそれぞれの仕組み

SSOの仕組みはSaaS版、オンプレミス版どちらでも実装できます。実装方式は複数あり、自社のSSO対象システムの対応環境によって選ぶことができます(下の表を参照)。

例えば、代行認証方式はWebシステム、C/Sシステム両方をSSO対象とできますが、リバースプロキシ方式ではC/SのシステムをSSO対象にはできません。自社のシステムに対してSSOが可能な実装方式をあらかじめ確認しておくと、SSOの選定がしやすくなります。

<SSO対象システムとSSOの方式の対応>

C/S Web(オンプレミス) Web(クラウドサービス)
代行認証方式 〇※1
リバースプロキシ方式 × 〇※1
エージェント方式 × 〇※2 〇※1
SAML認証方式 × 〇※4 〇※3
  • ※1:クラウドサービス側で単純な認証連携ができない場合もあるので事前検証が必要となります
  • ※2:対象システムにAgentモジュールを導入する必要があり、対応できない場合もあります
  • ※3:SAMLのSP(Service Provider)として提供されている必要があります
  • ※4:SAMLのSP(Service Provider)として開発されている必要があります

また、それぞれの実装方式は下記のように仕組みが異なるため、考慮事項も異なります。


代行認証方式の仕組み

代行認証方式とは、クライアントPCに導入したエージェントが、SSO対象システムのログイン画面を監視し、ログイン画面が起動したら認証情報を代行入力(代理認証)する仕組みです。

(絵:代行認証方式)

代行認証方式はSSO対象システムの制限(Web、C/Sなど)が少なく、導入も比較的容易に行えます。構成上、クライアントPCにエージェントを導入することと、アカウント情報DBに接続できる環境が必要となります。


リバースプロキシ方式の仕組み

リバースプロキシ方式とは、Web上で実現するSSOの仕組みです。リバースプロキシと呼ばれる中継サーバで認証を行い、リバースプロキシ経由で対象システムにアクセスすることでSSOを実現しています。

(絵:リバースプロキシ方式)

この方式では、アクセスが全てリバースプロキシサーバ経由になることで、リバースプロキシサーバがボトルネックになるケースがあります。また、直接Webシステムにアクセスさせず、リバースプロキシ経由にするよう、ネットワークの設計を考慮する必要があります。ただし、SSO対象システムにはエージェントなどを導入する必要がないため、既存システムへの影響なく事前検証ができるなど、この後説明するエージェント方式よりもリリースまでの工数を短縮できます。


エージェント方式の仕組み

エージェント方式とは、リバースプロキシ方式同様、Web上で実現するSSOの仕組みです。SSO対象Webシステムにはそれぞれエージェントを導入しますので、導入するエージェントが各SSO対象システムに対応している必要があります。

(絵:エージェント方式)

一方でこの方式では、リバースプロキシ方式に比べ、アクセス集中によるボトルネックが発生しにくく、既存のネットワーク環境に変更を加える必要もない点がメリットです。


SAML認証方式の仕組み

SAML認証方式とは、主に、クラウドのリソースを含めたSSO実装に使う仕組みです。SAML(Security Assertion Markup Language)とは、異なるインターネットドメイン間でユーザー認証を行うための標準規格です。

SAMLは、IdP(Identity Provider)とSP(Service Provider)の2つの要素で構成されます。Webサービスを提供するSP側がSAMLに対応していれば、IdPが提供する認証情報を利用しSSOを実現できます。

(絵:SAML方式)

Google WorkspaceやMicrosoft 365、Salesforceなどの多くのクラウドサービスはSAMLに対応しているので、これらのサービスをSSO対象に含めたい場合は、実装するSSO製品(IdP)側でもSAML対応しているかを確認する必要があります。


SSO製品の選定ポイント

以上のように、SSOを実装する際には、SSOをしたい対象システムの対応環境を確認することが必要です。昨今では、オンプレミスからクラウドまでを含めたハイブリット環境が主流となっているため、対応環境が広いことは、基本的に求められる選定ポイントの1つです。

ただし、組織によっては、C/SシステムをSSOの対象として必須にする必要がある場合や、今後もオンプレミスのアプリケーションの利用が主流である場合もあります。また規定上、認証情報は社内に置かなければならない場合や、インターネット接続をしない、もしくは制限をしている環境である場合もあります。実際にSSO製品を選定する際は、いくつかの選択肢を用意すると良いでしょう。なおSSO製品によっては、上記の方式によるデメリット面もカバーできる仕様になっていることもありますので、いずれにしろ、選定時にはまず、販売元に相談するとスムーズです。例えばアシストでご紹介しているのは以下のラインナップです。

<アシストのSSO製品ラインナップ>

SSO対象 実装方法 製品名 開発元 特徴
全WebシステムのSSOを実現したい クラウドサービス(IDaaS)を利用 Okta Identity Cloud Okta Inc.(米国) ・SAML IdPとして機能し、SAML連携が可能(OpenID Connect、WS-Fedにも標準対応)。
SAML未対応のクラウドやWebアプリに対する代理認証も提供。
・連携用のテンプレートが数多く準備されており、クラウドサービスやWebアプリとの連携を容易に実現。
オンプレミスに導入 CloudLink 株式会社アイピーキューブ(日本) ・SAML IdPとして機能し、SAML連携が可能。SAML未対応のクラウドやWebアプリに対する代理認証も提供。
・エージェント方式により、SAML未対応のWebアプリにSAML SP機能を提供
C/Sを含めたアプリケーションのSSOを実現したい オンプレミスに導入 Password Assistant(ID管理製品「LDAP Manager 」のオプション製品) エクスジェン・ネットワークス株式会社(日本) ・代行認証方式
・統合ID管理製品のオプション製品として、SSOと統合ID管理をスムーズに実現可能

まとめ

以上のように、SSOの実装の仕組みには方式があります。SSO対象システムの環境が対応できない場合もあることを踏まえて、いくつかの選択肢の中から、自社の利用システムに合うSSOの選択をしましょう。


SSOについて、もっと知りたい方へ

●さらに詳しい資料をダウンロードいただけます

シングルサインオン製品の選び方

(PDF資料、21ページ)

シングルサインオンの仕組みの解説とそれを実現する製品についての資料をすぐにダウンロードいただけます。

(登録済みの方は以下からログイン、新規の方はお客様情報のご登録のみお願いしています。)

さらに知りたいご質問、ご相談も承ります。
以下「問い合わせをする」からお気軽にご連絡ください。


セキュリティに関するその他の課題

ページの先頭へ戻る