認証¶

ユーザー登録¶

Weblate のデフォルトの設定では、新規ユーザーの登録を処理するために Web サイト上のフォームである python-social-auth を使用します。メールを確認すると、新規ユーザーはサードパーティのサービスを利用して協力したり認証したりできます。

新規ユーザーの登録は、REGISTRATION_OPEN を使用して無効にもできます。

認証の試行は、接続制限の対象です。

認証バックエンド¶

Weblate は認証に Django を使用しています。これには、Django に標準で備わっているパスワード認証、ソーシャル認証、および Django 用のサードパーティ製認証バックエンドが含まれます。

Django の組み込み認証機能を使用することで、他の Django ベースのプロジェクトのユーザーデータベースをインポートすることができます（参照: Pootle から移行）。

参考

認証設定で、 Docker の公式イメージで認証を設定する方法を説明します。

パスワード認証¶

デフォルトの settings.py には、脆弱なパスワードを許可しないように設計された、適切な AUTH_PASSWORD_VALIDATORS の設定が含まれています。この設定は、あなたのパスワードポリシーに合わせてカスタマイズできます。

さらに django-zxcvbn-password-validator もインストールできます。これは、入力されたパスワードの難易度をかなり正確に計算できるので、一定のしきい値以下のパスワードを拒否することができます。

参考

SAML 認証¶

Added in version 4.1.1.

バージョン 5.12 で変更: SAML 認証に必要な依存パッケージは、デフォルトの all extras には含まれなくなりました。Weblate パッケージを pip でインストールする際は、saml を明示的に含めることが必要です（例: uv pip install Weblate[all,saml]）。

設定については、Python Social Auth の手順に従ってください。注意が必要な違い:

Weblate は単一の IDP のみに対応しており、SOCIAL_AUTH_SAML_ENABLED_IDPS ではその IDP 名を Weblate として設定することが必要です。
SAML の XML メタデータ URL は /accounts/metadata/saml/ であり、これはエンティティ ID としても使用されます。
サインイン URL は /accounts/complete/saml/ （ACS URL とも呼ばれます）。
自動的に入力される設定項目: SOCIAL_AUTH_SAML_SP_ENTITY_ID, SOCIAL_AUTH_SAML_TECHNICAL_CONTACT, SOCIAL_AUTH_SAML_SUPPORT_CONTACT

設定例:

# Authentication configuration
AUTHENTICATION_BACKENDS = (
    "social_core.backends.email.EmailAuth",
    "social_core.backends.saml.SAMLAuth",
    "weblate.accounts.auth.WeblateUserBackend",
)

# Social auth backends setup
SOCIAL_AUTH_SAML_SP_ENTITY_ID = f"https://{SITE_DOMAIN}/accounts/metadata/saml/"
SOCIAL_AUTH_SAML_SP_PUBLIC_CERT = "-----BEGIN CERTIFICATE-----"
SOCIAL_AUTH_SAML_SP_PRIVATE_KEY = "-----BEGIN PRIVATE KEY-----"
SOCIAL_AUTH_SAML_ENABLED_IDPS = {
    "weblate": {
        "entity_id": "https://idp.testshib.org/idp/shibboleth",
        "url": "https://idp.testshib.org/idp/profile/SAML2/Redirect/SSO",
        "x509cert": "MIIEDjCCAvagAwIBAgIBADA ... 8Bbnl+ev0peYzxFyF5sQA==",
    }
}
SOCIAL_AUTH_SAML_ORG_INFO = {
    "en-US": {
        "name": "example",
        "displayname": "Example Inc.",
        "url": "http://example.com"
    }
}
SOCIAL_AUTH_SAML_TECHNICAL_CONTACT = {
    "givenName": "Tech Gal",
    "emailAddress": "technical@example.com"
}
SOCIAL_AUTH_SAML_SUPPORT_CONTACT = {
    "givenName": "Support Guy",
    "emailAddress": "support@example.com"
}

新しい鍵ペアを生成するコマンド:

openssl req -newkey rsa:4096 -new -x509 -days 3652 -nodes -out saml.crt -keyout saml.key

デフォルトの構成では、以下の属性からユーザーの詳細が抽出されます。下記を提供するように IdP を設定:

属性	SAML 参照 URI
フルネーム	`urn:oid:2.5.4.3`
名前 (名)	`urn:oid:2.5.4.42`
姓	`urn:oid:2.5.4.4`
メールアドレス	`urn:oid:0.9.2342.19200300.100.1.3`
ユーザー名	`urn:oid:0.9.2342.19200300.100.1.1`

IdP（アイデンティティプロバイダー）で Weblate のサービスプロバイダー（SP）を構成する際は、Name ID format で persistent（永続）を選択してください。

ヒント

上記の例と Docker イメージは、weblate と呼ばれる IdP（アイデンティティプロバイダー）を定義しています。IdP で、この文字列を Relay に設定してください。

注釈

Weblate の認証処理では、RelayState パラメーターが認証フローを通じて渡される必要があります。一部のアイデンティティプロバイダー（IdP）で必要なパラメーターの設定:

Okta を使用してカスタム RelayState を送信する方法

参考

LDAP 認証¶

LDAP認証は、django-auth-ldap パッケージを使用することが最適です。通常のインストール方法:

# Using PyPI
uv pip install 'django-auth-ldap>=1.3.0'

# Using apt-get
apt-get install python-django-auth-ldap

ヒント

このパッケージは、Docker コンテナに含まれています。参照: Docker を使用したインストール。

注釈

Python LDAP 3.1.0 モジュールは一部に互換性がなく、そのバージョンは使用できないことがあります。エラー AttributeError: 'module' object has no attribute '_trace_level' が発生した場合は、python-ldap を 3.0.0 にダウングレードしてみてください。

パッケージのインストール後に、Django 認証にフックする方法:

# Add LDAP backed, keep Django one if you want to be able to sign in
# even without LDAP for admin account
AUTHENTICATION_BACKENDS = (
    "django_auth_ldap.backend.LDAPBackend",
    "weblate.accounts.auth.WeblateUserBackend",
)

# LDAP server address
AUTH_LDAP_SERVER_URI = "ldaps://ldap.example.net"

# DN to use for authentication
AUTH_LDAP_USER_DN_TEMPLATE = "cn=%(user)s,o=Example"
# Depending on your LDAP server, you might use a different DN
# like:
# AUTH_LDAP_USER_DN_TEMPLATE = 'ou=users,dc=example,dc=com'

# List of attributes to import from LDAP upon sign in
# Weblate stores full name of the user in the full_name attribute
AUTH_LDAP_USER_ATTR_MAP = {
    "full_name": "name",
    # Use the following if your LDAP server does not have full name
    # Weblate will merge them later
    # 'first_name': 'givenName',
    # 'last_name': 'sn',
    # Email is required for Weblate (used in VCS commits)
    "email": "mail",
}
# Optional: route "Forgot your password?" to your LDAP self-service page
PASSWORD_RESET_URL = "https://id.example.net/password-reset/"


# Hide the registration form
REGISTRATION_OPEN = False

注釈

AUTHENTICATION_BACKENDS の設定から 'social_core.backends.email.EmailAuth' を削除してください。削除しなければ、ユーザーは Weblate でパスワードを設定すると認証できてしまいます。匿名ユーザーが簡単にログインできるアクセス権を作成するには、'weblate.accounts.auth.WeblateUserBackend' の設定を維持することが必要です。ローカル管理者アカウントが作成されている場合は、ローカル管理者アカウントを使用してサインインすることもできます（例: createadmin）。

バインドパスワードの使用¶

認証に直接バインドを使用できない場合は、検索を使用し、検索にバインドするユーザーを指定してください。ユーザーを指定する設定例:

import ldap
from django_auth_ldap.config import LDAPSearch

AUTH_LDAP_BIND_DN = ""
AUTH_LDAP_BIND_PASSWORD = ""
AUTH_LDAP_USER_SEARCH = LDAPSearch(
    "ou=users,dc=example,dc=com", ldap.SCOPE_SUBTREE, "(uid=%(user)s)"
)

Active Directory との連携¶

import ldap
from django_auth_ldap.config import LDAPSearch, NestedActiveDirectoryGroupType

AUTH_LDAP_BIND_DN = "CN=ldap,CN=Users,DC=example,DC=com"
AUTH_LDAP_BIND_PASSWORD = "password"

# User and group search objects and types
AUTH_LDAP_USER_SEARCH = LDAPSearch(
    "CN=Users,DC=example,DC=com", ldap.SCOPE_SUBTREE, "(sAMAccountName=%(user)s)"
)

# Make selected group a superuser in Weblate
AUTH_LDAP_USER_FLAGS_BY_GROUP = {
    # is_superuser means user has all permissions
    "is_superuser": "CN=weblate_AdminUsers,OU=Groups,DC=example,DC=com",
}

# Map groups from AD to Weblate
AUTH_LDAP_GROUP_SEARCH = LDAPSearch(
    "OU=Groups,DC=example,DC=com", ldap.SCOPE_SUBTREE, "(objectClass=group)"
)
AUTH_LDAP_GROUP_TYPE = NestedActiveDirectoryGroupType()
AUTH_LDAP_FIND_GROUP_PERMS = True

# Optionally enable group mirroring from LDAP to Weblate
# AUTH_LDAP_MIRROR_GROUPS = True

参考

CAS 認証¶

CAS 認証は、Django CAS NG などのパッケージを使用して実行できます。

ステップ 1、CAS 経由でユーザーのメールアドレスの入力フィールドを表示させます。これは、CAS サーバー自体に設定することが必要です。、CAS v 1 は属性に一切対応していないため、少なくとも CAS v 2 の実行が必要です。

ステップ 2、Weblate を更新して CAS サーバーと属性を使用します。

Django CAS NG のインストール方法:

uv pip install django-cas-ng

パッケージをインストールした後に、settings.py ファイルを変更して Django 認証システムに接続する設定方法:

# Add CAS backed, keep the Django one if you want to be able to sign in
# even without LDAP for the admin account
AUTHENTICATION_BACKENDS = (
    "django_cas_ng.backends.CASBackend",
    "weblate.accounts.auth.WeblateUserBackend",
)

# CAS server address
CAS_SERVER_URL = "https://cas.example.net/cas/"

# Add django_cas_ng somewhere in the list of INSTALLED_APPS
INSTALLED_APPS = (..., "django_cas_ng")

最後に、signal を使用してメールの入力フィールドをユーザーオブジェクトに設置できます。この機能を使用するには django-cas-ng パッケージから signal をインポートし、この signal を使用してコードに接続することが必要です。設定ファイルに設定すると問題が発生することがあります。推奨する設定方法:

アプリケーションの設定ファイル、django.apps.AppConfig.ready() メソッドの中に記述
プロジェクトファイル、 urls.py の中に記述（モデルが存在しない場合）

from django_cas_ng.signals import cas_user_authenticated
from django.dispatch import receiver


@receiver(cas_user_authenticated)
def update_user_email_address(sender, user=None, attributes=None, **kwargs):
    # If your CAS server does not always include the email attribute
    # you can wrap the next two lines of code in a try/catch block.
    user.email = attributes["email"]
    user.save()

サードパーティの Django 認証の設定¶

通常、Django 認証プラグインは Weblate で動作します。プラグインの指示に従い、Weblate user backend をインストールした状態にしておくことに注意が必要です。

参考

LDAP 認証
CAS 認証

通常の、認証バックエンドを AUTHENTICATION_BACKENDS に追加し、認証アプリケーション（存在する場合）を INSTALLED_APPS にインストールする方法:

AUTHENTICATION_BACKENDS = (
    # Add authentication backend here
    "weblate.accounts.auth.WeblateUserBackend",
)

INSTALLED_APPS += (
    # Install authentication app here
)

二要素認証¶

Added in version 5.7.

ヒント

二要素認証は、パスワードだけでなく、追加の認証要素を要求することでアカウントのセキュリティをより強固にします。

Weblate は次の二要素認証に対応しています。

セキュリティキー（WebAuthn）

パスキーと秘密鍵の両方に対応しています。

パスキーにはユーザー認証が含まれており、タッチ、顔認識、デバイスのパスワード、または PIN を使用して ID を検証します。

セキュリティキーは、認証の 2 番目の要素としてのみ使用できる WebAuthn 認証情報であり、ユーザーの存在のみを検証します。

認証アプリ（TOTP）

Aegis、Bitwarden、Google Authenticator、1Password、Authy、Microsoft Authenticator などの認証アプリやブラウザー拡張機能は、サインイン時に求められた場合に、あなたの身元を確認するための第二要素として使用する、ワンタイムパスワードを生成します。

回復コード

回復コードは、デバイスへのアクセスができない場合、または二要素認証コードを受け取ることができない場合、アカウントにアクセスするために使用します。

回復コードをパスワードと同じくらい安全な場所に保存してください。Bitwarden、1Password、Authy、または Keeper などのパスワードマネージャーに保存することをお勧めします。

各ユーザーは、これをアカウントで設定することができます。既存の認証方法に加えてサインインには 2 番目の要素が必要となります。

これは、プロジェクト（参照: 強制的な二要素認証）またはチーム単位でユーザーに適用できます。サイト全体の展開では、デフォルトのユーザーチームで有効化することで、すべてのユーザーに二要素認証を強制できます。このチームは自動チーム割り当てにより新規ユーザーに自動的に割り当てられます。

二要素認証を強制しているチームの権限は、それを設定していないユーザーには適用されません。

認証¶

ユーザー登録¶

認証バックエンド¶

ソーシャル認証¶

OpenID 認証¶

GitHub 認証¶

GitHub EE 認証¶

Bitbucket 認証¶

Google OAuth 2¶

Facebook OAuth 2¶

GitLab OAuth 2¶

Gitea OAuth 2¶

Microsoft Entra ID¶

Slack¶

認証方法の名前とアイコンの上書き¶

パスワード認証の無効化¶

パスワード認証¶

SAML 認証¶

LDAP 認証¶

バインド パスワードの使用¶

Active Directory との連携¶

CAS 認証¶

サード パーティの Django 認証の設定¶

二要素認証¶

バインドパスワードの使用¶

サードパーティの Django 認証の設定¶