LDAP より SAML/OIDC が高セキュリティという幻想 – 認証方式は適材適所で選ぶ

「LDAP より SAML/OIDC の方が高セキュリティである」という言い方を見かけることがあります。しかし、この理解はかなり雑です。LDAP、SAML、OIDC は同じ土俵で単純比較できるものではありません。

SAML/OIDC は認証結果をアプリケーションへ連携するための仕組みであり、LDAP はディレクトリ情報へアクセスするための仕組みです。どちらが上位互換かではなく、どのレイヤで、何を守り、どのように運用するかで評価すべきです。

この記事では、LDAP、SAML、OIDC を「高セキュリティかどうか」という雑な軸ではなく、目的、適用範囲、実装責任、運用負荷の観点から整理します。

SAML/OIDC は認証結果の連携手段

SAML や OIDC は、IdP で行われた認証結果をアプリケーションに伝えるための仕組みです。SAML は XML ベースの Assertion を使い、OIDC は OAuth 2.0 を土台に ID Token や Claims を扱います。

ここで重要なのは、SAML/OIDC を使えばアプリケーションが自動的に安全になるわけではない、という点です。アプリケーション側でトークンや Assertion の検証、ユーザー認可、セッション管理、ログアウト、アカウント紐付けを誤れば、SAML/OIDC を使っていても危険な構成になります。

高セキュリティに見える理由

SAML/OIDC が高セキュリティに見えるのは、プロトコルそのものというより、IdP 側で多くの機能を集約しやすいからです。

• MFA を導入しやすい
• SSO によってログイン経路を集約できる
• 認証ログを一元化しやすい
• 条件付きアクセスやリスクベース認証を実装しやすい
• アプリケーション側にパスワードを持たせずに済む

これらは大きな利点です。ただし、これは IdP の機能、設定、運用、監査が適切である場合の話です。IdP が単一障害点になり、設定ミスで広範囲に影響することもあります。

LDAP は古くて脆弱な認証方式ではない

LDAP はそもそも「古い認証方式」というより、ディレクトリ情報へアクセスするためのプロトコルです。LDAP を使った認証では、アプリケーションがユーザー DN を検索し、Bind によって資格情報を確認する構成がよく使われます。

LDAP が危険になるのは、平文通信、過剰な Bind 権限、広すぎる検索範囲、ログ監査の不足、アカウントロックやパスワードポリシーの不足がある場合です。逆に、LDAPS や StartTLS、適切な ACL、監査、ロックアウト、パスワードポリシーを組み合わせれば、堅牢な認証基盤として運用できます。

アプリケーション -> LDAP サーバー
  1. ユーザーを検索する
  2. ユーザー DN を特定する
  3. Bind で資格情報を確認する
  4. グループや属性を取得して認可に使う

目的が違うものを比較してはいけない

SAML/OIDC と LDAP は、どちらも認証に関係しますが、目的が違います。SAML/OIDC は主に Web アプリケーションや SaaS、組織間連携、SSO に向いています。一方、LDAP は Linux 認証、ネットワーク機器、ミドルウェア、社内システム、ディレクトリ管理など、より低いレイヤやプライベートな管理領域で使われることが多いです。

個人的には、システム管理を行うレイヤでは LDAP 認証が適しており、一般ユーザー向けの Web アプリケーションや外部サービス連携では SAML/OIDC が適している場面が多いと考えています。

SAML/OIDC は実装と運用が重い

SAML/OIDC は便利ですが、実装と運用は決して軽くありません。特に OSS や新しい Web アプリケーションでは比較的きれいに対応していることが多い一方で、古いプロダクトでは対応が中途半端だったり、情報が不足していたりします。

• メタデータや証明書の管理が必要になる
• 属性マッピングやグループ連携が製品ごとに異なる
• ログアウトの挙動が期待通りにならないことがある
• CLI、WebDAV、メール、VPN など非ブラウザ系クライアントでは扱いにくい
• IdP 側の設定変更が複数サービスへ波及する

この点は、Nextcloud の SAML 認証と WebDAV の問題にもつながります。ブラウザでは SSO がうまく動いても、WebDAV クライアントが SAML のログインフローを扱えるとは限りません。

本質はプロトコルではなく設計と運用

認証の安全性は、プロトコル名だけでは決まりません。どの方式を使うかよりも、どこで本人確認を行い、どこで認可を行い、どこでセッションを管理し、どのように監査するかが重要です。

• 通信が暗号化されているか
• 資格情報や Token の有効期限が適切か
• MFA や条件付きアクセスを必要な範囲に適用しているか
• アプリケーション側の認可が正しく実装されているか
• ログと監査が追えるか
• 障害時や IdP 停止時の影響範囲が分かっているか

SAML/OIDC も LDAP も、設計と運用次第で安全にも危険にもなります。セキュリティの高さは、プロトコルの名前ではなく、設計、実装、運用、可視化、監査体制の全体で決まります。

まとめ

LDAP より SAML/OIDC の方が高セキュリティである、という単純な理解は危険です。SAML/OIDC は SSO や認証連携に強く、LDAP はディレクトリ管理やシステム管理レイヤの認証に強い。それぞれ目的が違います。

SAML/OIDC を入れれば安全になるのではありません。LDAP を使っているから古くて危険というわけでもありません。重要なのは、対象システム、利用者、アクセス経路、認可、セッション、監査、障害時の影響を含めて設計することです。

認証方式は流行や印象で選ぶものではありません。管理レイヤでは LDAP が自然なこともあり、Web アプリケーションや外部連携では SAML/OIDC が自然なこともあります。セキュリティは方式の名前ではなく、適材適所の設計と運用で決まります。

参考

• OASIS – SAML 2.0 Technical Overview
• OpenID Connect Core 1.0
• OWASP – Authentication Cheat Sheet
• OWASP – Session Management Cheat Sheet
• Keycloak – Server Administration Guide

Related posts:

Nextcloud SAML 認証で WebDAV が問題になる理由 CentOS 7 LDAP クライアント設定 – authconfig と nslcd の LDAPS 接続 CentOS 8 OpenLDAP LDAP クライアント – ldapsearch と証明書信頼設定 CentOS 8 SSSD Linux クライアント – LDAP 認証の基本設定 CentOS 8 389 Directory Server と Samba – LDAP スキーマ連携の基本 Ubuntu 22.04 389 Directory Server #1 – インスタンス作成と suffix 設計 Ubuntu 22.04 389 Directory Server #2 – TLS 有効化と LDAPS 設定 Ubuntu 22.04 389 Directory Server #3 – ベースエントリーの登録 Ubuntu 22.04 389 Directory Server #4 – BIND ユーザーとアクセス制御 Ubuntu 22.04 SSSD – LDAP ユーザーで Linux 認証する Ubuntu 22.04 OpenLDAP LDAP ユーティリティ – ldapsearch / ldapadd / ldapmodify の使い方 Zabbix で複数 LDAP 連携を使う時の注意点 – JIT プロビジョニングと認証設計