SAML統合ベストプラクティス【属性マッピングから運用まで】

マルチSaaS環境でシングルサインオン（SSO）を実装する際、SAML 2.0は最も標準的なプロトコルです。本記事では、SAML統合の全体像、属性マッピングのベストプラクティス、証明書管理、メタデータ自動更新、NameID戦略について詳解します。

SAML 2.0 の基本概念

SAML 2.0 とは

SAML（Security Assertion Markup Language）2.0 は、フェデレーション認証の標準プロトコルです。

基本的な流れ

1. ユーザーが Web アプリケーション（SP：Service Provider）にアクセス
2. SP はユーザーを IdP（Identity Provider）にリダイレクト
3. IdP でユーザーが認証（ユーザー名・パスワード）
4. IdP は SAML アサーション（ユーザー属性を含む XML）を生成
5. ユーザーは SP にリダイレクトされ、SP は SAML を検証
6. ユーザーがアプリケーションにログイン

SAML vs OAuth 2.0 vs OpenID Connect

項目	SAML 2.0	OAuth 2.0	OpenID Connect
用途	エンタープライズ SSO	API 認可	消費者向け SSO
ユースケース	社員の SSO	権限委譲	Google ログイン等
標準化度	高（成熟）	高（広く採用）	中（OAuth 2.0 の拡張）
複雑さ	高（XML）	中（JSON）	中（JSON）

LOCKED MSO での対応

• SAML 2.0：完全対応
• OAuth 2.0：対応
• OpenID Connect：対応

SAML 統合の 5 つのステップ

ステップ 1：IdP と SP の識別子設定

Entity ID（エンティティ ID）

IdP と SP は、それぞれ一意の Entity ID を持つ必要があります。

例：

IdP の Entity ID：https://idp.company.com/saml
SP の Entity ID：https://salesforce.com/

ステップ 2：SAML メタデータの交換

IdP と SP は、メタデータファイル（XML）を交換します。

メタデータに含まれる情報

• Entity ID
• 署名証明書
• ログイン URL（IdP）
• Assertion Consumer Service URL（SP）

メタデータ交換方法

1. 手動交換：メタデータファイルをダウンロード・アップロード
2. URL ベース：メタデータ URL を相互に登録（自動更新）

ベストプラクティス： URL ベースの登録により、証明書更新時に自動的に反映されます。

ステップ 3：属性マッピングの設定

IdP（LOCKED MSO）のユーザー属性を、SP（Salesforce 等）が理解できる属性に変換します。

標準的なマッピング例：

LOCKED MSO 属性	Salesforce 属性	用途
user.email	urn:oid:0.9.2342.19200300.100.1.3	ユーザー識別
user.firstname	urn:oid:2.5.4.42	名前
user.lastname	urn:oid:2.5.4.4	姓
user.department	カスタム属性	部門情報
user.groups	memberOf	グループ（権限）

ステップ 4：署名と暗号化の設定

SAML アサーションは、改ざん防止のため署名される必要があります。

署名アルゴリズム

• RSA-SHA256（推奨）
• RSA-SHA512

暗号化

• 機密性の高い属性（給与情報等）は暗号化

チェックリスト

• 署名アルゴリズムが RSA-SHA256 以上
• 证明書有効期限を確認
• 秘密鍵を安全に管理

ステップ 5：テストと検証

本番展開前にテスト環境で十分な検証が必須です。

テスト項目

• ログインが成功する
• 属性が正しくマップされている
• グループメンバーシップが反映される
• ログアウトが正常に動作
• エラーメッセージが適切

NameID 戦略

NameID とは

NameID は、SAML アサーション内でユーザーを一意に識別するフィールドです。

NameID の形式

形式	例	用途
unspecified	user123	汎用
emailAddress	user@company.com	メールベース
persistent	https://idp.com/user/123	変更不可
transient	一時的な値	セッションスコープ

NameID 戦略のベストプラクティス

推奨：emailAddress または persistent

EmailAddress の場合：
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
  user@company.com
</saml:NameID>

メリット

• 人間にとって理解しやすい
• メールアドレス変更時の対応を計画しやすい

デメリット

• メールアドレス変更があると同期が複雑化

推奨：Persistent NameID

<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
  https://idp.company.com/user/a1b2c3d4
</saml:NameID>

メリット

• ユーザー属性変更の影響を受けない
• セキュリティが高い

デメリット

• ID が不透明で追跡が困難

企業規模別の推奨 NameID 戦略

企業規模	推奨形式	理由
小規模（100 名以下）	emailAddress	シンプルさ重視
中規模（100～1,000 名）	persistent	柔軟性を確保
大規模（1,000 名以上）	persistent	変更に強い

証明書管理のベストプラクティス

証明書の有効期限管理

推奨：

• 証明書有効期限：3 年
• 更新タイミング：有効期限の 3 ヶ月前
• モニタリング：自動アラート設定

有効期限切れのリスク

• SAML アサーションが検証不可
• ユーザーがログインできなくなる

証明書更新の手順

1. 新しい証明書を IdP で生成
2. メタデータを更新
3. SP 側でメタデータを更新（自動 or 手動）
4. テスト環境で検証
5. 本番環境で有効化
6. 旧証明書を無効化（数日後）

LOCKED MSO での実装

LOCKED MSO は、メタデータ自動更新機能により、証明書更新時に自動的に SP 側に反映されます。

属性マッピングのベストプラクティス

マッピング設計の原則

1. 統一性の確保

複数アプリケーションで同じ属性を使用：

全アプリケーション共通：
- email：ユーザー識別
- givenName：名
- sn：姓

2. カスタム属性の最小化

标準属性で対応可能な場合は、カスタム属性を避ける。

3. 空値の処理

属性が存在しない場合のデフォルト値を定義：

IF user.department == null THEN "Unassigned" ELSE user.department

マルチ SaaS 環境での属性マッピング例

シナリオ：100 名企業が Salesforce + Slack + Jira を導入

ユーザー属性	Salesforce	Slack	Jira
email	[email]	[email]	[email]
givenName	[First Name]	[First Name]	[First Name]
sn	[Last Name]	[Last Name]	[Last Name]
department	[Department]	[Custom: dept_ja]	-
manager	[Manager ID]	-	[Custom: manager]
groups	[Role]	[Channel Mapping]	[Project Role]

実装コスト

• HENNGE One：100～150 万円（UI ベース）
• Okta：150～250 万円（OEL による複雑さ）
• LOCKED MSO：80～120 万円（シンプルな設定）

メタデータ自動更新の実装

URL ベースのメタデータ交換

IdP がメタデータ公開 URL を提供することで、SP は自動的に最新メタデータを取得できます。

メタデータ公開 URL 例：

https://idp.company.com/saml/metadata.xml

メリット

• 証明書更新が自動化される
• 手作業のミスを削減

デメリット

• URL がインターネット上に公開される
• セキュリティ対策が必須（IP 制限等）

LOCKED MSO でのメタデータ自動更新設定

1. LOCKED MSO 管理画面で SAML アプリケーション設定
2. メタデータ URL を取得：https://app.locked.jp/saml/metadata/{AppID}
3. Salesforce（等）の SAML 設定でメタデータ URL を入力
4. 自動更新を有効化

トラブルシューティング

よくあるエラーと対応

エラー	原因	対応
署名検証失敗	証明書不一致	メタデータの再取得
NameID マッピングエラー	NameID 形式が異なる	NameID 形式を確認
属性が反映されない	マッピング設定漏れ	マッピングを再確認
タイムアウト	IdP サーバー障害	IdP のステータス確認

デバッグのコツ

SAML リクエスト・レスポンスを確認するツール：

• SAML Tracer（ブラウザ拡張）
• Okta SAML Assertion Viewer
• onelogin SAML Test

LOCKED MSO での SAML 統合の優位性

項目	Okta	HENNGE One	LOCKED MSO
メタデータ自動更新	◎	◎	◎
属性マッピング UI	△（複雑）	◎	◎
NameID 柔軟性	◎	◎	◎
サポート	△（英語）	◎	◎
実装期間	長（3～6 ヶ月）	短（1～2 ヶ月）	短（1～2 ヶ月）

---

外部参考リンク

• OASIS SAML 2.0 仕様
• SAML コンソーシアム
• Microsoft SAML 実装ガイド

関連記事

• MFA運用完全ガイド【TOTP/FIDO2/SMS比較と段階導入】
• Azure AD SSO設定実装ガイド【Office 365/Teams連携・条件付きアクセス】
• Okta評判・ユーザーレビュー【導入難易度と実装事例】
• OneLogin評判・機能【SAML/OIDC対応の実装事例】

LOCKEDの詳細を見る

シングルサインオン・認証管理でお悩みなら、LOCKEDの無料デモをお試しください。

資料請求・デモ依頼はこちら →