手当たり次第に書くんだ

飽きっぽいのは本能

LDAP と SAML / OIDC の違い – 認証方式を高セキュリティという印象で選ばない

作者: si62512548投稿日: カテゴリー: 認証タグ: , , , , , , , , , LDAP と SAML / OIDC の違い – 認証方式を高セキュリティという印象で選ばない へのコメントはまだありません

「LDAP より SAML / OIDC の方が高セキュリティである」という言い方を見かけることがあります。しかし、この理解はかなり雑です。LDAP、SAML、OIDC は、同じ目的の認証方式を横並びにしたものではありません。

LDAP は、ディレクトリ情報へアクセスするためのプロトコルです。ユーザーやグループ、属性を検索し、Bind によって資格情報を確認する用途で使われます。一方、SAML と OIDC は、IdP で行われた認証結果をアプリケーションへ連携するための仕組みです。

つまり、LDAP と SAML / OIDC の違いは、単純な新旧や強弱ではありません。どのレイヤで本人確認を行い、どこへ認証結果を渡し、どこで認可し、どのように監査するかという設計の違いです。この記事では、LDAP、SAML、OIDC を目的、適用範囲、実装責任、運用負荷の観点から確認します。

参考
書籍
参考書籍

認証と認可 Keycloak 入門 第2版

Keycloak、SSO、OAuth、OpenID Connect、認証・認可の設計を確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。

Amazon で見る

このリンクは Amazon アソシエイトリンクです。

まず役割を分ける

LDAP、SAML、OIDC は、どれも認証や ID 管理の文脈で出てきます。しかし、同じ部品ではありません。LDAP はディレクトリに問い合わせるためのプロトコルであり、SAML / OIDC は認証結果をサービスへ渡すための連携プロトコルです。

方式主な役割典型的な利用先注意点
LDAPディレクトリ検索、ユーザー属性取得、Bind による認証確認Linux、ネットワーク機器、社内システム、ミドルウェアTLS、Bind 権限、検索範囲、ACL、監査が重要
SAMLIdP と SP の間で認証結果を Assertion として連携するSaaS、企業向け Web アプリ、組織間 SSO署名検証、Audience、期限、属性マッピングが重要
OIDCOAuth 2.0 を土台に ID Token と Claims を扱うWeb アプリ、モバイルアプリ、API 連携Issuer、Audience、Nonce、Redirect URI、Token 検証が重要

この表だけでも分かるように、LDAP と SAML / OIDC は置き換え関係というより、使う場所が違います。実際の環境では、IdP の裏側で LDAP を参照し、アプリケーションには SAML / OIDC で認証結果を渡す構成も普通にあります。

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

SAML は、IdP で認証されたユーザーの情報を XML ベースの Assertion として SP に渡します。OIDC は OAuth 2.0 を土台に、ID Token や Claims を使って認証結果とユーザー情報を渡します。

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

  • SAML Assertion の署名を正しく検証しているか
  • Issuer と Audience を確認しているか
  • OIDC の ID Token、Nonce、Redirect URI を正しく扱っているか
  • 認証と認可を混同していないか
  • アプリケーション側のセッション管理が適切か

LDAP は古い認証方式ではない

LDAP は「古い認証方式」というより、ディレクトリ情報へアクセスするためのプロトコルです。ユーザー DN を検索し、その DN で Bind して資格情報を確認し、必要に応じてグループや属性を取得します。

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

LDAP が危険になるのは、LDAP という名前のせいではありません。平文通信、過剰な Bind 権限、広すぎる検索範囲、弱いパスワードポリシー、監査不足、アカウントロック不足がある場合に危険になります。

逆に、LDAPS や StartTLS、適切な ACL、最小権限の Bind アカウント、監査ログ、ロックアウト、パスワードポリシーを組み合わせれば、LDAP は現在でも堅牢なディレクトリ基盤として使えます。

SAML / OIDC が高セキュリティに見える理由

SAML / OIDC が高セキュリティに見えるのは、プロトコル単体というより、IdP 側に認証機能を集約しやすいからです。MFA、条件付きアクセス、リスクベース認証、認証ログ、SSO を IdP 側でまとめて扱えることは大きな利点です。

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

ただし、これは IdP の設計、設定、運用、監査が適切である場合の話です。IdP 側の設定ミスは複数サービスへ波及します。便利な集約点は、同時に大きな影響点にもなります。

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

LDAP と SAML / OIDC は、どちらも認証に関係します。しかし、目的が違います。LDAP は、ディレクトリ内のユーザーやグループを参照し、内部システムや管理レイヤで資格情報を確認する用途に向いています。SAML / OIDC は、Web アプリケーションや SaaS に対して、IdP の認証結果を渡す用途に向いています。

たとえば、Linux ログイン、ネットワーク機器、ミドルウェア、社内運用ツール、古い業務システムでは LDAP が自然なことがあります。一方、SaaS、ブラウザ前提の Web アプリ、組織間 SSO、外部サービス連携では SAML / OIDC が自然です。

用途向きやすい方式理由
Linux やネットワーク機器のログインLDAPディレクトリ参照と Bind による確認が扱いやすい
SaaS への SSOSAML / OIDCIdP の認証結果をサービスへ渡しやすい
Web アプリのログイン統合OIDCID Token と Claims をアプリ側で扱いやすい
企業間の認証連携SAMLエンタープライズ SSO の実績が多い
非ブラウザ系クライアントLDAP や個別認証が残りやすいSAML / OIDC のリダイレクトフローを扱えないことがある

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

SAML / OIDC は便利ですが、実装と運用は軽くありません。特に古い製品や中途半端な対応のアプリケーションでは、設定項目の意味が分かりにくかったり、属性マッピングやログアウトが期待通りに動かなかったりします。

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

Nextcloud のように、ブラウザでは SAML 認証が成立しても、WebDAV クライアントが SAML のログインフローを扱えないケースがあります。この場合、SSO とアプリパスワード、LDAP、ローカル認証をどう併用するかまで設計しなければなりません。

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

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

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

SAML / OIDC も LDAP も、設計と運用次第で安全にも危険にもなります。セキュリティの高さは、方式の名前ではなく、責任分界、設定、実装、可視化、監査体制の全体で決まります。

まとめ

LDAP より SAML / OIDC の方が高セキュリティである、という単純な理解は危険です。LDAP はディレクトリ情報へアクセスするためのプロトコルであり、SAML / OIDC は IdP の認証結果をアプリケーションへ連携するための仕組みです。

SAML / OIDC は SSO、MFA、条件付きアクセス、認証ログの集約に強みがあります。一方で、LDAP はシステム管理レイヤ、内部システム、ネットワーク機器、ミドルウェアの認証や属性参照で自然に使える場面があります。

認証方式は流行や印象で選ぶものではありません。対象システム、利用者、アクセス経路、認可、セッション、監査、障害時の影響を含めて、適材適所で設計する必要があります。

参考情報

参考：

関連する記事

あわせて読みたい：

関連する記事
LDAP と SAML / OIDC の違い – 認証方式を高セキュリティという印象で選ばない

関連記事

認証・ID 管理ハブ – LDAP、SAML/OIDC、証明書認証を使い分ける フォワードプロキシ認証の課題 – LDAP / Basic 認証 / HTTPS プロキシ / SAML・OIDC を分けて考える Nextcloud SAML 認証で WebDAV が問題になる理由 – SSO とアプリパスワードを分けて考える Keycloak を利用した認証基盤の統合 – LDAP / Nextcloud / Kubernetes をどうつなぐか EAP-TLS と EAP-TTLS の違い – 証明書認証、ID / パスワード認証、TEAP との使い分け Zabbix で複数 LDAP 連携を使う時の注意点 – JIT プロビジョニングと認証設計 Apache Directory Studio で LDAP ユーザーを管理する – GUI クライアントの使いどころ Apache Directory Studio は開発終了なのか – LDAP クライアントの現状と使いどころ

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。（スパム対策）

トップへ戻る