SAML入門：シングルサインオンを支える仕組みとその歴史

🌟 はじめに

SAML（Security Assertion Markup Language）は、異なるシステム間で認証情報を安全にやり取りするための標準規格です。特にシングルサインオン（SSO）を実現する基盤として広く利用されており、クラウドサービスや企業内システムの統合認証で活躍しています。
この記事では、SAMLの誕生背景から仕組み、利用のメリット・デメリット、そして実際のユースケースまでを体系的に整理します。

📜 歴史的背景 ― なぜSAMLが生まれたのか

90年代〜2000年代初頭

インターネット黎明期、各Webサービスはそれぞれ独自のアカウントとパスワードを要求。ユーザは「パスワード地獄」に苦しみ、管理コストも増大。
一方、企業では社内LANに多様なアプリケーションが導入されるようになり、統合的な認証基盤が求められるようになった。

OASISによる標準化

2001年にOASIS（構造化情報の標準化団体）がSAML 1.0を策定。
XMLを用いて認証・属性情報を表現し、異なるドメイン間で共通の方法でやり取り可能にした。
2005年にはSAML 2.0が登場し、機能が大幅に拡張。以降のSSO標準の中心的存在となる。

🔑 SAMLの基本概念

主な登場人物

ユーザ（Principal）：ログインを試みる人。
IdP（Identity Provider）：認証を担当するサービス（例：社内のActive Directory）。
SP（Service Provider）：ユーザが利用したいWebサービス（例：Salesforce, Google Workspace）。

SAMLアサーション

IdPが発行するXML文書で、ユーザが「誰か」を証明する。
3種類のアサーションがある：
1. 認証アサーション：ユーザが認証された事実
2. 属性アサーション：ユーザの属性（部署・役職など）
3. 認可アサーション：サービス利用の可否

🔄 動作フロー（WebブラウザSSOの例）

ユーザがSPにアクセス
SPは「この人は誰？」とIdPにリクエスト
IdPが認証（パスワードや多要素認証など）
IdPがSAMLアサーションを作成し、ブラウザ経由でSPへ返却
SPがアサーションを検証し、認証成功 → ユーザ利用開始

SAMLではブラウザリダイレクトやPOSTを通じてXMLがやり取りされる。ユーザ本人が直接見ることはないが、内部では署名・暗号化が行われておりセキュリティが担保される。

🎯 SAMLを使うメリット

SSO実現：複数サービスへのログインを1回で済ませられる。
セキュリティ向上：認証情報をサービスごとに保存せず、IdPに集中管理。
管理効率化：アカウント管理をIdPに一本化できる。

⚠️ 課題・デメリット

XMLの複雑さ：SAMLはXMLベースで、実装が難解。開発・解析コストが高い。
モバイル・API連携には不向き：SAMLはブラウザ中心の設計で、スマホアプリやREST API連携には不便。
後継技術の台頭：OpenID Connect（OIDC）がJSON/RESTベースで軽量なため、モバイルやクラウドネイティブ環境ではOIDCの利用が増えている。

SAMLアサーションが盗まれると、正規の認証を通過した「証明書付きチケット」を悪用される危険がある。そのため、通信の暗号化やトークンの有効期限設定は必須。

🏢 代表的なユースケース

企業SSO基盤：Active Directory + SAMLでクラウドサービス（Salesforce, AWSなど）にシングルサインオン。
教育機関の学術連携：大学間の認証連携（Shibbolethなど）に利用。
行政サービス：国際的な電子政府サービス連携にも応用。

🔮 今後の展望

SAMLは今なお多くの企業で利用されているが、モバイルやクラウドの世界ではOIDCへの移行が進んでいる。
ただし、歴史の長さとエンタープライズシステムの基盤としての信頼性から、SAMLは今後も当面の間は重要な存在であり続けると考えられる。

✅ まとめ

SAMLは「異なるドメイン間で安全に認証情報を共有する」ために生まれた規格。
主にSSO実現のために使われ、IdPとSPの間でアサーションをやり取りする。
OIDCが注目を浴びているものの、SAMLは依然として企業認証の要。