「manaba」におけるSingle Sign-On (SSO)サービスについて【前編】

朝日ネットシステム基盤部のGernot Hassenpflugです。主に仮想インフラ、サーバ運用と認証システム連携を担当しています。

今回は朝日ネットの開発する教育支援システム「manaba」で活用しているSingle Sign-On（シングルサインオン、以降SSO）認証の基本と運用についてご紹介します。

SSOの由来
SSOを利用する「manaba」サービス
SSOの説明とメリット
SSO関連について
- IdPの種類
SSOの実装について
参考
採用情報

SSOの由来

SSO (Single Sign-On) とは、複数のウェブベースのアプリケーションで、ユーザがそのうちの一つに一度ログインしたら規定の時間内なら他のアプリケーションも自動でログインしアクセスできるというコンセプトで、大学等教育機関でも多く使われている仕組みです。

必要なログイン操作や別々のログイン情報を増やさないというメリットとともに、セキュリティーポリシーを一元化し、アプリケーションとユーザ管理を単純にすることで、ますますウェブ中心になっていくユーザのオンライン学習を容易にできるようにすることを目的としています。

以下のようなサービスでSSOを利用したことがある方も多いかもしれません。

Googleメール
Microsoft Office 365
Ubuntu GNU/Linuxのオンラインフォーラム

最も一般的な形では、SSOはフェデレーション化された(federated)システムで、ユーザは他の教育機関にあるアプリケーションを自分の使える認証サーバを選びながら利用できます。ここで認証サーバのことをIdP (Identity Provider)、 SSO対応しているアプリケーションのことをSP (Service Provider) と呼びます。

f:id:watanabe06:20210129185122p:plain — フェデレーション化されたSSOの利用

利用者はシームレスにSSOを利用できることが理想です。しかし、コンセプトは表面的には単純ですが、技術的には実装が困難で、制限も多く運用するには多くの知識が必要です。

この記事ではまず朝日ネットが提供する教育支援システムの商品「manaba」にどうSSOを組み込んでいるか、そして技術的な、また運用上の問題点を解説します。最後に朝日ネットでは将来的にSSOをどのように活用していくことが考えられるかをご紹介します。

SSOのコンセプト、歴史、技術などの参考文献は記事末尾をご覧ください。

SSOを利用する「manaba」サービス

「manaba」はもともといくつかの大学でLDAPサーバという認証サーバと連携をしていました。その後8年ほど前からSSOの利用がはじまり、年々増えており今はLDAPでの認証連携とほぼ同じ数の大学がSSOを利用しています。

現在「manaba」をご導入いただいている大学のうち2割弱がSAML2（後述）のSSOを利用しています。割合が少なく見えますがユーザ数で見ると合計約50%が利用していますので、「manaba」のインフラにおいてSSOが非常に重要な部分になっています。特に組織が大きい大学ほどSSOを導入する傾向にあり、まさにSSOの管理上やセキュリティー上のメリットが有効です。

SSOの説明とメリット

朝日ネットの教育支援システム「manaba」のユーザ（主に大学の学生）にとっては、manabaに別の認証情報を登録しなくても容易にアクセスできることがSSOの一番のメリットです。

ですので、SSOでは昔ながらのログイン方法とは異なり、アプリケーション（manabaなど）固有のログイン画面は表示されません。代わりに、ユーザにはそのアプリケーションに関連するSSOのログイン画面（ユーザの大学、もしくはユーザが一覧から選んだ他サービスの認証サーバのもの）が表示されます。もし直近ログインしていてSSOのセッション（後述）がまだ有効であれば、直接アプリケーションへアクセスできます。

このようにユーザは、複数のSSO対応アプリケーションを SSOの認証プロバイダーが定める再認証が必要となる時間まではシームレスに利用できます。

f:id:watanabe06:20210127183452p:plain — 複数のSSO対応アプリケーションの利用

SSOの導入と運用には技術的なスキルが必要で、LDAPや単独のログインシステムより（システムの維持、ユーザに使い方を案内するといった）管理コストもかかります。

大学のSSO認証基盤との相互運用によってユーザに前述のメリットを提供したいという思いをきっかけに、朝日ネットは「manaba」にSSO機能を追加しました。

セキュリティーと管理の面から見ると、さらにメリットが沢山あります。SSO の認証サーバ（IdP）は実際のユーザ認証情報を裏にあるストレージから取得します。このストレージ（データを持っているサーバ）はLDAPサーバかもしれません。このLDAPサーバは他のサービスから直接アクセスできないところに置かれ、IdPのみがアクセスできます。このIdPは認証とアクセス許可の要求を受け付けて処理を行います。

SSO対応しているアプリケーション（SP）もユーザ認証情報 (パスワード、またはパスワードのハッシュ)を保存することなく、単にIdPの結果を信用してその指示にしたがってアクセスを提供します。このようにして、IdPもSPも認証情報を何も持たずに済みます。

これにより技術的に難しいのは、IdPとSPの信頼関係を慎重に実装することが必須で、さらに運用も慎重に行わないといけないことです。

アクセス許可の内容、再認証までの時間といったセキュリティーポリシーはIdPが定めて、SP側ではそれに合わせた設定（例えばセッションタイムアウトの時間等）を行います。

SSOは基本的に他を「上書き」するセキュリティーポリシーなので、適切に実装されていればアプリケーションにSSO経由でのみアクセスし、他の方法でアクセスせずに済むようになります。これによりアプリケーション自体のセキュリティーは相対的に強化され、一方でSSOもシステムの中心的かつ重大な部分になってきます。SSOをトラブルなしに運用し続けるにはIdPとSPの管理者がお互いに適切にコミュニケーションを取りながらサービスを維持する必要があります。

SSO関連について

サービス間で相互運用できるようにしたいという大学からの要望にお応えするために、「manaba」サービスも大学のSSO認証基盤と連携する必要があります。一部の環境では独自の認証・アクセス許可システムを使うことがありますが、ほとんどの環境ではウェブ技術を使った標準化されたSSOプロトコルを使います。これはもともと米国政府の支援で開発され、現在OASISという組織で保守されているSAML 2.0（以降SAML2と呼びます）標準というもので、認証とアクセス許可の主体（いわゆるユーザ）をセキュリティードメイン間で連携するSAML (Security Assertion Markup Language) 標準の最新バージョンです（2020年12月現在）。

このプロトコルはSAML2を直接使うアプリケーションだけでなく、Microsoft ADFSおよびAzureAD、OpenAMなど広く使われている商用SSO認証システムもオプションでサポートしています。複雑な話になりますが、システムによってIdP（認証基盤）としてもSP（サービスプロバイダー）としても運用できます。ここでは主に認証基盤としての役割でSAMLプロトコルを利用して「manaba」のSPと連携できるかに注目していきます。

SAML2をサポートしているSSO認証基盤として利用できるアプリケーションの例：

Microsoft ADFS1.x
Microsoft ADFS2.0
Microsoft ADFS2.1
Microsoft ADFS3.0
Microsoft ADFS4.0
Microsoft AzureAD
CAS
Citrix Open Cloud
GlobalSign SSO
Gluu Server
OpenAM
Oracle Identity Federation
Shibboleth
IBM Tivoli
Red Hat JBoss EAP

朝日ネットでは「Shibboleth」というオープンソースのSAML2プロトコルのリファレンス実装アプリケーション（このプロトコルを使う際の参考にしてもらうために作られたアプリケーション）を利用することにしました。これはSAML2プロトコル自体と一緒に開発、保守されており、（リファレンス実装なので当然ながら）SSOを構成するのに必要なIdPとSPの両方を実装しています。「manaba」にはこのうちのSPを組み込み、社内にはこのIdPサーバも立てて、社内で連携して検証した後にお客様（大学）組織のIdPと連携を行います。

標準化されたプロトコルをサポートすることによる良い点は、お客様組織のIdPの細かい構成を知ることなく連携できることです。 IdPがSAML2をサポートしていさえすれば、SPとIdPの間で必要な情報やその他標準のパラメータを標準に沿って取り決めることができます。

IdPの種類

manabaと連携しているIdPを集計してみるとShibbolethが一番多く、次いでMicrosoft AzureAD（でSAML2サポートを有効化していただいたもの）でした。

Shibboleth: 55%
Microsoft AzureAD/ADFS: 27%
OpenAM: 5%
その他: 14%

f:id:watanabe06:20201211184731p:plain

Shibboleth IdPはこれからも最も多くのお客様で利用され続けることを期待していますが、 Microsoft製品が日本の教育機関では広く採用されていることから、AzureADがSAML2をサポートする商用認証基盤の中で最も使われるIdPとなっていくでしょう。

SSOの実装について

Shibbolethを使用するSPの実装は、mod_shibというApacheウェブサーバの認証・アクセス許可モジュールとshibdというデーモン（サーバ）で構成されます。この構成は「manaba」の基盤に使っているLinuxシステムにある他の認証・アクセス許可方法とよく似ています。例えばLDAPによる認証・アクセス許可ではmod_authn_ldap、mod_authnz_ldapといったウェブサーバのモジュールが（OpenLDAPというライブラリーを使って）LDAPサーバと連携します。

ApacheのモジュールはURL（モジュール内ではLocationと呼んでいます）に基づいてアクセス制限を行います。ユーザ（ウェブクライアント、ブラウザ）が保護されたURLにアクセスしようとすると、直ちにshibdのデーモンに渡されて、既存のSSOセッション（SPセッション、後述）の存在をチェックします。有効なセッションがあるときはアプリケーションへのアクセスを許可しますが、ないときは強制的にIdPのログイン画面へリダイレクトさせます。つまり、ユーザがアプリケーション自体のログイン画面を見ることはありません。

なお、一般的にはユーザに利用可能なIdPの一覧を表示して、ユーザが選んだIdPのログインページへリダイレクトします。

IdPへのリダイレクトはブラウザー側のリダイレクト機能を使って、暗号化したSAML2メッセージをHTTPのヘッダー内に埋め込んで行います。ここでSSOの技術的制限が一つあります。暗号化したメッセージは長いので、ユーザのウェブブラウザーが長いHTTPヘッダーを扱える必要があります。 SAML2のメッセージにはアクセスしたいURLも含めているので、IdPで認証とアクセス許可を行った後、そのURLでもともとアクセスしたかったアプリケーションにリダイレクトできます。

f:id:watanabe06:20210127181416p:plain — SSOのSAML2フロー（出典：https://en.wikipedia.org/wiki/SAML_2.0）

IdPにリダイレクトされたユーザは、IdPのログイン画面で認証を行います。認証を通ったユーザには「IdPセッション」を作成します（通らない場合はIdPの画面から進めません)。このセッションが有効な間は、このIdP経由で別のSSO対応サービス（SP）へアクセスしようとしたらユーザは何も入力せずに認証が通ります。つまり、同じIdPを使う複数のアプリケーションへシームレスにアクセスできるということです。

その後、IdPはまたHTTPヘッダーを使ってユーザをもともといたSPへリダイレクトします。SPはIdPのメッセージを解釈して今度はユーザにアプリケーションへのアクセスを許可します。

SPは許可するだけでなく、ユーザの「SPセッション」を作成します。このセッションが有効な間はIdPへリダイレクトを行いません。これによって、セキュリティーポリシーに照らし合わせて妥当な一定期間はユーザが再認証せずにアプリケーションを自由に使えるようになります。 SPセッションの有効期間等はIdPとSPの管理者間で適切に決めます。

ユーザのウェブクライアントはSPおよびIdP関連の情報をCookie（クッキー）に保存して、 IdPセッションやSPセッションへの他のリクエストを逆にユーザ情報に結び付けます。

ユーザが自分のSSOセッションを終了させたいときは、セッションの有効期限が切れるのを待ちます。またはウェブクライアントを閉じて終了させればSPとIdPのCookieが削除されるので終了します（ブラウザのSession cookieの扱いに依存しますが）。 SSO環境で起こるログアウトに関する問題は後半で解説します。

後半の記事では上記ログアウト問題の他、朝日ネットで行っている運用とサポート業務についてお話しします。