SAML(Security Assertion Markup Language)は、異なるドメイン間で認証情報を安全にやり取りするためのシングルサインオン(SSO)および認証連携(Federation)のための標準プロトコルです。XMLベースで記述され、Webアプリケーションやクラウドサービスにおける認証と認可を実現するために広く利用されています。
例えば、企業の社員がGoogle WorkspaceやSalesforceなどのクラウドサービスを利用する際、毎回ログインするのではなく、一度の認証で複数のサービスを利用できる仕組みを提供します。
SAMLの基本概念
SAMLは、主に以下の3つの役割で構成されます。
- IDプロバイダー(IdP: Identity Provider)
- ユーザーの認証を行い、その結果をアサーションとして発行するサーバー(例:Active Directory、Okta、Google Workspace など)。
- サービスプロバイダー(SP: Service Provider)
- ユーザーが利用したいWebアプリケーションやサービス(例:Salesforce、AWS、Google Drive など)。
IdPからの認証情報を受け取り、ユーザーを認可する。
- ユーザーが利用したいWebアプリケーションやサービス(例:Salesforce、AWS、Google Drive など)。
- ユーザー(Client)
- IdPで認証し、SPを利用する。
SAMLの基本的な流れ(SSOの例)
- SP-Initiated(サービス側からのログイン)
- ユーザーがSP(例:Salesforce)にアクセスする。
- SPは、SAMLのリクエスト(AuthnRequest)を作成し、IdPにリダイレクトする。
- IdPでユーザーが認証(ID・パスワード入力など)する。
- IdPは、認証結果を含むSAMLアサーション(SAML Response)をSPへ送信。
- SPはSAML Responseを検証し、ユーザーをログインさせる。
- IdP-Initiated(IdP側からのログイン)
- ユーザーがIdP(例:Okta)にログインする。
- IdPがSAMLアサーションを作成し、SPにリダイレクトする。
- SPはSAMLアサーションを検証し、ユーザーをログインさせる。
SAMLの主要コンポーネント
- SAML Request(認証リクエスト)
- SPからIdPに送られる認証要求。
- XML形式で記述され、Base64エンコードされる。
- SAML Response(認証応答)
- IdPがSPに返す認証結果を含んだレスポンス。
- 署名付きのXMLデータで、ユーザーのID情報などが含まれる。
- SAML Assertion(アサーション)
- 認証情報を含むXML文書で、認証(Authentication)、属性(Attribute)、認可(Authorization)の情報が入っている。
- 3つの要素で構成される:
- Authentication Statement(認証情報): 誰が、いつ認証したか。
- Attribute Statement(属性情報): ユーザーの名前やメールアドレス。
- Authorization Decision Statement(認可情報): SPがアクセスを許可すべきか。
- SAML Binding
- SAMLメッセージのやり取り方法(HTTP-Redirect、HTTP-POST、SOAP など)。
SAMLの利点
✅ シングルサインオン(SSO)を実現 → ユーザーが一度ログインすれば、複数のサービスを利用可能。
✅ セキュリティの向上 → パスワードを各サービスに保存せずに認証可能。
✅ 一元管理が可能 → 企業のIT管理者がIdPを通じてユーザー管理を統一できる。
SAMLの課題
❌ 実装が複雑 → XMLベースで設定が多く、証明書の管理が必要。
❌ リアルタイムの認証解除が難しい → SAML自体には「ログアウト機能」がなく、セッションの有効期限管理が必要。
❌ モバイルアプリとの親和性が低い → 近年はJSONベースのOAuth2/OpenID Connectが好まれる。
SAML vs OAuth2/OpenID Connect
特徴 | SAML | OAuth2/OpenID Connect |
---|---|---|
特徴 | SAML | OAuth2/OpenID Connect |
認証方式 | XML(Base64エンコード) | JSON(JWT) |
目的 | SSO・Federation | API認可・IDトークンの発行 |
モバイル対応 | 弱い | 強い |
利用シナリオ | 企業のSSO・クラウド連携 | Web/Mobileアプリの認可 |
実装の複雑さ | 高い | 比較的簡単 |
最近では、モバイルやAPI連携が多い場合はOAuth2/OpenID Connect、企業内のSSOではSAMLが選ばれる傾向があります。
まとめ
- SAMLは異なるドメイン間で安全に認証情報をやり取りするSSOの標準プロトコル。
- IdP(Identity Provider)とSP(Service Provider)の間で認証情報をやり取りする。
- SAML Assertionを利用し、認証・属性・認可の情報を安全に提供。
- 企業のSSOに適しているが、OAuth2/OpenID Connectの方が新しいシステム向け。
SAMLは現在も多くの企業システムで利用されている技術ですが、モバイルやAPI連携の進化により、OAuth2やOpenID Connectに移行するケースも増えています。