MariaDB GSSAPI認証のプログラミング例：C、Javaでの接続方法

2025-05-26

GSSAPIとは？

GSSAPIは、アプリケーションがセキュリティサービス（認証、メッセージ保護など）を利用するための一般的なインターフェースを定義する標準です。GSSAPI自体は具体的な認証メカニズムを規定するものではなく、KerberosやNTLMといった様々な認証プロトコルをその下で利用することができます。

MariaDBでのGSSAPI認証プラグインの役割

このプラグインを使うことで、MariaDBは以下のような認証システムと連携できるようになります。

Microsoft Active Directory (Windows系システム): Windows環境では、GSSAPIと同様のSSPI (Security Support Provider Interface) というAPIが利用されます。MariaDBのGSSAPIプラグインは、Windows上ではKerberosやNTLM認証をサポートし、Active Directoryとの連携によるパスワードレス認証などを可能にします。
Kerberos (主にUnix系システム): Kerberosは、ネットワーク上でユーザーとサービスが安全に認証し合うための認証プロトコルです。主に大規模な企業ネットワークで利用されます。MariaDBのGSSAPIプラグインを使用することで、Kerberos認証基盤に統合された形でMariaDBへのアクセスを制御できます。

なぜGSSAPI認証プラグインを使うのか？

主なメリットは以下の通りです。

管理の簡素化: ユーザー認証を一元化することで、MariaDBのユーザー管理の負担を軽減できます。
セキュリティの強化: 集中管理された認証システムを利用することで、パスワードの管理やセキュリティポリシーの適用が容易になります。
シングルサインオン (SSO): ユーザーがすでにKerberosやActive Directoryで認証されている場合、MariaDBへのログイン時に再度パスワードを入力する必要がなくなります。

設定と利用方法

MariaDBでGSSAPI認証プラグインを利用するには、以下の手順が必要になります。

プラグインのインストール: MariaDBのパッケージにauth_gssapiという名前で含まれています。OSによっては別途パッケージのインストールが必要な場合があります。
Kerberosの設定 (Unixの場合): Kerberosの鍵ファイル (keytab) の作成など、Kerberos環境の準備が必要です。
MariaDBサーバーの設定: gssapi_keytab_pathなどのシステム変数を設定し、鍵ファイルのパスを指定します。
GSSAPIユーザーの作成: CREATE USERステートメントでIDENTIFIED VIA gssapi句を使用して、GSSAPI認証を利用するユーザーを作成します。オプションでrealmを指定することも可能です。

CREATE USER 'username'@'hostname' IDENTIFIED VIA gssapi;
-- または、realmを指定する場合
CREATE USER 'username'@'hostname' IDENTIFIED VIA gssapi USING '[email protected]';

Windows環境では設定が比較的簡単ですが、Unix環境ではKerberosの知識が多少必要になる場合があります。
クライアント側もGSSAPI認証をサポートしている必要があります。MariaDBの公式クライアントや一部のコネクタはGSSAPIをサポートしていますが、使用しているアプリケーションやライブラリが対応しているか確認が必要です。

GSSAPI 認証は Kerberos などの外部認証システムと連携するため、MariaDB 自体の設定に加えて、Kerberos 環境の設定やクライアント側の設定など、考慮すべき点が多く、エラーが発生しやすい傾向にあります。

一般的なエラーとトラブルシューティング

プラグインのロード失敗 (Plugin 'gssapi' init function returned error)

エラーメッセージ例

[Warning] mysqld: GSSAPI plugin : default principal 'mariadb/host.domain.com@REALM' not found in keytab
[ERROR] Plugin 'gssapi' init function returned error.

原因

Kerberos 設定（krb5.confなど）に問題がある。
Keytab ファイルに MariaDB サーバーのサービスプリンシパル (SPN) が登録されていない、または間違っている。
Keytab ファイルが見つからない、またはアクセス権がない。
auth_gssapi プラグインが正しくインストールされていない、またはロードされていない。

トラブルシューティング

プラグインのインストールとロード確認
- MariaDB サーバーの my.cnf (または my.ini for Windows) に plugin_load_add = auth_gssapi または plugin_load_add = auth_gssapi.so (Unix系) / plugin_load_add = auth_gssapi.dll (Windows) が記述されているか確認します。
- MariaDB を再起動し、サーバーのログ (mariadb.log など) で gssapi プラグインが正常にロードされているか確認します。
- INSTALL SONAME 'auth_gssapi'; コマンドで動的にプラグインをロードしてみることもできます。
Keytab ファイルの確認
- my.cnf で gssapi_keytab_path が正しく設定されているか確認します。パスが間違っていないか、ファイルが存在するか確認してください。
- MariaDB サーバーを実行しているユーザー（通常は mysql または mariadb）が keytab ファイルへの読み取り権限を持っているか確認します。
- klist -kt /path/to/your/keytab コマンドで keytab ファイルの内容を確認し、MariaDB サーバーのサービスプリンシパル (mariadb/host.domain.com@REALM のような形式) が含まれているか確認します。
サービスプリンシパル名の確認
- Kerberos KDC (Key Distribution Center) で登録されているサービスプリンシパル名が、MariaDB サーバーが想定しているものと一致しているか確認します。
- もしデフォルトのプリンシパル名 (例: mariadb/hostname.fqdn@REALM) と異なる場合は、gssapi_principal_name システム変数で明示的に指定します。

クライアント側の認証プラグインロード失敗 (Authentication plugin 'auth_gssapi_client' cannot be loaded)

エラーメッセージ例

ERROR 2059 (HY000): Authentication plugin 'auth_gssapi_client' cannot be loaded: The specified module could not be found.

原因

クライアントが GSSAPI 認証をサポートしていない。 (例: 一部の古いクライアントライブラリや非公式のコネクタ)
クライアント側で auth_gssapi_client プラグインが見つからない。

トラブルシューティング

クライアントプラグインの場所確認
- MariaDB クライアントツール (mysql コマンドなど) を使用している場合、--plugin-dir=/path/to/plugin/directory オプションでプラグインのパスを指定してみます。通常、プラグインは MariaDB インストールディレクトリの lib/plugin サブディレクトリにあります。
- クライアントライブラリ（例: Connector/C、Connector/J）を使用している場合は、そのライブラリが GSSAPI 認証をサポートしているバージョンであるか確認します。一部のクライアントは組み込みで GSSAPI をサポートしている場合もあります。
クライアントのバージョン確認
- 使用している MariaDB クライアントやアプリケーションが GSSAPI 認証に適切に対応しているか、公式ドキュメントで確認します。
- MariaDB 10.11以降では、クライアント側のGSSAPIプラグインが静的にリンクされているため、通常はDLL/SOファイルを明示的に指定する必要はありませんが、一部のツール（mariabackupなど）では例外がある場合があります。

アクセス拒否 (Access denied for user 'username'@'hostname' (using password: NO))

エラーメッセージ例

GSSAPI name mismatch, requested '[email protected]', actual name '[email protected]'
ERROR 1045 (28000): Access denied for user 'username'@'hostname' (using password: NO)

原因

KDCまたはDNSの設定に問題がある。
時刻同期の問題（クライアントとKDC間の時刻ずれ）。
Kerberos レルムが正しく設定されていない。
MariaDB ユーザー名と Kerberos プリンシパル名が一致しない。
MariaDB ユーザーアカウントが GSSAPI 認証を使用するように正しく設定されていない。
Kerberos チケット（TGT: Ticket Granting Ticket）が取得されていない、または期限切れ。

トラブルシューティング

Kerberos チケットの確認と取得
- クライアント側で klist コマンドを実行し、有効な TGT があるか確認します。
- TGT がない場合は、kinit コマンドで取得します。
MariaDB ユーザーの確認
- CREATE USER 'username'@'hostname' IDENTIFIED VIA gssapi AS 'kerberos_principal@REALM'; のように、ユーザーが IDENTIFIED VIA gssapi で作成されているか確認します。
- AS 句で指定された Kerberos プリンシパル名が、実際にクライアントが使用しているプリンシパル名と正確に一致しているか確認します。（大文字・小文字、realm の有無など）
- MariaDB のユーザー名と Kerberos プリンシパル名が異なる場合、AS 'kerberos_principal@REALM' を明示的に指定する必要があります。
時刻同期の確認
- クライアントマシン、MariaDB サーバー、Kerberos KDC のすべてのシステム時刻が同期されていることを確認します（NTP などを使用）。Kerberos は厳密な時刻同期を必要とします。
DNS解決の確認
- クライアントから MariaDB サーバーのホスト名が正しく解決できるか確認します。
- MariaDB サーバーから KDC のホスト名が正しく解決できるか確認します。
- 逆引き（IPアドレスからホスト名）も正しく行われることを確認します。
Kerberos レルムの設定
- クライアントとサーバーの両方で、krb5.conf ファイル内のレルム設定が正しいか確認します。特に、Kerberos プリンシパル名に含まれるレルムと設定が一致していることが重要です。

原因

Kerberos側のより詳細なログや診断が必要。
GSSAPIレイヤーでエラーが発生したが、具体的な原因がMariaDBに伝わっていない。

Kerberos KDCのログ確認
- Kerberos KDC サーバーのログを確認し、認証失敗に関する詳細な情報がないか調べます。
GSSAPIデバッグログの有効化
- Kerberos クライアント環境変数 KRB5_TRACE を設定して、GSSAPI のデバッグ出力を有効にします。
- MariaDB サーバー側でも、必要に応じてGSSAPI関連のデバッグオプションを有効にできる場合があります（MariaDBのバージョンと設定によります）。

公式ドキュメントの参照
MariaDB の GSSAPI 認証プラグインに関する公式ドキュメント (MariaDB Knowledge Base) は、設定手順や既知の制限、トラブルシューティング情報が豊富に記載されています。常に最新の情報を参照してください。
Kerberos の基本知識
GSSAPI 認証は Kerberos プロトコルに基づいているため、Kerberos の基本的な仕組み（プリンシパル、レルム、Keytab、TGT、サービスチケットなど）を理解していると、トラブルシューティングが格段に楽になります。
最小構成でのテスト
複雑な環境で問題が発生した場合、できるだけシンプルな構成（例: 同じホスト上でクライアントとサーバーを実行、一時的な Kerberos ユーザーの作成）で GSSAPI 認証が機能するかどうかをテストすると、問題の切り分けに役立ちます。
権限の確認
Keytab ファイル、設定ファイル、MariaDB のデータディレクトリなどのファイル権限が、MariaDB サーバープロセスを実行しているユーザーに正しく設定されているか確認してください。
詳細なログの確認
MariaDB のエラーログ (mariadb.log など) はもちろんのこと、システムログ (syslog、journalctl) や Kerberos KDC のログも確認してください。

MariaDB の GSSAPI 認証プラグインに関連するプログラミングの例コードを説明します。ここでは、主にサーバー側の設定と、クライアント側からの接続方法に焦点を当てます。

GSSAPI 認証は Kerberos などの外部認証システムと連携するため、コード例だけでは完結せず、Kerberos 環境の構築と設定が前提となります。

MariaDB サーバー側の設定（my.cnf）

MariaDB サーバーが GSSAPI 認証をサポートするように設定します。これはコードというよりは設定ファイルによる定義です。

[mysqld]
# GSSAPI 認証プラグインをロードする
plugin_load_add = auth_gssapi

# (オプション) Kerberos の keytab ファイルのパスを指定
# このファイルには、MariaDB サーバーのサービスプリンシパルが格納されている必要があります。
# MariaDB サーバーを実行するユーザーが読み取り権限を持つように設定してください。
gssapi_keytab_path = /etc/krb5.keytab

# (オプション) MariaDB サーバーのサービスプリンシパル名を明示的に指定する場合
# 通常はホスト名から自動決定されますが、異なる場合は指定します。
# 例: mariadb/your_server_hostname.example.com@YOUR_REALM
# gssapi_principal_name = mariadb/[email protected]

解説

gssapi_principal_name: MariaDB サーバーが自身を識別するための Kerberos プリンシパル名を明示的に指定します。通常は FQDN (Fully Qualified Domain Name) から自動的に決定されますが、明示的に指定することで柔軟性が増します。
gssapi_keytab_path: Kerberos のキー配布センター (KDC) から取得した、MariaDB サーバーのサービスプリンシパルを含む Keytab ファイルのパスを指定します。このファイルが正しく設定されていないと、サーバーは GSSAPI 認証リクエストを処理できません。
plugin_load_add = auth_gssapi: MariaDB サーバー起動時に auth_gssapi プラグインをロードするよう指示します。

MariaDB サーバー側での GSSAPI ユーザーの作成

MariaDB に、GSSAPI 認証を使用するユーザーを作成します。

-- GSSAPI 認証を使用するユーザーを作成する基本的な例
-- この場合、Kerberos プリンシパル名と MariaDB ユーザー名が同じであると仮定されます。
CREATE USER 'your_username'@'localhost' IDENTIFIED VIA gssapi;

-- リモートホストからの接続を許可し、Kerberos プリンシパル名を明示的に指定する例
-- 'your_username' は MariaDB のユーザー名、'your_kerberos_principal@YOUR_REALM' は対応する Kerberos プリンシパルです。
-- 両者が異なる場合に AS 句を使用します。
CREATE USER 'your_username'@'%' IDENTIFIED VIA gssapi AS 'your_kerberos_principal@YOUR_REALM';

-- 作成したユーザーに権限を付与する
GRANT SELECT ON your_database.* TO 'your_username'@'%';
FLUSH PRIVILEGES;

解説

AS 'kerberos_principal@REALM': オプションで、この MariaDB ユーザーに対応する Kerberos プリンシパル名を明示的に指定できます。MariaDB ユーザー名と Kerberos プリンシパル名が異なる場合や、複数の Kerberos プリンシパルが同じ MariaDB ユーザーにマップされる場合に便利です。
IDENTIFIED VIA gssapi: この句により、MariaDB がこのユーザーの認証に GSSAPI プラグインを使用するように設定されます。

クライアント側からの接続は、使用するプログラミング言語の MariaDB コネクタによって異なります。ここでは、代表的な例として C (MariaDB Connector/C) と Java (MariaDB Connector/J) を挙げます。

C 言語 (MariaDB Connector/C)

MariaDB Connector/C を使用する場合、通常は自動的に GSSAPI 認証が処理されます。重要なのは、クライアントを実行するシステムで有効な Kerberos チケット (TGT) が取得されていることです。

#include <mysql.h>
#include <stdio.h>
#include <stdlib.h>

int main() {
    MYSQL *conn;
    char *server = "localhost"; // MariaDB サーバーのホスト名
    char *user = "your_username"; // GSSAPI 認証で作成したMariaDBユーザー名
    char *database = "your_database"; // 接続するデータベース名
    int port = 3306; // MariaDB のポート番号

    // 有効な Kerberos チケット (TGT) がクライアント側で取得されていることを確認してください
    // 例: kinit your_kerberos_principal@YOUR_REALM

    conn = mysql_init(NULL);
    if (conn == NULL) {
        fprintf(stderr, "mysql_init() failed\n");
        exit(1);
    }

    // GSSAPI 認証プラグインを明示的に指定することも可能ですが、通常は不要です。
    // mysql_options(conn, MYSQL_DEFAULT_AUTH, "auth_gssapi_client");

    if (mysql_real_connect(conn, server, user, NULL, database, port, NULL, 0) == NULL) {
        fprintf(stderr, "mysql_real_connect() failed: %s\n", mysql_error(conn));
        mysql_close(conn);
        exit(1);
    }

    printf("Successfully connected to MariaDB using GSSAPI!\n");

    // 接続が成功したら、SQL クエリを実行できます
    // ...

    mysql_close(conn);
    return 0;
}

コンパイルと実行

# クライアント側で Kerberos チケットを取得
kinit your_kerberos_principal@YOUR_REALM

# コンパイル (libmariadbclient-dev または mariadb-connector-c-devel がインストールされている必要あり)
gcc -o gssapi_client gssapi_client.c $(pkg-config --libs --cflags mariadb)

# 実行
./gssapi_client

解説

クライアントを実行するユーザーが Kerberos で認証されており、有効な TGT を持っている必要があります。
MariaDB Connector/C は、ユーザー名が提供されていれば、パスワードが NULL の場合に GSSAPI 認証を自動的に試みます。

Java 言語 (MariaDB Connector/J)

MariaDB Connector/J の場合、JDBC 接続文字列に GSSAPI 関連のプロパティを追加します。

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class GssapiMariaDBClient {
    public static void main(String[] args) {
        // MariaDB サーバーの情報
        String host = "localhost"; // MariaDB サーバーのホスト名
        String port = "3306";
        String database = "your_database";
        String username = "your_username"; // GSSAPI 認証で作成したMariaDBユーザー名

        // Kerberos の JAAS (Java Authentication and Authorization Service) 設定ファイルを指定
        // このファイルは、Kerberos の設定や Keytab の場所を Java に伝えます。
        // 例: -Djava.security.krb5.conf=/etc/krb5.conf -Djava.security.auth.login.config=/path/to/jaas.conf
        // jaas.conf の例:
        /*
        com.sun.security.jgss.krb5.initiate {
          com.sun.security.auth.module.Krb5LoginModule required
          useTicketCache=true;
        };
        */

        // JDBC 接続文字列
        // authenticationPlugins=GSSAPI を指定することで、GSSAPI 認証を強制または優先させます。
        // user=your_username は、MariaDB 側で設定したGSSAPIユーザー名です。
        String jdbcUrl = String.format("jdbc:mariadb://%s:%s/%s?authenticationPlugins=GSSAPI&user=%s",
                                       host, port, database, username);

        Connection connection = null;
        try {
            // MariaDB JDBC ドライバーをロード
            Class.forName("org.mariadb.jdbc.Driver");

            // データベースに接続
            System.out.println("Attempting to connect to MariaDB...");
            connection = DriverManager.getConnection(jdbcUrl);
            System.out.println("Successfully connected to MariaDB using GSSAPI!");

            // 接続が成功したら、SQL クエリを実行できます
            // ...

        } catch (ClassNotFoundException e) {
            System.err.println("MariaDB JDBC Driver not found: " + e.getMessage());
        } catch (SQLException e) {
            System.err.println("Failed to connect to MariaDB: " + e.getMessage());
            e.printStackTrace();
        } finally {
            if (connection != null) {
                try {
                    connection.close();
                } catch (SQLException e) {
                    System.err.println("Error closing connection: " + e.getMessage());
                }
            }
        }
    }
}

実行時の注意点

Java アプリケーションで Kerberos 認証を行うには、JAAS (Java Authentication and Authorization Service) の設定が重要です。

java.security.auth.login.config: JAAS のログイン設定ファイル (jaas.conf など) の場所を指定します。このファイルは、Java アプリケーションが Kerberos 認証を使用する方法を定義します。
java.security.krb5.conf: Kerberos の設定ファイル (krb5.conf) の場所を指定します。

例の jaas.conf

com.sun.security.jgss.krb5.initiate {
  com.sun.security.auth.module.Krb5LoginModule required
  useTicketCache=true; // クライアントの Kerberos チケットキャッシュを利用する
  // useKeyTab=true; // クライアントが Keytab を持っている場合はこちらを使用
  // storeKey=true; // Kerberos チケットキャッシュに保存するかどうか
  // principal="your_kerberos_principal@YOUR_REALM"; // 明示的なプリンシパル指定 (useTicketCache=falseの場合など)
};

Java コマンド例

# クライアント側で Kerberos チケットを取得
kinit your_kerberos_principal@YOUR_REALM

# コンパイル
javac GssapiMariaDBClient.java

# 実行
java -Djava.security.krb5.conf=/etc/krb5.conf -Djava.security.auth.login.config=/path/to/jaas.conf GssapiMariaDBClient

解説

JAAS の設定 (krb5.conf および jaas.conf) は、Java が Kerberos 環境と連携するための鍵となります。これらの設定は、JVM の起動オプションとして渡されるか、コード内でプログラム的に設定されます。
authenticationPlugins=GSSAPI: JDBC 接続文字列でこのプロパティを指定することで、MariaDB Connector/J に GSSAPI 認証の使用を指示します。

GSSAPI 認証を MariaDB で利用するプログラミングは、大きく以下のステップに分かれます。

Kerberos 環境の準備: KDC の設定、サービスプリンシパルと Keytab ファイルの作成、ユーザープリンシパルの発行。
MariaDB サーバーの設定: my.cnf で GSSAPI プラグインをロードし、Keytab ファイルのパスを指定。
MariaDB ユーザーの作成: CREATE USER ... IDENTIFIED VIA gssapi ... で GSSAPI 認証を利用するユーザーを定義。
クライアント側の設定とコード:
- クライアントを実行するユーザーが有効な Kerberos チケットを取得していること。
- 使用するプログラミング言語の MariaDB コネクタが GSSAPI 認証をサポートしていること。
- 必要に応じて、接続文字列やクライアントの設定で GSSAPI 認証を有効にすること。特に Java の場合は JAAS の設定が重要です。

GSSAPI の「代替」として考えられるのは、主にMariaDBが提供する他の認証プラグインや、外部システムとの連携方法です。

mysql_native_password または caching_sha2_password (デフォルト)

これは最も一般的な認証方法で、ユーザー名とパスワードを MariaDB 自身が管理します。

特徴

パスワード管理
MariaDB サーバー内でパスワードを管理します。caching_sha2_password はより強力なハッシュアルゴリズムを使用します。
利便性
多くのアプリケーションやツールがこの認証方法をサポートしています。
シンプルさ
設定が非常に簡単で、特別な外部サービスは不要です。

コード例 (一般的な接続)

// Java (MariaDB Connector/J)
String url = "jdbc:mariadb://localhost:3306/your_database";
String user = "your_user";
String password = "your_password";
Connection conn = DriverManager.getConnection(url, user, password);

# Python (MariaDB Connector/Python)
import mariadb
conn = mariadb.connect(
    host="localhost",
    port=3306,
    user="your_user",
    password="your_password",
    database="your_database"
)

欠点

集中管理の欠如
ユーザー認証を他の企業システムと統合するのが難しい場合があります。
シングルサインオン (SSO) 不可
ユーザーは MariaDB 専用のパスワードを別途管理する必要があります。

Unix ソケット認証 (unix_socket)

Linux/Unix システムで、同じホスト上のクライアントがソケットファイル経由で接続する場合に、OS のユーザー認証を利用します。

特徴

MariaDB サーバー上のローカル接続に限定
リモートからの接続には利用できません。
便利
OS ユーザーが MariaDB ユーザーと一致していれば、パスワードなしで接続できます。
高いセキュリティ
パスワードがネットワーク上を流れることがありません。

MariaDB ユーザー作成例

CREATE USER 'your_os_username'@'localhost' IDENTIFIED VIA unix_socket;
GRANT SELECT ON your_database.* TO 'your_os_username'@'localhost';

コード例 (Python)

import mariadb
# Unix ソケット経由で接続 (ホスト名 'localhost' で自動的に試行されることが多い)
conn = mariadb.connect(
    unix_socket="/var/run/mysqld/mysqld.sock", # MariaDB のソケットファイルのパス
    user="your_os_username",
    database="your_database"
)

欠点

OS ユーザーと MariaDB ユーザーのマッピングが必要です。
リモート接続には使用できません。

PAM 認証 (auth_pam)

PAM (Pluggable Authentication Modules) は、Unix 系システムで認証サービスをモジュール化するためのフレームワークです。これにより、MariaDB は PAM を介して、LDAP、Active Directory、ローカルパスワードファイルなど、様々な認証バックエンドと連携できます。

特徴

GSSAPI の代替
Kerberos (GSSAPI) が直接サポートされていない、またはPAM経由でKerberosを扱いたい場合に有効です。
集中管理
既存の PAM ベースの認証インフラストラクチャを利用できるため、ユーザー管理を一元化できます。
柔軟性
PAM の設定次第で、多種多様な認証方法を MariaDB に統合できます。

MariaDB ユーザー作成例

-- PAM 認証を使用するユーザーを作成
CREATE USER 'your_pam_user'@'%' IDENTIFIED VIA pam;

-- PAM サービス名や PAM の設定を細かく制御することも可能
-- CREATE USER 'your_pam_user'@'%' IDENTIFIED VIA pam AS 'service=your_pam_service';

コード例 (クライアント側)
クライアント側のコードは、基本的に通常のユーザー/パスワード認証と同じです。PAM が認証プロセスを処理するため、アプリケーションコードは特別な変更を必要としません。

// Java (MariaDB Connector/J)
String url = "jdbc:mariadb://localhost:3306/your_database";
String user = "your_pam_user";
String password = "your_pam_password"; // PAM が検証するパスワード
Connection conn = DriverManager.getConnection(url, user, password);

欠点

Windows 環境では直接利用できません（Windows には PAM がないため）。
MariaDB サーバーが稼働する OS に依存します。
PAM の設定と管理の知識が必要です。

LDAP 認証 (auth_ldap または auth_ldap2)

MariaDB は LDAP (Lightweight Directory Access Protocol) サーバー（例: OpenLDAP, Microsoft Active Directory）と直接連携するためのプラグインを提供しています。これにより、既存の企業ディレクトリサービスでユーザーを認証できます。

特徴

クロスプラットフォーム
MariaDB が Linux でも Windows でも動作し、LDAP サーバーと連携できます。
SSO の可能性
LDAP ディレクトリと連携している他のサービスと認証基盤を共有できます（厳密な SSO ではないが、ユーザー管理の一元化）。
集中管理
LDAP ディレクトリに存在するユーザーを一元的に管理できます。

MariaDB サーバー設定 (my.cnf) 例

[mysqld]
plugin_load_add = auth_ldap
# または plugin_load_add = auth_ldap2

# LDAP サーバーのURI (例: ldap://your_ldap_server:389)
ldap_url = ldap://your_ldap_server:389

# 検索ベースDN (ユーザーの検索を開始するディレクトリの場所)
ldap_base_dn = ou=Users,dc=example,dc=com

# (オプション) バインドDNとパスワード (LDAPサーバーに匿名で接続できない場合)
# ldap_bind_dn = cn=admin,dc=example,dc=com
# ldap_bind_password = your_ldap_bind_password

# ユーザー名属性 (例: uid, sAMAccountName)
ldap_uid_attribute = uid

# ユーザーフィルタ (オプション、特定のユーザータイプのみを許可する場合など)
# ldap_user_filter = (objectClass=person)

MariaDB ユーザー作成例

-- LDAP 認証を使用するユーザーを作成
CREATE USER 'your_ldap_username'@'%' IDENTIFIED VIA ldap;
-- または auth_ldap2 の場合
-- CREATE USER 'your_ldap_username'@'%' IDENTIFIED VIA ldap2;

コード例 (クライアント側)
これも PAM と同様に、クライアント側のコードは標準のユーザー名/パスワード認証と同じです。

// Java (MariaDB Connector/J)
String url = "jdbc:mariadb://localhost:3306/your_database";
String user = "your_ldap_username";
String password = "your_ldap_password"; // LDAP が検証するパスワード
Connection conn = DriverManager.getConnection(url, user, password);

欠点

ネットワーク経由での通信が必要なため、LDAP サーバーへの接続性やセキュリティに注意が必要です。
LDAP サーバーの設定と管理の知識が必要です。

SSL/TLS 証明書認証 (auth_tls)

MariaDB は、クライアント証明書による認証をサポートしています。これは GSSAPI や他のパスワードベースの認証とは異なり、秘密鍵と公開鍵証明書を用いてクライアントを認証します。

特徴

GSSAPI とは異なるアプローチ
SSO は提供しませんが、パスワードなしでの認証を実現します。
相互認証
サーバーとクライアントの両方が互いの身元を確認できます。
高セキュリティ
パスワードが不要で、鍵ペアに基づいて強力な認証が可能です。

MariaDB サーバー設定 (my.cnf) 例

[mysqld]
ssl_ca = /path/to/ca.pem
ssl_cert = /path/to/server-cert.pem
ssl_key = /path/to/server-key.pem
require_secure_transport = ON # TLS/SSL 接続を必須にする場合

MariaDB ユーザー作成例

-- 特定の証明書のサブジェクトによって認証されるユーザーを作成
CREATE USER 'your_user'@'%' REQUIRE X509;

-- または、特定の証明書（識別名）を指定
-- CREATE USER 'your_user'@'%' REQUIRE SUBJECT '/CN=your_client_cert';

コード例 (Java - MariaDB Connector/J)
クライアント側で KeyStore と TrustStore を設定し、クライアント証明書を提示するようにします。

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Properties;

public class TlsMariaDBClient {
    public static void main(String[] args) {
        String host = "localhost";
        String port = "3306";
        String database = "your_database";
        String user = "your_user"; // MariaDB ユーザー名 (パスワードは不要)

        // クライアントの証明書と秘密鍵を含むKeyStore
        System.setProperty("javax.net.ssl.keyStore", "/path/to/client_keystore.jks");
        System.setProperty("javax.net.ssl.keyStorePassword", "your_keystore_password");

        // サーバー証明書を検証するためのTrustStore (CA証明書など)
        System.setProperty("javax.net.ssl.trustStore", "/path/to/client_truststore.jks");
        System.setProperty("javax.net.ssl.trustStorePassword", "your_truststore_password");

        String jdbcUrl = String.format("jdbc:mariadb://%s:%s/%s?user=%s",
                                       host, port, database, user);

        Properties props = new Properties();
        // props.setProperty("useSSL", "true"); // MariaDB Connector/J は通常自動で判断

        Connection connection = null;
        try {
            Class.forName("org.mariadb.jdbc.Driver");
            connection = DriverManager.getConnection(jdbcUrl, props);
            System.out.println("Successfully connected to MariaDB using TLS client certificate authentication!");
        } catch (ClassNotFoundException e) {
            System.err.println("MariaDB JDBC Driver not found: " + e.getMessage());
        } catch (SQLException e) {
            System.err.println("Failed to connect to MariaDB: " + e.getMessage());
            e.printStackTrace();
        } finally {
            if (connection != null) {
                try {
                    connection.close();
                } catch (SQLException e) {
                    System.err.println("Error closing connection: " + e.getMessage());
                }
            }
        }
    }
}

既存の Kerberos/AD 環境との統合は直接的には行えません。
証明書の管理 (生成、配布、失効) が複雑です。

手軽さや汎用性を重視するなら
caching_sha2_password (ただし、SSO や一元管理は期待できません)。
同じサーバー上で非常にシンプルな認証が必要なら
Unix ソケット認証。
パスワードなし認証と強力なセキュリティが必要で、証明書管理が可能なら
SSL/TLS 証明書認証。
既存の社内認証システムとの連携を重視するなら
PAM または LDAP 認証。特に Active Directory 環境であれば LDAP が有力です。