Nextcloud SAML 認証で WebDAV が問題になる理由

Nextcloud を Keycloak の SAML 認証と連携させると、ブラウザからのログインはかなりきれいに統合できます。SSO としては自然で、ユーザー体験も分かりやすいです。

一方で、Nextcloud には WebDAV という別の重要なアクセス経路があります。ここで問題になるのは、SAML 認証そのものの良し悪しではなく、ブラウザ前提の SSO と WebDAV クライアントの認証方式が同じではないことです。

発生した問題

私の環境では、Nextcloud を Keycloak の SAML と連携し、試行錯誤は必要だったものの、ブラウザでは問題なく認証できるようになりました。Mac や iPhone のクライアントからも利用できました。

しかし、WebDAV を SAML 認証のまま使おうとすると問題が出ました。WebDAV クライアントが SAML のリダイレクト、IdP 側のログイン、セッション確立といった流れを理解してくれるとは限らないためです。

• ブラウザでは SAML のリダイレクトを追跡できる
• WebDAV クライアントはユーザー名とパスワードを前提にすることが多い
• OS 標準の WebDAV マウント機能は SSO フローに弱い場合がある
• 結果として、ブラウザではログインできるのに WebDAV では認証できない状態が起きる

SAML はブラウザ向けの認証フロー

SAML は非常に便利で、組織内の認証基盤とアプリケーションを統合するには強力です。ただし、その強さは主にブラウザを前提にしたリダイレクト型の認証フローにあります。

WebDAV は HTTP ベースのプロトコルですが、実際のクライアントは OS 標準のファイルマネージャー、同期ツール、バックアップアプリ、スマートフォンアプリなど多様です。これらがすべて SAML のログインフローを扱えるとは限りません。

Nextcloud の WebDAV はアプリパスワードで考える

Nextcloud の公式ユーザーマニュアルでも、サードパーティーの WebDAV クライアントを使う場合は通常のパスワードではなくアプリパスワードを使うことが案内されています。これはセキュリティ上も運用上も自然な設計です。

つまり、SAML で Nextcloud のブラウザログインを統合しても、WebDAV クライアントには別途アプリパスワードを発行して使う、という整理が現実的です。

https://cloud.example.com/remote.php/dav/files/USERNAME/

WebDAV の URL は上記のような形になります。実際のクライアント設定では、Nextcloud のユーザー名と、セキュリティ設定から発行したアプリパスワードを使うことになります。

LDAP 認証との違い

LDAP 認証の場合、Nextcloud 側でユーザー名とパスワードを受け取り、サーバーサイドで LDAP に問い合わせる形になります。そのため、WebDAV クライアントがユーザー名とパスワードを送るだけでも認証が成立しやすいです。

一方、SAML は IdP とのブラウザベースの認証フローを前提にします。WebDAV クライアントがその流れに対応していなければ、SAML を有効にしただけでは WebDAV まで同じように使えるとは限りません。

設計時に決めるべきこと

Nextcloud に SAML を導入する場合、最初に決めるべきなのは「どのアクセス経路を正式にサポートするのか」です。ブラウザだけを対象にするのか、デスクトップクライアント、モバイルアプリ、WebDAV マウント、バックアップツールまで含めるのかで、設計は変わります。

確認する観点

• ブラウザログインを SAML に統一するのか
• Nextcloud 公式クライアントを許可するのか
• OS 標準の WebDAV マウントを許可するのか
• アプリパスワードの発行を許可するのか
• LDAP ユーザーやローカル管理者の直接ログイン経路を残すのか
• 緊急時に /login?direct=1 のような直接ログイン経路を使えるようにしておくのか

特に管理者アカウントについては、SSO 設定ミスでログイン不能にならないように、Nextcloud 側に直接入れる経路を残す設計が必要です。

自分の環境での結論

私の環境では、Nextcloud に柔軟なアクセス経路を持たせたいという要求があります。ブラウザだけで完結するシステムなら SAML は非常に有効ですが、WebDAV や各種クライアントを広く使いたい場合は、SAML だけで全方位を満たすのは難しいと感じました。

そのため、Nextcloud の認証を考える時は、SAML を「高度な認証方式」として単純に上位互換扱いするのではなく、WebDAV のような非ブラウザ系アクセスをどう扱うかまで含めて判断する必要があります。

まとめ

Nextcloud と SAML の組み合わせは、ブラウザベースの SSO には強いです。しかし、WebDAV は別の認証モデルで動くクライアントが多く、SAML 認証にそのまま乗せられるとは限りません。

WebDAV を使う必要があるなら、アプリパスワードを前提にするのか、LDAP 認証を併用するのか、WebDAV をサポート対象外にするのかを明確にした方がよいです。SAML の導入可否は、認証方式だけではなく、Nextcloud をどの経路から使うかという運用設計で決まります。

参考

• Nextcloud User Manual – Accessing Nextcloud files using WebDAV
• Nextcloud App Store – SSO & SAML authentication
• Nextcloud Portal – Configuring Single-Sign-On

Related posts:

LDAP より SAML/OIDC が高セキュリティという幻想 – 認証方式は適材適所で選ぶ Nextcloud における .DS_Store Mac Finder WebDAV アクセスが遅すぎる EAP-TEAP の仕組みと設計指針 CentOS 8 OpenLDAP LDAP クライアント – ldapsearch と証明書信頼設定 CentOS 8 SSSD Linux クライアント – LDAP 認証の基本設定 Ubuntu 22.04 389 Directory Server #3 – ベースエントリーの登録 Ubuntu 22.04 389 Directory Server #4 – BIND ユーザーとアクセス制御 Ubuntu 22.04 389 Directory Server #5 – グループとユーザーの登録 LDAP クライアント Apache Directory Studio は開発終了なのか Samba の SID と認証の整理 Zabbix で複数 LDAP 連携を使う時の注意点 – JIT プロビジョニングと認証設計