複数のSaaSアプリを利用する場合、SaaSアプリ単位にID、パスワードを管理する運用は非常に困難です。ユーザにとっては、異なるSaaSアプリを使用するたびにID、パスワードを入力、および管理する必要があり、ユーザビリティが低下します。もちろん、管理者にとっても複数アプリに跨り、ID管理することは大変な負担です。
SAML（Security Assertion Markup Language）とは一度のユーザ認証により、異なる組織へのアプリケーションにも認証無しで使用（シングルサインオンでログイン）できる仕組みで、XML仕様のマークアップ言語です。
SAMLに伴い、中央のID管理システムにより1度認証されたユーザは、複数のSaaSアプリへシームレスにアクセスすることができます。
SAMLの概要
SAMLの登場人物として、IdP、SPがあります。
IdP（IDプロバイダ）は、ユーザIDやパスワードなどの認証情報を保持しているサービスのことで、SP（サービスプロバイダ）は、いわゆるSaaSアプリのことです。
SaaSアプリ（SP）を利用する際に、IDプロバイダ（IdP）で認証をして、認証OKだったら、SPに接続させます。
通常は、IdPとSPは異なる組織（ドメイン）になります。例えば、IdPで有名なのは、AzureAD、Okta、PingFederation, JumpCloudなどがあり、SP（SaaSアプリ）は、Microsoft365、Box など、多数存在します。
IdPとSPは異なる組織のため、予め信頼関係を結ぶことで、IdPが認証OKとなれば、それをSPで信用します。この信頼関係は、PKIの仕組みを使用しています。
例えば、IdPを認証局として、証明書を発行し、SPへインポートします。IdPから送信される認証結果（アサーション）にIdPの署名をつけて、SPはIdPから発行された証明書の公開鍵で署名を検証します。
署名の仕組みは、以下の記事も参考にしてください。
>> 参考記事 : 【初心者】公開鍵暗号、認証局、デジタル署名をイメージで解説
SAML処理フロー
ユーザがあるSaaSアプリに接続してから、シングルサインオンによりアプリへの接続ができるまでのフローは以下のとおりです。
- クライアントは、ブラウザ等よりSP（SaaSアプリ）へ接続します。
- SPは、予め設定されたIdP（サインオンURL）へリダイレクトするよう、クライアントへ要求します。
- クライアントはサインオンURLへ接続します。サインオンURLの接続先はIdPです。
- IdPよりユーザIDとパスワードの入力を求められます。ここで、ユーザIDとパスワードを入力します。
- 認証がOKであれば、ユーザに紐づいた属性値などを含めたアサーションを付与し、予め設定されたSPのSSOモジュール（応答URL）へリダイレクトするようクライアントへ要求します。
- クライアントは、応答URLへ接続し、SPへアサーションを提供します。
- SPはアサーションを受信し、信頼関係のあるIdPからの署名であるのか検証します。
- 検証OKで、ユーザを受け入れる場合は、クライアントへSaaSアプリにリダイレクトするよう要求します。
- クライアントはSaaSアプリへ接続開始します。
- アクセスが成功します。
SaaSアプリが複数あっても、ユーザがIdPで認証済みであれば、アサーションを提供することで、ユーザIDの入力無しに複数SaaSアプリへのアクセスが成功します。
SAMLで使用するパラメータ
IdP、SPでは、例えば、以下のようなパラメータが発行されます。
基本的に、IdPで発行されたパラメータは、SPへインポートし、SPで発行されたパラメータは、IdPへインポートします。これによりIdPとSPとの信頼関係が結べます。
IdPで発行されるパラメータ
- サインオンURL（ログインURL/ログアウトURL）
- IdP識別子（エンティティID）
- SAML証明書（アサーションの署名用）
SPで発行されるパラメータ
- SP識別子（エンティティID)
- 応答URL
- サインオンURL/ログアウトURL
実際の設定は、IdP、SPそれぞれで公開されているドキュメントを参照しながら、実施します。
コメント