石川 竜雄
SAML 2.0とは
SAML（Security Assertion Markup Language）は、WEBアプリケーションやサービスにユーザーが本人であることを伝えるための標準規格です。認証サーバーによってユーザーの本人確認に成功すると認証トークンが発行されます。ユーザーがWEBアプリケーションやサービスを利用する際に、システムが保持している認証トークンを自動で提出してログインできるようにするシングルサインオン（SSO）を実現します。
利用シーン
SSOを実現するための規格であるSAMLは、Identity Provider（IdP：以下、IDプロバイダ）とService Provider（SP：以下、サービスプロバイダ）の2つの間で認証情報のやり取りを行う、セキュリティに配慮された安全な仕組みです。
ドメイン単位での導入になるため基本的にはエンタープライズ用途になります。
社内のID統合、SSOの導入を行う場合エンタープライズ向けのクラウドサービス（Microsoft 365、Google Workspace、Salesforce、Boxなど）を対象とするにはSAML 2.0が必須です。
多くのクラウドサービスはSAML2.0のサービスプロバイダ機能をサポートしており、SAML 2.0のIDプロバイダ機能を持つSSO製品や認証製品を導入することでID統合とSSOを実現できます。
エンタープライズで自社サービスを提供している場合、SAMLを使うことでID管理を専用のシステムに分離することができます。サービスにそれぞれSAMLのサービスプロバイダ機能を追加し、SAML 2.0のIDプロバイダ機能を持つIDaaS製品を導入します。これにより、ID管理の一元化を実現し、IDaaS製品が提供する各種ID管理の機能を使ってアカウント管理の手間を軽減できます。
また、複数のサービスを提供している場合のID統合にも有効です。
仕組み
SAML認証にはユーザーの本人性を確認し、SAMLアーサーションというXML形式のセキュリティトークンを発行するIDプロバイダと、認証トークンを受け取りログインを受け入れるサービスプロバイダが必要です。
IDプロバイダは通常のログインプロセスと同様に、ユーザーにIDとパスワード（あるいは二要素認証）の入力を要求し本人確認をおこなうサービスです。クラウドサービスなどにアクセスするユーザーの認証情報を保存・管理しています。SAMLを導入するすべてのサービスプロバイダで、１つのIDプロバイダが呼び出されるため、システム的にサービスプロバイダとは分離されている必要があります。
サービスプロバイダはユーザーがログインしたいWEBアプリケーションやサービスにあたります。例としてはGmailやMicrosoft 365などのメールプラットフォームやクラウドサービス、SlackやSkypeなどの通信アプリケーション、Boxなどのクラウドストレージがあります。通常はユーザーがこれらのサービスに直接ログインして利用しますが、SAMLを導入するとすべてのサービスのログイン画面をIDプロバイダに統合することができます。
以下は一般的なSAMLの処理フローです。
- ユーザーはサービスプロバイダに接続します
- サービスプロバイダは要求に応じてSAML認証要求を作成します
- サービスプロバイダはSAML認証要求をユーザに返します
- ユーザーはサービスプロバイダから受け取ったSAML認証要求をIDプロバイダに渡します
- IDプロバイダはSAML認証要求に応じて認証画面を表示します
- ユーザーは認証画面にID、パスワードを入力しログインします
- IDプロバイダはID、パスワードを検証します
- IDプロバイダはSAML認証トークンを発行します
- IDプロバイダはSAML認証トークンをユーザーに返します
- ユーザーはIDプロバイダから受け取ったSAML認証トークンをIDプロバイダに渡します
- IDプロバイダはSAML認証トークンを検証します
- IDプロバイダはユーザーにログインの許可を出します
セキュリティ
上述の処理フローのとおり、IDプロバイダとサービスプロバイダ間の通信はユーザー（ブラウザ）を介して行われるため、IDプロバイダとサービスプロバイダ間の直接の通信は行わず、ログインに必要な個人情報もユーザー（ブラウザ）とIDプロバイダ間の通信以外には流れないようになっています。
このため、SAMLではIDプロバイダのサーバーを安全なネットワークに配置することが、個人情報の漏えいを防止するために必要となります。例としては、社内のサーバーにIDプロバイダを構築し、クラウド提供されているサービス（サービスプロバイダ）へログインするといった運用が挙げられます。
