Authelia

Authelia は、リバースプロキシの横に置いて使う認証サーバーです。自分で動かしている Web アプリにログイン機能がなくても、アプリの手前でログイン画面と多要素認証をかけられます。

この記事は、自宅サーバーや社内で Web アプリを公開していて、その入口を守りたい人に向けています。読み終えると、次のことができるようになります。

• リバースプロキシと Authelia がどう連携するかを説明する
• 公式の Docker Compose バンドルで、手元の Linux 端末に Authelia を立ち上げる
• 本番で使う前に、どの設定を見直すべきかを知る

##Authelia とは

Authelia は Apache License 2.0 で公開されているオープンソースのソフトウェアです。公式リポジトリによると、Docker や Kubernetes のコンテナとして動かせるほか、静的バイナリ、.deb パッケージ、APT、AUR、FreeBSD Ports からも入れられます。Kubernetes 向けには Helm チャート（ベータ）もあります。

##仕組み

リバースプロキシは、届いたリクエストを通す前に、毎回 Authelia に「このリクエストを通してよいか」を問い合わせます。初めて来たユーザーはセッション Cookie を持っていないので、Authelia はそのユーザーを自分のログイン画面へ転送させます。ログインに成功すると、守っているドメインのサブドメイン全体で使えるセッション Cookie が発行されます。次に同じサイトへ来たときは、プロキシがその Cookie を Authelia に渡し、Authelia が確認できればリクエストを通します。Authelia はアプリ本体とは直接つながらず、Authorization ヘッダーのような認証に関わる部分だけを受け取ります。そのため、守る対象は REST でも GraphQL でも、HTTP の上で動くものなら構いません。

##Authelia でできること

公式の README と設定ドキュメントは、主な機能として次のものを挙げています。

• 2 つ目の要素：FIDO2 WebAuthn のセキュリティキー（YubiKey など）、認証アプリのワンタイムパスワード（TOTP）、Duo を使ったスマートフォンへのプッシュ通知
• パスワードなしのログイン：WebAuthn（パスキー）でログインできます。
• 細かいアクセス制御：サブドメイン、ユーザー、グループ、リクエストの URI やメソッド、接続元のネットワークを条件にルールを書き、bypass・one_factor・two_factor・deny のどれを適用するかを決めます。
• OpenID Connect 1.0 / OAuth 2.0：Authelia 自身が ID プロバイダーになれます。README によると OpenID Certified を取得していますが、公式ロードマップ上はまだベータの扱いです。なお、アクセス制御のルールは OpenID Connect には効きません。
• ログイン試行の制限（regulation）：ユーザー名とパスワードの失敗が続くと、アカウントや接続元 IP を一時的に締め出します。既定値は「2 分間に 3 回失敗したら 5 分間禁止」です。
• パスワードのリセット：メールで本人確認をしてからリセットできます。

##対応するリバースプロキシ

公式のサポート表には、導入ガイド付きで次のプロキシが載っています。Traefik、Caddy、Envoy、NGINX、NGINX Proxy Manager、SWAG、HAProxy、Skipper です。Traefik 1.x は旧版扱いです。細かい対応状況は公式の Supported Proxies で確認してください。

##安全な試し方：local バンドルを手元で動かす

公式は、設定に悩まず試すための「local」バンドルを用意しています。インターネットに公開しない前提のもので、ドメインは hosts ファイルに書き、自己署名証明書を使います。自分の Linux デスクトップか、検証用の VM で試しましょう。

1. Docker と Docker Compose を入れておきます。

2. リポジトリを取得し、最新のリリースに切り替えます。

   git clone https://github.com/authelia/authelia.git
   cd authelia
   git checkout $(git describe --tags `git rev-list --tags --max-count=1`)

3. local バンドルのフォルダーに移り、セットアップを実行します。途中で sudo を使って /etc/hosts を書き換えます。

   cd examples/compose/local
   ./setup.sh

4. ブラウザーで次の 3 つを開き、違いを確かめます（example.com は手順 3 で指定したドメインに置き換わります）。自己署名証明書なので、それぞれ警告を承認します。

2 要素の端末を登録するときは、確認メールのリンクを開きます。デモでは実際のメールは送られず、内容は ./authelia/notification.txt に保存されます。

##本番で守ること

• HTTPS は必須です。 公式は、テストでも https で提供することを求めています。Cookie を使う都合上、守るアプリ側もすべて https と wss で通信させます。
• 設定ファイルを先に作ります。 公式の Get started は、jwt_secret、authentication_backend（LDAP か YAML ファイル）、storage、session、notifier、access_control を最初に決める項目として挙げています。アクセス制御のドキュメントは、default_policy を deny にするよう勧めています。
• ストレージの暗号鍵を守ります。 storage.encryption_key はデータベース内の機密値を暗号化する鍵です。最短 20 文字ですが、64 文字以上のランダムな英数字が強く勧められています。
• シークレットはファイルで渡します。 jwt_secret やセッションの secret などは、AUTHELIA_JWT_SECRET_FILE のように _FILE で終わる環境変数でファイルから読ませる方法が推奨されています。同じ値を設定ファイルと二重に書くと Authelia は起動しません。
• 本番向けの保存先を選びます。 ストレージは SQLite3 がテストと小規模向け、PostgreSQL が本番向け、セッションには Redis、通知には SMTP が勧められています。
• バンドルの初期値を変えます。 lite バンドルの users_database.yml には、初期パスワードが authelia のユーザーが入っています。公開する前に必ず変えてください。
• 他人のサービスの前に勝手に置いたり、許可のないサイトで試したりしないでください。

##Keycloak との違い

Keycloak は管理コンソールでユーザーやアプリを管理でき、OpenID Connect と OAuth 2.0 に加えて SAML 2.0 にも対応します。Authelia はリバースプロキシと組んで入口を守る使い方が中心で、設定はファイルに書き、ユーザーは LDAP か YAML ファイルから読み込みます。

##次に読む

• cd ../keycloakKeycloakユーザー管理や外部 ID 連携までまとめて扱う認証・認可サーバー
• cat ~/guides/lab-setup.md安全な検証環境の作り方