Checkpoint Lab — Users, Groups, Permissions, Tokens, Authentication, and Authorization

1. Checkpoint scenario

You administer a disposable local SonarQube instance used by two synthetic teams, Alpha and Beta. Each team should browse/source-view/analyze only its own private project. Neither routine user is an administrator. CI uses project-analysis tokens; read-only API verification uses limited user tokens.

Your task is to prove the matrix, intentionally expose one broader inherited permission, repair it, prove revocation, and restore the initial server state.

2. Exact assumptions and prerequisites

3. Write the intended RBAC matrix before configuration

Also record the actual initial global Execute Analysis state for sonar-users. The desired final rollback state is whatever you observed initially—not what you remember the default to be.

4. Predictions before mutation

• Prediction A: while sonar-users still has global Execute Analysis, both authenticated users may be able to analyze either project despite narrow project templates.
• Prediction B: after removing that global grant in the disposable lab, Alpha will analyze Alpha but not Beta; Beta will analyze Beta but not Alpha.
• Prediction C: Alpha’s limited user token will read Alpha’s private measures but will not gain Beta Browse permission.
• Prediction D: revoking Alpha’s project-analysis token will make the same Alpha scan fail without changing source, project key, gate, profile, or template.
• Prediction E: restoring the original global grant during cleanup changes authorization state but does not rewrite earlier analysis/task evidence.

5. Setup and preflight evidence

1. Capture server/scanner versions.
2. Capture Global Permissions, Users, Groups, Permission Templates, and default visibility.
3. Create the two local users/groups and record memberships.
4. Create Alpha/Beta permission templates with key regexes and project grants.
5. Create the two private projects and verify template assignment.
6. Create source fixtures and record Git SHAs.
7. Create short-lived project-analysis and user tokens under the limited users.

mkdir -p evidence/ch21/{preflight,alpha,beta,deny,revocation,rollback}
curl -fsS "$SONAR_HOST_URL/api/system/status" > evidence/ch21/preflight/system-status.json
sonar-scanner --version 2>&1 | tee evidence/ch21/preflight/scanner-version.txt
printf 'alpha_sha=%s\n' "$(git -C sq-ch21-rbac/alpha rev-parse HEAD)" > evidence/ch21/preflight/revisions.txt
printf 'beta_sha=%s\n' "$(git -C sq-ch21-rbac/beta rev-parse HEAD)" >> evidence/ch21/preflight/revisions.txt

6. Execute the allow/deny proof

Run these evidence cases without changing the source revisions:

7. Deliberate mistake: prove the default global grant can defeat isolation

If the initial state had global Execute Analysis on sonar-users, preserve one cross-team scan result before removing it. That is the deliberate broken state. Record:

• Alpha’s membership in sonar-users;
• the global Execute Analysis grant;
• absence of Alpha’s Beta project-level grant;
• the surprising successful cross-team scan.

Then remove only that global grant, rerun the same revision/project/token pair, and preserve the denial. This is a causal authorization experiment.

8. Revoke and independently verify

Revoke Alpha’s project-analysis token. Repeat Alpha→Alpha scan and require nonzero exit. Revoke Alpha’s user token. Repeat the read-only Alpha API request and preserve the authentication failure/validation result.

revocation record:
  owner: sq21-alpha
  token type: project analysis / user
  associated project (if applicable): sq-ch21-alpha-app
  expiration originally selected:
  revoke timestamp:
  known consumers updated/removed:
  post-revoke verification command:
  post-revoke result:
  token value: NEVER RECORDED

9. Required evidence packet

10. Verification checklist

• ☐ Neither sample user is in sonar-administrators.
• ☐ Alpha and Beta permissions originate from intended groups/templates, not undocumented direct grants.
• ☐ Private visibility is independently verified.
• ☐ Global Execute Analysis initial and modified states are preserved.
• ☐ Positive and negative analysis tests were executed at exact recorded SHAs.
• ☐ ceTaskId is preserved for successful analyses.
• ☐ API evidence distinguishes authentication from authorization/resource visibility.
• ☐ Token values never appear in source, logs, screenshots, or evidence notes.
• ☐ Revoked credentials are proven unusable.
• ☐ Cleanup restores the original global permission.

11. Cleanup and rollback

1. Export the evidence packet.
2. Revoke remaining Chapter 21 credentials.
3. Restore the original sonar-users Execute Analysis state exactly.
4. Remove only the Chapter 21 disposable projects/templates/groups/users.
5. Unset environment variables and remove the local synthetic source tree if no longer needed.
6. Do not touch database/search state, global quality policy, external IdP configuration, or unrelated projects.

12. What Chapter 21 adds to the production operating model

The SonarQube control plane now includes a replayable identity chain: who authenticated, which groups/direct grants produced the effective permission, which project/global boundary applied, which token represented that identity, which analysis task resulted, and when access was revoked. Routine analysis no longer depends on administrator credentials.

Chapter 22 continues with SAML, LDAP, OIDC/SSO, Proxies, TLS, and Network Security, moving identity ownership from local accounts/groups toward enterprise authentication and network trust boundaries.

Knowledge check

Official references and version notes

• Managing permissions — Community Build — current global/project permissions, default sonar-users Execute Analysis grant, visibility, and permission templates.
• Managing groups — additive direct/group permission model and built-in groups.
• Managing your tokens — user/project/global analysis token types, expiration, revocation, and owner-permission dependency.
• Administering tokens — administrator generation/revocation responsibilities.
• User accounts — built-in/delegated authentication and forced-authentication guidance.
• Web API — bearer authentication, token-expiration response header, form-data guidance, and Web API V2 transition.
• Current SonarQube downloads — Community Build 26.9.0.129388 baseline.
• SonarScanner CLI 8.1.0.6389 — scanner baseline used by the local analysis proofs.