Security, Access Control and Authentication
Security, Access Control and Authentication
This domain tests how identities authenticate, how permissions are granted on repository paths, and how to avoid over-privileged access.
Core rules
- Authentication realms include local users, LDAP, SAML, OIDC, Crowd, and HTTP SSO. Users can belong to groups; groups are the scalable unit for permissions. SCIM can provision users and groups from an identity provider.
- A permission target binds repositories and path patterns to principals (users or groups) with roles. Repository path patterns use
**and*; include patterns grant access, and exclude patterns carve out sensitive paths. - Roles include read, annotate, deploy, delete, and manage. Permissions are additive across targets and groups; there is no explicit deny that overrides a grant.
- Anonymous access is a global setting. Disable it unless a repository is deliberately public. Admin users bypass permission checks, so protect admin group membership.
- Tokens and API keys are credentials. Prefer short-lived access tokens for automation; rotate and revoke compromised credentials.
Worked example
A team needs to read libs-release-local under com/acme/** but must not read com/acme/secrets/**. Create a permission target for libs-release-local with include com/acme/**, exclude com/acme/secrets/**, and assign the group acme-readers the Read role. Add deployment only through a separate target with Deploy on com/acme/releases/** for the CI group. If a user is in both groups, they get the union: read on the broad path and deploy on the narrow path. The exclude still removes the secrets subtree from the broad read grant.
Traps
Granting Manage broadly to avoid 403 errors. Assuming a permission target on a virtual repository automatically grants direct access to its underlying local repositories. Using a user-level grant when a group would scale. Assuming an LDAP group is available before the realm syncs it. Leaving anonymous access on after a proof of concept.