Nextcloud と連携してみよう

Drupal と Nextcloud を連携させる

Drupal さっぽろ勉強会

内容

Nextcloud と Drupal
- Nextcloud とは
- Drupal との連携
予備知識の整理
- ソーシャルログインと SSO
- 基盤となる技術／規格
- 参考資料（全体把握、OAuth、OIDC）
実際に動かしてみる
- 実習環境の準備
- OAuth2 によるソーシャルログイン
- OIDC による SSO
- デジタルアセットの共有

Nextcloud と Drupal

Nextcloud とは

元はストレージ共有の ownCloud からフォーク
Google Apps と同等の機能を OSS で
- ドキュメント共有
- メール、カレンダー、スケジュール管理
「アプリ」による機能拡張
主に組織内のデータ共有と管理に使われる

Nextcloud は、ストレージ共有を中核とするオープンソースの Web アプリケーションです。同種の ownCloud のフォークから発展したプロジェクトです。「アプリ」と呼ばれる拡張プログラムで機能を拡張できる設計になっており、チャット、メール、カレンダ、スケジュール管理、ドキュメント作成といった機能を統合したグループウェアのような環境を提供します。

対外的に発信する公開コンテンツの管理を基本的な目的とする Drupal に対し、Nextcloud は組織内でのデータ共有と管理を狙いとしたアプリケーションと言えます。両者を組み合わせることで、より包括的なデジタル情報管理の基盤を構築することができます。

Drupal との連携

ユーザー登録の一元化
- 一方にログインすれば両方を使える
- シングルサインオン
DAM（Digital Asset Management）
- 画像や動画などのデジタル資産の共有
- ファイル管理は Nextcloud で
- Web サイトでの活用は Drupal で

Drupal と Nextcloud を連携させることで生まれるメリットについて、ここでは次の２つを取り上げます。

１つはユーザー登録の一元化です。ユーザー登録を行う役割を一方に決めておき、そこでユーザーを登録することで両方のサービスを利用できるようにします。これは、Google や GitHub など外部の登録ユーザーでログインできる connpass のようなサービスと技術的に同じものを、ユーザー登録を行う場所も含めて自前で用意する考え方です。

もう１つはデジタル資産の管理と Web 活用です。共通アカウントで Drupal と Nextcloud の両方のサービスを利用できる環境を確立したら、それぞれが得意とする機能を適材適所で組み合わせて自在に活用できます。Nextcloud は元々ストレージ共有アプリケーションなので、文書・画像・動画・音声といったデジタル資産の管理が得意です。他方 Drupal は Web サイトのコンテンツ管理システムがベースですから、Web サイトに掲載するコンテンツの扱いで本領を発揮します。それぞれ出自や目的は異なりますが、デジタル資産の活用に関わるシステムである点は共通です。両者を連携させることで、組織内で管理するデジタルアセットを必要に応じて Web サイトで活用する仕組みを構築できるでしょう。このように、軸の異なるシステムが交差するポイントに連携メリットの可能性があります。

予備知識の整理

ソーシャルログインと SSO

ソーシャルログイン
SSO（Single Sign-On）

ソーシャルログインは、Facebook や X（旧 Twitter）などの SNS や、Google・Apple・GitHub といった大手のサービスで登録したユーザーアカウントを利用して、Web 上の別のサービス利用させるものです。たとえば、X や Facebook や GitHub のアカウントで connpass に登録／ログインできるのはソーシャルログインです。

SSO（Single Sign-On）は、異なる復数のサービスを１つの組織が運営している文脈において、各サービス共通のユーザーで一度のログインしておけば全てのサービスが利用可能になるものを表す用語です。たとえば、Google アカウントで一度ログインしておけば、Google 社による各種サービスの多くはそのまま（再度ログインする必要なしに）利用できます。これが SSO です。

サービスを提供するシステムの視点から見れば、どちらもユーザーの管理や識別を外部に移譲する仕組みに基づいており、技術的にも共通する部分がありますが、後者はより大規模なシステムにおけるユーザーの識別手法として使われる場合が多いようです。

SSO の方式

エージェント方式
リバースプロキシ方式
代理認証方式
透過型方式
フェデレーション方式

参照：
https://www.hitachi-solutions.co.jp/iam/sol_signon.html

エージェント方式は、シングルサインオンしたいすべてのサービスにエージェントを導入する手法です。エージェントからの認証情報をもとにシングルサインオンサーバー（SSOサーバー）で認証を行います。 リバースプロキシ方式は、端末とWebサーバの間にリバースプロキシを設置する方式です。リバースプロキシサーバで認証を行います。 代理認証方式は、ユーザーの端末に設置したエージェントがユーザーに代わり各サービスへのログインを行う方式です。 透過型方式は、端末と Web システムの通信を監視する方式です。認証が必要な場合のみ、認証情報を Web システムに送信します。 フェデレーション方式は、復数のサービスを利用する際に、別システムになされた認証の情報に基づき、再度認証画面を表示することなく連携する仕組みです。

オープンな標準化された技術に基づいて Web 上の任意のサービス間で SSO を実現するには、フェデレーション方式が適しています。

基盤となる技術／規格

SAML（Security Assertion Markup Language）は、XML の一種である SAML 形式の認証メッセージ交換を使用したフェデレーション方式の SSO 標準です。企業向けの大規模システムの SSO で多く使用されてきました。 CAS は、Web サイトがユーザーを認証できるようにする中央認証サービスです。CAS は、SAML（バージョン 2）の ID プロバイダとしても機能します。

OAuth は、複数サービスを連携して動作させる目的で使用される仕組みです。あるサービスから別のサービスを利用する際に、ユーザーが利用先サービスのユーザーとパスワードを毎回入力しなくても済ませるためのアクセストークンと呼ばれる認可情報を発行する手順を標準化したものです。アクセストークンを発行する際にユーザーへの確認が行われ、このとき事実上の認証も行われるため、ソーシャルログインにも使用されます。OAuth1 と OAuth2 とがあり両者に互換性はなく、現在は OAuth2 が主に使われています。

OIDC（OpenID Connect）は、OAuth2 においてシステム実装の選択に委ねていた領域を、JWT と呼ばれる JSON 形式のトークンを使用して標準化したもので、OAuth2 を基盤とするフェデレーション方式の SSO 認証の規格に位置づけることができます。

参考：IDaaS について

ID 管理
認証／認可
SSO
多要素認証
ログ管理

参考：OSS の Keycloak

参考資料

実習環境の準備

ffdsm の利用

## dsm47という名前のフォルダにffdsmをクローンする
$ git clone https://github.com/bkenro/ffdsm.git dsm47
## フォルダに移動して Vagrantfile を編集する
$ cd dsm47
$ vi Vagrantfile

synced_folder の調整

Vagrant.configure("2") do |config|
  config.vm.box = "bkenro/ffdsm"
  config.vm.network "private_network", ip: "192.168.56.81"
  config.vm.hostname = "dsm47.internal"
  config.vm.provider "virtualbox" do |vb|
    vb.name = "vm-dsm47"
    vb.customize ["modifyvm", :id, "--memory", "2048"]
  end
  # config.vm.synced_folder ".", "/vagrant", disabled: true
  # config.vm.synced_folder "www", "/var/www", type: "virtualbox"
end

仮想マシンの起動

$ vagrant up
〜
$ vagrant ssh

Nextcloud の入手とインストール

https://nextcloud.com/install/

$ sudo chown vagrant:vagrant /var/www
$ cd /var/www
$ wget https://download.nextcloud.com/server/releases/latest.zip
$ unzip latest.zip
$ sudo chown -R www-data:www-data nextcloud

仮想ホストの設定

展開したフォルダを仮想ホストに対応づけます。

$ cd /etc/apache2/sites-available
$ sudo cp example.conf nextcloud.conf
$ sudo vi nextcloud.conf

/etc/apache2/sites-available/nextcloud.conf

<VirtualHost *:80>
  DocumentRoot /var/www/nextcloud
  ServerName nextcloud.internal

  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined

  <Directory "/var/www">
    AllowOverride All
  </Directory>

</VirtualHost>

nextcloud.conf ファイルを保存した後、設定を有効化します。

## 仮想マシン側
$ sudo a2ensite nextcloud.conf
〜
$ sudo systemctl restart apache2

ホスト名の登録

## ホスト側
$ sudo vi /etc/hosts

### local dev hosts: dsm47
192.168.56.81   drupal.internal
192.168.56.81   nextcloud.internal

Nextcloud インストーラ

セットアップの問題確認

php.ini の調整

/etc/php/8.3/apache2/php.ini

〜
memory_limit = 512M
〜
opcache.interned_strings_buffer=16
〜

DB インデックスと Mimetype の修正

$ cd /var/www/nextcloud
$ sudo -u www-data php occ db:add-missing-indices
$ sudo -u www-data php occ maintenance:repair --include-expensive

Mailpit の利用設定

設定項目	値
送信モード	SMTP
暗号化	None/STARTTLS
送信元アドレス	任意（例：admin@nextcloud.internal）
サーバーアドレス	localhost:1025
認証を必要とする	OFF

テストメールの受信確認

https 接続の設定

## 自己認証局の構成
$ mkcert　-install

## ルート証明書と鍵の確認
$ ls $(mkcert -CAROOT)
rootCA-key.pem  rootCA.pem
## Vagrant の共有フォルダに移動
$ cd dsm47
## ルート証明書と秘密鍵をコピー
$ cp $(mkcert -CAROOT)/*.pem .

サーバー証明書の発行

$ mkcert nextcloud.internal

Created a new certificate valid for the following names 📜
 - "nextcloud.internal"

The certificate is at "./nextcloud.internal.pem" and the key at "./nextcloud.internal-key.pem" ✅

It will expire on 24 March 2027 🗓

サーバー証明書の設置

## 仮想マシン上
## ホストとの共有フォルダに移動
$ cd /vagrant
## サーバー証明書と鍵を所定の場所にコピー
$ sudo cp nextcloud.internal.pem /etc/ssl/certs/
$ sudo cp nextcloud.internal-key.pem /etc/ssl/private/

## Apache の SSL モジュールを有効化
$ sudo a2enmod ssl

HTTPS 用の仮想ホストの追加

## HTTPS 用の仮想ホストを追加
$ cd /etc/apache2/sites-available
$ sudo vi nextcloud-ssl.conf

/etc/apache2/sites-available/nextcloud-ssl.conf

<VirtualHost *:443>
  ## 対象ドメインと対応するディレクトリを指定
  ServerName nextcloud.internal
  DocumentRoot /var/www/nextcloud
  ## Apacheログの設定
  ErrorLog ${APACHE_LOG_DIR}/nextcloud_error.log
  CustomLog ${APACHE_LOG_DIR}/nextcloud_access.log combined
  ## HTTPSの有効化と証明書／鍵ファイルの指定
  SSLEngine on
  SSLCertificateFile      /etc/ssl/certs/nextcloud.internal.pem
  SSLCertificateKeyFile   /etc/ssl/private/nextcloud.internal-key.pem

  <FilesMatch "\.(?:cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
  </FilesMatch>

  <Directory "/var/www">
    AllowOverride All
  </Directory>

  <Directory /usr/lib/cgi-bin>
    SSLOptions +StdEnvVars
  </Directory>
</VirtualHost>

設定の反映

## 作成したhttps用の設定を組み込む
$ sudo a2ensite nextcloud-ssl.conf
## Webサーバーを再起動して反映
$ sudo systemctl restart apache2

仮想マシン内のホスト設定

$ sudo vi /etc/hosts

/etc/hosts

〜
### local dev hosts: dsm47
192.168.56.81   drupal.internal
192.168.56.81   nextcloud.internal

仮想マシン内で接続してみると

$ wget https://nextcloud.internal/
--2024-12-24 15:09:02--  https://nextcloud.internal/
Resolving nextcloud.internal (nextcloud.internal)... 192.168.56.81
Connecting to nextcloud.internal (nextcloud.internal)|192.168.56.81|:443... connected.
ERROR: cannot verify nextcloud.internal's certificate, issued by ‘CN=mkcert bkenro@dev01,OU=bkenro@dev01,O=mkcert development CA’:
  Unable to locally verify the issuer's authority.
To connect to nextcloud.internal insecurely, use `--no-check-certificate'.

CA の登録

## 仮想マシン内の操作
$ cd /vagrant
$ sudo cp rootCA.pem /usr/share/ca-certificates/
$ sudo vi /etc/ca-certificates.conf

/etc/ca-certificates.conf

〜
rootCA.pem

$ sudo update-ca-certificates

実際に動かしてみる

実装例１

Nextcloud
- 標準の OAuth2 機能
Drupal
- Social Auth Nextcloud

実装例２

Nextcloud を OIDC の IDP、Drupal を SP

Nextcloud
- OpenID Connect Login
Drupal
- OpenID Connect / OAuth client

実装例３

Drupal を OIDC の IDP、Nextcloud を SP

Drupal
- OAuth2 Server
Nextcloud
- Social Login
- https://github.com/zorn-v/nextcloud-social-login

逆のパターンも考えられます。つまり、Drupal を OIDC の IDP とし、Nextcloud を SP とする構成です。この場合、Drupal 側に OAuth2 Server モジュールを入れて、Nextcloud 側に Social Login アプリを入れる方法などが考えられます。

実際に試してみたところでは、oauth2_server にはパッチを当てる必要あるほか、リダイレクトURLなどの情報はドキュメントで確認できず、実際に動かしたときのリダイレクト先URLで確認しました。また、エンドポイントも同様で、モジュールの routing.yml ファイルから推測して設定する必要がありました。

一応、動かすことはできましたが、Nextcloud 側のユーザーの表示名が Drupal 側の uid（整数）になる問題があるようです。少なくとも現時点では、実際に使うにはまだ課題があるように思いました。

デジタルアセットの共有

アセットの選択画面

まとめ

今回の内容

Nextcloud と Drupal
- Nextcloud とは
- Drupal との連携
予備知識の整理
- ソーシャルログインと SSO
- 基盤となる技術／規格
- 参考資料（全体把握、OAuth、OIDC）
実際に動かしてみる
- 実習環境の準備
- OAuth2 によるソーシャルログイン
- OIDC による SSO
- デジタルアセットの共有

Nextcloud と連携してみよう

内容

Nextcloud と Drupal

Nextcloud とは

Drupal との連携

予備知識の整理

ソーシャルログインと SSO

SSO の方式

基盤となる技術／規格

参考：IDaaS について

参考：OSS の Keycloak

参考資料

実習環境の準備

ffdsm の利用

synced_folder の調整

仮想マシンの起動

Nextcloud の入手とインストール

仮想ホストの設定

ホスト名の登録

Nextcloud インストーラ

Nextcloud インストーラ

セットアップの問題確認

php.ini の調整

DB インデックスと Mimetype の修正

Mailpit の利用設定

テストメールの受信確認

https 接続の設定

サーバー証明書の発行

サーバー証明書の設置

HTTPS 用の仮想ホストの追加

設定の反映

仮想マシン内のホスト設定

仮想マシン内で接続してみると

CA の登録

実際に動かしてみる

Drupal とソーシャルログイン

Drupal と SSO（OIDC 以外）

Drupal と OAuth2/OIDC

Nextcloud と SSO

実装例１

実装例２

実装例３

デジタルアセットの共有

アセットの選択画面

まとめ

今回の内容