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

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

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

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

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

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

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

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

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

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

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

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

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

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

＜アシストのSSO製品ラインナップ＞

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