- シングルサインオン（SSO）を構築するおすすめOSSとIDaaSの機能比較
- ここでは、シングルサインオンを実現する各種のOSSとIDaaSを紹介します。
- シングルサインオンの仕組みと選び方
- ここでは、シングルサインオンの仕組みと、シングルサインオンを実現するためにソフトウェアやサービスを選定する時の選び方について説明します。
シングルサインオンの仕組みと選び方
シングルサインオン（SSO; Single Sign On）とは、1度のユーザIDとパスワードの認証により、組織（管理ドメイン）を超えて様々なシステムの認証を行えるようにする技術です。シングルサインオンを導入すると、ユーザが、様々なアプリケーションにログインする際に、ユーザ名とパスワードを入力する作業の手間が軽減され、業務効率が向上します。また、ユーザは、複数のパスワードを覚えることが不要になり、パスワード管理の負担から開放されます。このようにシステムの利便性が向上するため、シングルサインオンを導入する企業が増えています。
ここでは、シングルサインオンの仕組みを説明し、シングルサインオンを実現するためにソフトウェアやサービスを選定する時の選び方と検討のポイントについて説明します。
シングルサインオンの仕組み
シングルサインオンを実現する仕組みには、以下のようにいくつかの種類があります。
Kerberos認証
Kerberos（ケルベロス）認証は、WindowsのActiveDirectoryに採用されている認証方式です。Linux系のディストリビューションでも利用することができます。この認証方式をつかうと、WindowsログオンやLinuxへのログインと組み合わせたシングルサインオンが可能になります。つまり、Windowsにログオンすれば、他のサービスにパスワードなしでログインできるような環境を実現することができます。
SAML認証
シングルサインオン用のプロトコルである、SAMLを使ってシングルサインオンを実現する方法です。SAMLは、クラウドサービスなどをシングルサインオンで利用するために使われることが多いプロトコルです。SAMLでは、認証だけでなくユーザの属性情報等も共有することができます。そのため、認証だけでなくユーザの部署やメールアドレスなどの情報も含めて、サービスやアプリケーションに引き継ぐことができます。
SAMLの方式では、上の図のようなフローで認証を行います。シングルサインオンの要となる認証機能を提供するシステムをIdP（Identity Provider）と呼びます。
SAMLでは、認証だけでなく、認証の際に関連したユーザ情報をサービスプロバイダに提供することができます。この機能はフェデレーションと呼ばれています。SAMLはフェデレーション型の認証方式とも言われます。
OAuth認証
シングルサインオンの認可用のプロトコルである、OAuthを使ってシングルサインオンを実現する方法です。SAMLとは違い、ユーザの情報を伝達するフェデレーションの機能を提供することはできません。
OpenID Connect認証
OAuthの認証機能を強化したシングルサインオン用の認証プロトコルである、OpenID Connectを使ってシングルサインオンを実現する方法です。SAMLと同様に、ユーザ情報を提供することのできるフェデレーション型の認証方式です。
エージェント認証
Kerberos認証、SAML認証、OpenID認証に対応していないアプリケーションやサービスに利用する認証方式です。シングルサインオンの対象となるWebサイトやアプリに、認証用のエージェントを組み込みます。アプリケーションの改修が必要となるため注意が必要です。
リバースプロキシ認証
シングルサインオンの対象となるサービスやアプリケーションに対してエージェントを導入する代わりに、同じ機能をリバースプロキシに組み込む方法です。シングルサインオンの対象となるサービスやアプリケーションには、リバースプロキシを通じてアクセスすることになります。そのため、リバースプロキシに通信が集中するため、万一リバースプロキシが故障すると、すべての認証が行えなくなります。導入する場合には、スループットの問題や、冗長性の問題などを考慮する必要があります。
代理認証
プロキシサーバが、サービスやアプリケーションに代理でユーザ名とパスワードを送信し、認証を代行する方法です。サービスやアプリケーション側では変更がまったく必要がないところがメリットです。一方で、サービスやアプリケーション毎の代理認証プログラムが必要になります。そのため、対象サービスやアプリケーションに合わせて調整や開発を行う必要があります。また、リバースプロキシと同様に、スループットの問題や冗長性の問題を考慮する必要があります。
シングルサインオンのサービスやソフトウェアの選び方
これらの認証の方法には、それぞれに長所や短所があります。また、どの方式も万能ではなく、シングルサインオンに組み込みたいアプリケーションによって、適用できるものとできないものがあります。そのため、対象となるシステムに合わせて、複数の方式を組み合わせて利用するのが一般的です。また、利用するIDやパスワードを、どのように管理するのかも検討する必要があります。
認証方式を検討する
シングルサインオンのシステムを導入する場合には、まず適切な認証方式について検討する必要があります。
単一方式のシングルサインオンのシステム
例えば、OSSのWebメールのソフトウェアのRoundcubeはKerberos認証に対応しています。また、WindowsログオンでもKerberos認証を使用しています。そのため、Kerberos認証に対応したSSOの仕組みを導入すれば、Windowsログオン時に認証を行っただけで、Roundcubeの認証を連携し、自動的にログインするようにすることができます。
また、OSSのオンラインストレージのソフトウェアであるNextcloudは、SAML認証に対応していますが、Kerberos認証には対応していません。そのため、Kerberos認証だけをサポートしているSSOのシステムでは、シングルサインオンに組み込むことができません。
複数の方式を採用しているシングルサインオンのシステム
一方で、Kerberos認証とSAML認証の両方を実装しているシステムを使えば、WindowsログオンとRoundcubeはKerberos認証で、NextcloudはSAML認証でシングルサインオンに参加することができます。このように、異なる複数の方式をサポートしていると、シングルサインオンのシステムに組み込むことができるアプリケーションの幅が大きく広がります。そのため、複数の認証方式をサポートしているソフトウェアを選ぶ必要があります。
バックエンドの認証システムのサポート
シングルサインオンのシステムを検討する時には、ユーザ情報を管理する方法を考慮しておく必要があります。次のような方法がありますが、既にIDが統合されている環境では、そのID統合の仕組みに併せたユーザ管理方法を利用できると、スムーズに導入が行えます。
シングルサインオンシステムの内蔵データベース
独自の認証データベースを管理する方法です。現在の利用ユーザにあわせて、ユーザ情報を登録する必要があります。
LDAPサーバ
LDAPサーバを使ってID統合を実現している環境の場合には、LDAPに対応したシングルサインオンのシステムを選ぶ必要があります。それによって、スムーズにシングルサインオンに移行できます。
ActiveDirectory
ActiveDirectoryはLDAPの一種です。そのためActiveDirectoryでID管理を行っている場合にも、LDAPに対応したシングルサインオンのシステムを選ぶのが便利です。ActiveDirectoryはKerberos認証方式もサポートしているため、ActiveDirectoryは非常に便利です。
多要素認証の導入
シングルサインオンのシステムでは、一般的にはユーザ名・パスワードを使った認証が行われます。これは、人の記憶を使った認証方法です。多要素認証では、それ以外に人が所有しているもの、人の身体的な特徴など、別の要素を使って認証を行います。
シングルサインオンのシステムでは、一回認証を行うと参加しているすべてのアプケーションの認証が許可されます。そのため、ユーザ名やパスワードなどの利用者データが漏洩すると非常に危険だというデメリットがあります。
こうしたリスクを避けるために、より高度なセキュリティを実現することが求められ、多要素認証の仕組みを利用することが推奨されています。
シングルサインオンで利用できるOSS
シングルサインオンのシステムでは、クラウド上のサービスを利用する方法とオンプレミスにシステムを作る2つの方法があります。
クラウド型のシングルサイオンのサービスでは、クラウド上の様々なWebサービスをシングルサインオンにすることができます。しかし、社内のアプリケーションをシングルサインオンにすることはできないため不便です。また、利用ユーザ数が増えると、コストがかかるという問題があります。
オープンソースソフトウェアを使ってシングルサインオンのシステムを構築すれば、ユーザ数が多い場合でもコストを削減することができます。また、自社内にサーバを配置することにより、オンプレミスのアプリケーションとクラウド上のアプリケーションの両方を、シングルサインオンとすることができます。
ここでは、シングルサインオンのシステムで活用できるOSSについて解説します。
シングルサインオンのシステム
シングルサインオンを実現するためのオープンソースソフトウェアとしては、KeycloakとOpenAMの2つのソフトウェアがよく使われています。OpenAMは、高機能ですがコミュニティの活動が行われていないため、最近はKeycloakが使われるようになっています。ここでは、各OSSがサポートしている仕組みを記載します。
| 機能 | Keycloak | OpenAM | 備考 |
|---|---|---|---|
| エージェント型認証 | ○ | ○ | Keycloakではクライアントアダプタ |
| リバースプロキシ型認証 | ○ | ○ | |
| SAML | ○ | ○ | |
| OpenID Conenct | ○ | ○ | |
| OAuth | ○ | ○ | |
| 代理認証 | × | ○ | |
| SNS連携 | ○ | ○ | |
| LDAP連携 | ○ | ○ | |
| ActiveDirectory連携 | ○ | ○ | |
| OTP認証 | ○ | ○ | |
| 多要素認証 | ○ | ○ | |
| アダプティブ認証 | × | ○ | |
| デバイスプリント認証 | × | ○ | |
| ユーザによるアカウント管理 | ○ | ○ | |
| ユーザによるパスワード管理 | ○ | ○ | |
| アクセス制御 | ○ | ○ | OpenAMはより高機能 |
「Keycloak〜シングルサインオンを実現する注目のOSS〜」へ
Apacheモジュール（mod_auth_openidc）
Apacheモジュールのmod_auth_openidcは、WebサーバのApacheにOpen IDConnectの認証機能を組み込むために利用できるツールです。これまでBasic認証方式で認証を行っていたWebサイトでは、mod_auth_openidcを使った認証に切り替えることで、シングルサインオンに参加できるようになります。また、Apacheでリバースプロキシを構成し、mod_auth_openidcを利用することで、リバースプロキシ型の認証を簡単に利用することができます。
LDAPサーバ
シングルサインオンのシステムでは、ユーザ情報の管理を行うための認証サーバは別に用意することが推奨されています。ここでは、シングルサインオンのシステムとの連携でよく使われるオープンソースのLDAPサーバを紹介します。
OpenLDAP
OpenLDAPは、多くのLinuxディストリビューションに採用されているLDAPサーバです。サーバだけではなく、LDAPユーティリティやLDAPライブラリなどが、多くのソフトウェアで利用されています。古くから利用されていて、LDAPサーバとしてはリファレンス的な位置づけのサーバです。インターネットサービス・プロバイダ向けなどの厳しい環境でも使われています。
389 Directory Server
389 Directory Serverは、RedHatが開発・管理を行っているLDAPサーバです。もともとは、OpenLDAPをベースに開発され、製品化され販売されていたものを、RedHatがオープンソース化しました。OpenLDAPに比べて高速に動作するという特徴があります。ReHat Enterprise Linux 8からは、OpenLDAPに変わって、389 Directory Serverが採用されています。
「389 Directory Server〜OSSのLDAPサーバ〜」へ
多要素認証
多要素認証とは、IDとパスワードによるユーザの確認だけではなく、他の要素でも認証を行う方法です。シングルサインオンのシステムでは、セキュリティを高める対策として、多要素認証の仕組みを導入することが推奨されています。ここでは、多要素認証を実現するために利用できるオープンソースソフトウェアについて解説します。
Google Authenticator
Google Authenticatorは、オープンソースのワンタイムパスワードの仕組みです。Googleが開発し、オープンソースソフトウェアとして公開されています。Google Authenticatorアプリで時間にあわせて作成される6桁のワンタイムパスワードと、認証するシステム側で同様の方法で作成したパスワードが一致することを検証します。Keycloakと連携することが可能です。
「Google Authenticator〜OSSのワンタイムパスワード〜」へ