認証¶

ユーザー登録¶

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

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

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

認証バックエンド¶

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

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

参考

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

Teams from identity providers¶

Added in version 2026.10.1.

Weblate can synchronize selected teams from external group memberships or application roles during social authentication. The default native and Docker pipelines include synchronization after authentication checks and two-factor authentication. Extraction and assignment are disabled until configured. If you use a custom authentication pipeline, place social_core.pipeline.user.sync_groups after all authentication checks, including weblate.legal.pipeline.tos_confirm when terms acceptance is enabled.

Map external identifiers to lists of existing Weblate team IDs. Find team IDs in the administration interface URL or the teams REST API. Names can repeat across project and workspace scopes, so they are not used as mapping targets.

For Microsoft Entra ID, prefer application roles:

SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_GROUPS_KEY = "roles"
SOCIAL_AUTH_AZUREAD_TENANT_OAUTH2_GROUPS_MAP = {
    "Weblate.Translator": [42],
    "Weblate.Reviewer": [43],
}

Configure the provider to issue these roles. Group identifiers can instead be selected with GROUPS_KEY = "groups". Group overage causes authentication to fail; Weblate does not retrieve memberships from Microsoft Graph. Restrict the trusted tenant and issuer before granting permissions, especially when using a common Azure endpoint.

For generic OpenID Connect or Keycloak, configure a literal claim name:

SOCIAL_AUTH_OIDC_GROUPS_KEY = "groups"
SOCIAL_AUTH_OIDC_GROUPS_MAP = {"translators": [42]}

SOCIAL_AUTH_KEYCLOAK_GROUPS_KEY = "groups"
SOCIAL_AUTH_KEYCLOAK_GROUPS_MAP = {"/organization/reviewers": [43]}

For GitLab, explicitly enable membership retrieval:

SOCIAL_AUTH_GITLAB_GROUPS_ENABLED = True
SOCIAL_AUTH_GITLAB_GROUPS_MAP = {"organization/translators": [42]}

Enabling retrieval automatically requests read_api unless read_api or api is already requested. Enable the corresponding permission in the GitLab OAuth application settings alongside read_user.

GitLab uses full group paths by default. Use stable numeric group IDs instead when paths might change or be reused:

SOCIAL_AUTH_GITLAB_GROUPS_IDENTIFIER = "id"
SOCIAL_AUTH_GITLAB_GROUPS_MAP = {"12345": [42]}

For SAML, add the group attribute and mapping to each existing entry in SOCIAL_AUTH_SAML_ENABLED_IDPS:

SOCIAL_AUTH_SAML_ENABLED_IDPS["company"].update(
    {
        "attr_groups": "https://example.com/claims/groups",
        "groups_map": {"translators": [42]},
        "allow_groups": ["translators", "reviewers"],
    }
)

All targets in a mapping become provider-managed teams. Authentication adds desired memberships and removes obsolete managed memberships. Unrelated teams and existing membership language restrictions are preserved. Changes are recorded in the audit log. Manual membership in a managed team is subject to replacement at the next authentication. A team may be managed by only one configured provider or SAML IdP; conflicting mappings and nonexistent teams cause errors before memberships change. No teams are created automatically.

A missing configured claim fails authentication. When a provider omits claims for users without assignments, explicitly enable its SOCIAL_AUTH_<BACKEND>_GROUPS_MISSING_AS_EMPTY setting. SAML uses groups_missing_as_empty in the IdP entry. An empty membership list removes all provider-managed memberships. An empty GROUPS_MAP disables assignment.

Login restrictions are independent of assignment. Configure SOCIAL_AUTH_<BACKEND>_ALLOW_GROUPS to require membership in any listed external group or role. Unknown identifiers grant nothing, but do not reject login unless an allow list is configured. Existing CAS allow lists require no new settings or pipeline entries.

Synchronization applies to login, registration, and authentication-method linking. Password reset and account removal do not synchronize teams. Updates occur only during authentication; this does not deactivate accounts or revoke access in the background. Synchronization does not store external membership snapshots.

In Docker installations, use 環境変数以外の設定 to supply these Python settings; there are no dedicated environment variables for team mappings.

参考

External groups

パスワード認証¶

デフォルトの 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（永続）を選択してください。

ヒント

一部のIDプロバイダー（多要素認証を備えた Microsoft Entra ID など）は、SAMLセキュリティ設定のデフォルト値 requestedAuthnContext を無効にする必要があります：

SOCIAL_AUTH_SAML_SECURITY_CONFIG = {"requestedAuthnContext": False}

Dockerでは、代替として WEBLATE_SAML_SECURITY_CONFIG を設定してください。

ヒント

上記の例と 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 認証情報であり、ユーザーの存在のみを検証します。

When signing in on a new computer or in a different browser, your passkey might not be available. Use a device where the passkey is available, or connect your registered security key. A verification error can mean that the request timed out, was canceled, or that the credential is unavailable; it does not identify the exact cause.

You can also select another configured verification method on the sign-in page, such as Use recovery codes. If you cannot use any configured method, contact the site administrator for help.

認証アプリ（TOTP）

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

Registration becomes active only after you verify a code from the app. Complete registration within 24 hours; otherwise start again with a new QR code. Each registration can be completed only once. After registering, wait for the next code before using the app to sign in.

Only one registration can be pending per account. Opening registration in another browser session shows the same QR code until registration is completed or expires.

If you have more than one registered authenticator app, select the app you are using when entering its code during sign-in.

回復コード

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

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

Each user can configure this in セキュリティ and second factor will be required to sign in addition to the existing authentication method.

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

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

認証¶

ユーザー登録¶

認証バックエンド¶

Teams from identity providers¶

ソーシャル認証¶

Authentication storage cleanup¶

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 認証の設定¶