認証ポータルのログインやトークン更新、プロフィール、管理APIを利用するHTTPクライアントの仕様確認とトラブル対応を支援します。
- ポータル向けJSONログインを実装したいとき
- ブラウザーのトークン更新を調べたいとき
- ネイティブ認証APIを扱いたいとき
Caddyでローカル・LDAPのパスワード認証ストアを設定し、データベースや接続先、TLS信頼、グループとロールの対応を整えるスキルです。
Configure local, LDAP or SQLite password identity stores, trusted SQLite administration, realms, databases, binds, TLS trust and group mappings. Delegates static local entries to configuration-users.
実行スコア 未検証
インストール方法を見るCaddyのlocal identity storeとldap identity storeを設定し、認証ポータルが使うパスワードアカウントの保存先を整えます。ローカルストアではrealmやユーザーデータのパスを指定し、LDAPではサーバー、検索範囲、サービスアカウント、ユーザー属性、グループとロールの対応などを設定します。LDAPSの証明書信頼や自動グループマッピング、認証時の検索・バインドの流れも確認できます。静的ユーザー登録やパスワード取り込みは、別スキルconfiguration-usersの担当です。
ポータル用のローカルアカウントを保存したいときや、社内ディレクトリをログイン元として使いたいときに役立ちます。LDAP接続はできてもロールが付かない、証明書検証に失敗する、ユーザー検索条件が合わないといった設定の見直しにも使えます。
LDAP接続にはディレクトリ情報とバインド資格情報が必要です。LDAPSでは信頼するCA証明書を設定し、ignore_cert_errorsに頼らない構成が案内されています。ローカル管理者の初期設定には環境変数を利用できます。
この紹介文は、公開されている SKILL.md をもとに AI(OpenAI Codex)が作成しました。正確な仕様は下の原文を確認してください。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Use this skill to configure local identity store <name> and
ldap identity store <name> blocks. The dispatcher is caddyfile_identity.go;
the store parser is caddyfile_identity_store.go.
Use configuration-users to configure static
user <username> entries, password imports, API keys, and stored challenge rules.
For password verification, credential versions, management/profile mutations,
reload invalidation, and Caddy qualification, read
local identity compatibility.
Check github.com/greenpau/go-authcrunch/pkg/ids when changing this skill:
ids.IdentityStoreConfig.Validate admits only local and ldap stores and
validates the authcrunch parameter names produced by the Caddyfile parser.
For SQLite password accounts and trusted offline administration, read SQLite identities. The bundled module uses root runtime injection and preserves its own kind, epoch and password-only capabilities. The separate SQLite API-key authenticator does not create portal password accounts.
Local stores require realm and path in the authcrunch config. The full
Caddyfile form is:
{
security {
local identity store localdb {
realm local
path assets/config/users.json
}
}
}
The local shortcut is valid and sets realm local plus the user file path.
Only local stores support this shortcut:
local identity store localdb assets/config/users.json
Add users inline only when the Caddyfile should own the local account data:
user alice {
name "Alice Example"
email alice@example.com
password {env.ALICE_PASSWORD} overwrite
roles authp/user authp/admin
}
Local store-level options supported by authcrunch are login_icon,
username_recovery_enabled, password_recovery_enabled,
contact_support_enabled, support_link, and support_email. In Caddyfile,
set those with icon, enable username recovery, enable password recovery,
enable contact support, support link, and support email.
Authcrunch creates a missing local database and bootstraps an administrative user whenever the loaded database has no administrator, including an existing database. Configure the bootstrap password explicitly before first startup: the selected library logs the created username, email and roles, but does not log the generated password. These environment variables set the account:
AUTHP_ADMIN_USER
AUTHP_ADMIN_EMAIL
AUTHP_ADMIN_SECRET
The local database stores password and username policy fields. The default
password policy requires length 8-128, and the default username policy requires
length 3-50. Users with non-guest portal access can change their password from
the portal profile/settings UI; administrators can reset passwords and manage
users through security local
or authdbctl. These commands use the running portal's admin API.
LDAP stores require realm and servers at config-validation time. At
provisioning time authcrunch also needs bind credentials, search_base_dn, and
either explicit groups or automatic group mapping. Use this practical shape:
ldap identity store corp {
realm corp.example.com
servers {
ldaps://ldap.example.com
}
trusted_authority /etc/caddy/ldap/corp-ca.pem
username "CN=authsvc,OU=Service Accounts,DC=example,DC=com"
password {env.LDAP_BIND_PASSWORD}
search_base_dn "DC=example,DC=com"
search_user_filter "(&(|(sAMAccountName=%s)(mail=%s))(objectclass=user))"
attributes {
name givenName
surname sn
username sAMAccountName
member_of memberOf
email mail
}
groups {
"CN=Admins,OU=Groups,DC=example,DC=com" authp/admin
"CN=Users,OU=Groups,DC=example,DC=com" authp/user
}
}
Use these Caddyfile-to-authcrunch aliases deliberately:
username becomes bind_username; do not write bind_username in Caddyfile.password becomes bind_password; if omitted, authcrunch falls back to
LDAP_USER_SECRET during provisioning.search_filter is a legacy alias for search_user_filter; prefer
search_user_filter for clarity when adding new examples.attach to local identity store <name> sets attachment.local_identity_store
(LDAP only).trusted_authority <path> appends to authcrunch trusted_authorities.icon becomes login_icon.LDAP server addresses must start with ldap:// or ldaps://. Authcrunch uses
default ports 389 and 636, or a port in the URL, and defaults timeout to 5
seconds; the Caddyfile parser currently exposes only ignore_cert_errors and
posix_groups server flags.
Prefer trusted_authority <path> for LDAPS trust over ignore_cert_errors.
When collecting a server certificate chain for trust configuration, use
openssl s_client -showcerts against the LDAPS endpoint, split the PEM
certificates, verify the intended CA against the directory operator's trust
material, and point trusted_authority at those CA files. A certificate
retrieved from the endpoint alone does not establish trust in that endpoint.
If search_user_filter, search_group_filter, or attributes are omitted,
authcrunch defaults to Active Directory-style values:
sAMAccountName/mail, memberOf, givenName, sn, and
(&(uniqueMember=%s)(objectClass=groupOfUniqueNames)). Override them for POSIX
or non-AD directories.
Group mapping rules:
groups { <group_dn> <role> [<role>...] } for explicit LDAP DN to role
mappings.enable short automatic group mapping to map group DNs to the lower-case
first RDN value, such as ou=mathematicians,... to mathematicians.enable full automatic group mapping to map group DNs to lower-case full
DN roles.posix_groups on a server when group membership must be found through
search_group_filter instead of the user's member_of attribute.fallback_roles for roles assigned when the user
authenticates but no LDAP group mapping produced roles. It does not replace
the requirement for explicit or automatic group mapping to configure LDAP.fallback role authp/user or fallback roles authp/user directory/member
inside an LDAP store. All supplied roles survive adaptation; repeating the
directive replaces the list. Local stores reject this LDAP-only setting.
TestIdentityStoreFallbackRoles checks typed mapping; the LDAP journey in
TestCaddyAuthenticationChallengesE2E verifies a real service bind, user bind,
signed role claims and protected route over disposable verified LDAPS/TLS.Runtime LDAP authentication flow:
search_user_filter, and searches under search_base_dn.Connections are closed after each operation; identification and password verification do not share a long-lived connection.
Verified LDAP subjects also receive an attached local identity,
using private memory when no explicit attachment is supplied. The native
password-sandbox flow signs amr: ["federated", "pwd"]; the federation marker
does not prove a separate local password or MFA factor. The LDAPS fallback-role
E2E verifies this exact signed evidence and protected-resource access. Explicit
LDAP attachment uses attach to local identity store <name> once in the LDAP
block. The complete clause is validated by the shared attachment parser;
duplicates, nested blocks and local-store declarations of attach fail.
The exact name may resolve once from an environment or secrets reference in the
private runtime Params snapshot. A nonempty reference resolving to empty fails;
native empty attachments retain private memory. Read
attached identities and connection for target
selection, durable UUIDs, local-factor policy and browser-only connection.
This flow means a correct-looking Caddyfile can still fail because the search filter is too broad, group membership does not map to any role, LDAPS trust is missing, or service bind credentials are wrong.
Supported store-level options include:
disabledrealm, path, search_base_dn, search_group_filter,
search_user_filter, search_filter, username, and passwordattach to local identity store <name> (LDAP only)trusted_authority <path>attributes { <local_name> <remote_name> }servers { <ldap_url> [ignore_cert_errors] [posix_groups] }groups { <group_dn> <role> [<role>...] }enable username recovery, enable password recovery,
enable contact supportenable full automatic group mapping and
enable short automatic group mappingsupport link <url> and support email <address>icon <text> ...Do not invent raw authcrunch JSON field names as Caddyfile directives unless
the parser accepts them. In particular, Caddyfile uses username, password,
trusted_authority, and search_filter/search_user_filter, while the
adapted authcrunch config stores bind_username, bind_password,
trusted_authorities, and search_user_filter.
After defining a store, enable it from an authentication portal:
authentication portal myportal {
enable identity store localdb corp
}
Use these examples:
caddyfile_identity_test.go.caddyfile_identity_store_test.go.testdata/caddyfile_adapt/testcase_security_authentication_portal.Caddyfile.TestIdentityAttachment*, TestAppIdentityProviderAttachment* and
testcase_identity_attachments cover parser, target, snapshot and ownership
boundaries. TestCaddyConnectedProvidersE2E covers explicit LDAP attachment,
current local policy and connected identity through verified LDAPS/Caddy.
The LDAP journey in ldap_fallback_e2e_test.go, invoked by
TestCaddyAuthenticationChallengesE2E, checks verified LDAPS, fallback role
claims and a protected route. It does not qualify every directory schema,
POSIX group lookup, or production CA configuration. For those changes, verify
exactly-one-user selection, explicit and automatic mapping, unmapped-user
rejection or fallback, wrong-password rejection and trust failures against a
disposable directory before claiming login compatibility.
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
認証ポータルのログインやトークン更新、プロフィール、管理APIを利用するHTTPクライアントの仕様確認とトラブル対応を支援します。
Caddyの認証・認可まわりで起きた設定や実行時の障害を、設定ファイル、ログ、バージョン、HTTPの証拠から切り分け、最小修正や調査報告にまとめます。
caddy-securityのGoコードやCaddyモジュール、Caddyfileパーサー、HTTP連携の実装・レビューで、境界やライフサイクル、エラー処理の規約を確認するスキルです。
caddy-securityのCaddyfile全体を作成・点検し、認証方式に合う設定ガイドを選びながらsecurityアプリとHTTPルートを配線するスキルです。
Caddyの認証ポータルとルートへの認証処理を設定し、利用するログイン元やリダイレクト先の信頼条件、更新機能などを組み立てるスキルです。
認証ポータルのCookie名や接頭辞、属性、ドメインを設定し、認可ポリシーが探すトークンCookieとの対応を整えます。