SAML 完全解説 ― 仕組み・メリット・実装ポイントまとめ

# SAML 完全解説 ― 仕組み・メリット・実装ポイントまとめ  
公開日: 2025-04-23

> **この記事の目的**  
> - SAML (Security Assertion Markup Language) の基礎と用語を整理  
> - SSO フローを図解しながら分かりやすく解説  
> - OpenID Connect との違い・選定指針を明示  
> - 実装・運用でハマりやすいポイントとベストプラクティスを紹介  

---
## 0. 導入
- SAMLってどのような仕組みか忘れてしまう自分への備忘録。。
- Ouathとの違いは？なども含めて記載しています。

## 1. SAML とは？

- **Security Assertion Markup Language** の略  
- XML ベースで認証・認可の情報（アサーション）をやり取りする **フェデレーション (Federation) プロトコル**  
- 現行バージョンは **SAML 2.0 (OASIS, 2005)**  
- 主な用途は **エンタープライズ向け SSO**。クラウド (SaaS) ⇔ 社内 IdP 連携で依然として採用例が多い

---

## 2. 基本用語

| 用語 | 略称 | 役割 |
| ---- | ---- | ---- |
| **Identity Provider** | IdP | 認証を実施し、アサーションを発行する側 |
| **Service Provider** | SP | 利用するサービス（SaaS / アプリ）側 |
| **Principal** | ー | ユーザー本人 |
| **Assertion** | ー | 認証結果と属性情報を含む XML 署名付きトークン |
| **Metadata** | ー | IdP/SP の公開鍵・エンドポイントなどの設定ファイル |
| **Binding** | ー | アサーション配送方式（HTTP-Redirect, HTTP-POST, Artifact 等） |
| **Profile** | ー | 利用シナリオを定義（Web SSO Profile など） |

---

## 3. Web SSO フローを図で理解する

```mermaid
sequenceDiagram
  participant User
  participant SP as サービスプロバイダー (SP)
  participant IdP as アイデンティティプロバイダー (IdP)

  User->>SP: 保護リソースへアクセス
  SP-->>User: AuthnRequest (HTTP Redirect)
  User->>IdP: AuthnRequest を転送
  IdP-->>User: ログイン画面
  User->>IdP: 資格情報入力
  activate IdP
  IdP-->>User: SAML Response (Signed Assertion)  ※HTTP POST
  deactivate IdP
  User->>SP: SAML Response をブラウザ経由で送信
  SP->>SP: 署名検証 & 属性マッピング
  SP-->>User: セッション確立 & リソース表示
```

## ✅ 抑えておきたいポイント

- **AuthnRequest は SP 起点**  
  - IdP-Initiated も可能だが **監査ログ管理が難しい**  
- **SAML Response は「署名必須・暗号化任意」**  
  - IdP → SP の通信自体は **HTTPS** で保護される  
- **SP はアサーションの `NotOnOrAfter` を検証**  
  - 有効期限外は拒否し、**リプレイ攻撃** を防止する  

---

## 4. メリットと制約

| 観点 | メリット | 制約・注意点 |
| ---- | -------- | ------------ |
| **統合認証** | 1 回のログインで複数 SaaS にアクセス | クラウドごとにメタデータ設定が必要 |
| **セキュリティ** | XML 署名 + 証明書で改ざん検知 | **XML Signature Wrapping** 脆弱性に注意 |
| **属性連携** | 部署 / 役職などを属性で渡せる | 属性スキーマがサービス間でズレやすい |
| **互換性** | 多くのエンタープライズ SaaS が対応 | モバイルネイティブには不向き（重い） |

---

## 5. SAML vs OpenID Connect (OIDC)

| 規格 | データ形式 | 典型用途 | トークン | エコシステム例 |
| ---- | ---------- | -------- | -------- | -------------- |
| **SAML 2.0** | XML | エンプラ SSO / SaaS | SAML Assertion | ADFS, Okta, PingFederate |
| **OIDC** | JSON + JWT | モバイル / SPA / API 認可 | ID Token, Access Token | Auth0, Cognito, Firebase, Azure AD B2C |

> **選定ヒント**  
> - **ブラウザベース・レガシー SaaS ➡ SAML** が無難  
> - **モバイル / SPA & API Auth ➡ OIDC** が主流  
> - 両方をサポートする IdP を導入し、**サービス特性で切り替える** 構成が実践的  

---

## 6. 実装ガイド

### 6-1. IdP 構築

1. **製品選定**  
   - オンプレ: **ADFS / Keycloak / Shibboleth**  
   - SaaS : **Okta / Azure AD / Google Workspace**
2. **メタデータ公開**  
   - `https://idp.example.com/metadata` を **HTTPS** でホスト  
   - **証明書ローテーション** は *約 180 日* 周期で実施
3. **署名鍵管理**  
   - HSM や **AWS KMS** に格納  
   - キーローテーション後は **SP にメタデータを再配布**

### 6-2. SP 側設定

- IdP メタデータを取り込み（EntityID, cert, ACS URL）  
- `NameIDFormat` は `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent` を採用し、  
  **メールアドレスをユニーク ID** として扱うケースが多い  
- ログイン失敗時は **AuthnRequest ID** をエラーページに表示し、  
  IdP 側ログとの突合を容易にする

### 6-3. Attribute Mapping 例 (Okta → AWS IAM)

| Okta Attribute | SAML Attribute | IAM 設定例 |
| -------------- | ------------- | ---------- |
| `email` | `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress` | `aws:userid` |
| `department` | `https://example.com/claims/dept` | `aws:PrincipalTag/dept` |
| `role` | `https://aws.amazon.com/SAML/Attributes/Role` | `arn:aws:iam::123456789012:role/ReadOnly` |

> 💡 **TIP**  
> 2023 年以降、AWS では **SAML Attributes → Session Tags** が正式サポート。  
> ロール数削減 + **ABAC** が容易に！

---

## 7. セキュリティ ベストプラクティス

- **∀ Assertion に署名** - 可能なら **AuthnRequest** にも署名  
- **最小許可の属性発行** - 不要な個人情報は渡さない  
- **Metadata TLS Pins** - `KeyDescriptor use="encryption"` を必ず含める  
- **Replay 対策** - `NotBefore / NotOnOrAfter` を ±5 min 以内、`InResponseTo` を検証  
- **監査ログ** - IdP で SAML ステータスを **SIEM** へ送信 (Azure Monitor, Splunk 等)  
- **脆弱性対応** - XML ライブラリの **XXE / XSW** パッチを最新化  
  - 例: **CVE-2022-42889** (XML Commons Text) を適用確認

---

## 8. テスト & デバッグツール

| ツール | 種別 | ポイント |
| ------ | ---- | -------- |
| **SAML Tracer** (Firefox / Chrome) | ブラウザ拡張 | SAML Message や Assertion をリアルタイム確認 |
| **SSO Circle** | 無償公開 IdP | SP 開発時に外部 IdP を手軽に利用可能 |
| **saml2aws / aws-iam-authenticator** | CLI | SAML → AWS 一時クレデンシャル取得を検証 |
| **pySAML2** | Python ライブラリ | ローカル IdP / SP の即席テスト環境を構築 |

---

## 9. まとめ

1. **SAML は “エンタープライズ SSO の定番”** として依然重要  
2. モダンアプリには **OIDC とのハイブリッド構成** が現実解  
3. 実装時は **Metadata & 署名鍵のライフサイクル管理** が肝  
4. 運用後も **監査ログ + 脆弱性対応** を継続し、安全な認証基盤を保守する

---

### 参考リンク

- [OASIS SAML 2.0 Core Specification](https://docs.oasis-open.org/security/saml/v2.0/)  
- [SAML Wiki – SAML 2.0 Technical Overview](https://wiki.samltool.com/doku.php?id=saml_tech_overview)  
- [OWASP Cheat Sheet: SAML Security](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html)  
- [AWS Identity Federation with SAML 2.0](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html)

---

この記事があなたの **SAML 導入・運用** のヒントになれば幸いです。  
フィードバックはぜひコメントでお寄せください！