この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

はじめに

CloudSteadyの技術ブログでは過去に様々なWebアプリケーションとの認証連携について紹介しています。

Azure ADとG Suiteの認証連携

Azure ADとSlackの認証連携

Nextcloud on Azure with Azure AD認証～設定編～

これらの記事ではいずれもAzureADにて「アプリケーションの統合」を用いて、SAMLによるシングルサインオンを実現する具体例を掲載しています。

アプリケーションの統合を用いると簡単にSSOを構成する事ができますが、そのためにはいくつかの用語について理解しておく必要があります。

本記事では、そもそもシングルサインオンとは何か？また、SAMLとは何か？という部分について説明したいと思います。

シングルサインオンとは

シングルサインオン（SSO：Single-Sign-On）とは、一度のユーザー認証によって、複数のアプリケーションを個別の認証無しで利用できる機能の事です。

簡単に言うと、一度ユーザIDとパスワードを入力して認証が成功すると、そのセッションが生きている限り、その後使用するアプリケーションでは再度パスワードを入力することなく使うことができるようになります。

ちなみにシングルサインアウトという機能もあります。

これは１回のサインアウトで、ログイン済みのすべてのアプリケーションのセッションを切断する機能で、SSOの設定と併せて各アプリケーションのログアウトURLを設定することで使われる場合があります。

シングルサインオンを使う理由

シングルサインオンを使うと何が嬉しいのでしょうか？

利用ユーザとしては、一度認証を行なうだけで複数のWebアプリを認証無しで利用できるため、複数のパスワードを管理する手間が減ります。当然認証にかかる時間も節約できます。

組織側としては、ユーザからの問い合わせ（パスワード忘れなど）を減らすことに役立ちます。

また、認証方法を統一することでガバナンスを効かせることが可能となります。

例えばAzure ADのアプリケーション統合によるSSOを構成した場合、認証に強力なアクセス制御（MFAや条件付きアクセス※）を組み合わせることができるため、より安全でセキュアにアプリケーションを提供することができます。

※ Azure AD P1以上のライセンスが必要

Azure ADのアプリケーション統合について

SSOの実現には様々な方法がありますが、Azure ADにはアプリケーション統合という比較的簡単に設定できる仕組みが用意されています。

「Azure Active Directory」→「エンタープライズアプリケーション」→「新しいアプリケーション」で見ることのできるAzure ADギャラリーでは、事前構築済み、ID統合確認済みのアプリのカタログが用意されています。

また、Azure ADのアプリケーションプロキシ※を用いることでオンプレミスのWebアプリケーションも統合することが可能です。

ここで多くのアプリケーションは簡単に統合することができますが、ギャラリーに無いWebアプリケーションも「独自のアプリケーションを作成」選んで手動で設定することができます。

※ Azure AD P1以上のライセンスが必要

SSOの認証プロトコル

Google WorkspaceやSalesforceのような企業向けSaaSアプリではSAMLによるSSOが用いられます。

これ以外にOpen ID Connectを利用するSSO、パスワードベースのSSOもありますが、今回は説明を割愛します。

SSOに関する用語

以下のページにて、様々なSaaSアプリケーションとAzure ADを統合する際の一連のチュートリアルが公開されています。

https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/tutorial-list

Slackのチュートリアルを見てみましょう。

このチュートリアルをみると、下記のように見慣れない用語が多く出てくると思います。

SSOに関する幾つかの用語を確認していきます。

SAML

SAMLとはSecurity Assertion Markup Languageの略でOASISという標準化団体によって策定された規格です。

SAMLではIDを提供するサイトをアイデンティティプロバイダ（IdP）、IdPの認証情報を用いてサービスやアプリケーションを提供するサイトをサービスプロバイダ（SP）と言います。

Azure ADのアプリケーション統合でいうと、IdPであるAzure ADの認証情報を用いて、SPである各Webアプリケーションにログインする仕組みとなります。

SAML Binding

IdPとSPがメッセージをやり取りする仕組みについても複数の方法があり、これをSAML Bindingといいます。

Azure ADではHTTP リダイレクトバインディングとHTTP POST バインディングが用いられます。

HTTPリダイレクトバインディングとHTTP POSTバインディングではSAMLメッセージのリクエストとレスポンスはユーザーのブラウザを介して行われます。つまり、IdPとSP間での直接の通信というのは発生しません。

出典：シングルサインオンの SAML プロトコル

SP-Initiated SSO、IdP-Initiated SSO

先ほどのチュートリアルでは、「SPによって開始されるSSOがサポートされます」という表記がありました。

これは、一般的にSP-Initiated SSOと呼ばれ、SSOの処理が始まる起点がSP側にあるという事を意味します。

反対に、SSOの処理がIdP側から始まるものを、IdP-Initiated SSOと呼びます。

出典：Security Assertion Markup Language (SAML) V2.0 Technical Overview

ユーザープロビジョニング

アプリケーション統合にて簡単にSSOを構成できたとしても、実際に利用するにはSP側にIdPと同じユーザが存在する必要があります。つまり、SPであるWebアプリケーション側で、あらかじめIdP側と同じユーザIDを作成しておかないといけません。

IdP側と同じユーザIDをSP側に作成することをプロビジョニングと言います。

自動化されたユーザープロビジョニングとは、IdP側からSPに対し、自動的にユーザIDとロールを作成する機能の事をいいます。これにより、IdP側で組織にたいして新しいユーザが作成された場合に、SP側へ自動的に対応するユーザを作成できます。

Just-In-Timeユーザープロビジョニングとはプロビジョニングをあらかじめ行うのではなく、ユーザーが最初にSSOを実行したタイミングでユーザーIDを作成する機能の事です。

メタデータ

SAMLによるSSOを構成する際には、一般的にはメタデータと呼ばれるxmlファイルをSPとIdP間で交換します。

メタ―データにはSAMLの署名証明書が含まれます。

これにより、IdPとSPの信頼関係を結び、IdPの認証情報をSPが利用可能になるわけです。

まとめ

今回は、アプリケーションの統合によるSSOについて、特にSAMLに関する用語について解説しました。

アプリケーションの統合の具体的な手順については、冒頭に記載した記事を見ていただけると流れが確認できてわかりやすいと思います。

Azure ADにおけるアプリケーション統合とは①