Checkpoint Lab — SAML, LDAP, OIDC/SSO, Proxies, TLS, and Network Security

1. Checkpoint scenario

You are preparing a SonarQube instance for delegated authentication. Before any production IdP or public DNS change, you must prove the network/authentication contract locally. Your dossier must show:

1. where TLS terminates and how the backend is protected;
2. the external Server base URL and callback calculation;
3. trusted proxy headers;
4. one synthetic identity/group mapping;
5. the built-in LDAP/SAML versus optional OIDC/plugin boundary;
6. a tested local administrator recovery route;
7. one deliberate misconfiguration and causal repair;
8. explicit residual limitations.

2. Exact assumptions

3. Predictions before actions

• Prediction 1: HTTPS requests with the local certificate explicitly trusted will reach the same SonarQube system status as the HTTP backend.
• Prediction 2: the deliberate X-Forwarded-Proto=http proxy run will still be capable of reaching the API but will leave incorrect external-transport evidence in the proxy log.
• Prediction 3: a mismatched Server base URL/callback origin can be detected offline without a real IdP.
• Prediction 4: the local administrator remains usable after the proxy/SSO simulation because external identity was never made the only recovery path.

4. Execute the local proxy experiment

Reuse the certificate and proxy.py from Lesson 2. Preserve both the broken and corrected states:

mkdir -p evidence/{broken,fixed,identity}

# Broken forwarded protocol
python proxy.py http > evidence/broken/proxy.log 2>&1 &
echo $! > proxy.pid
sleep 1
curl --cacert localhost.crt -fsS \
  https://localhost:9443/api/system/status \
  | tee evidence/broken/system-status.json
kill "$(cat proxy.pid)"

# Correct forwarded protocol
python proxy.py https > evidence/fixed/proxy.log 2>&1 &
echo $! > proxy.pid
sleep 1
curl --cacert localhost.crt -fsS \
  https://localhost:9443/api/system/status \
  | tee evidence/fixed/system-status.json

grep 'FORWARD proto=' evidence/broken/proxy.log \
  | tee evidence/broken/forwarded-header.txt
grep 'FORWARD proto=' evidence/fixed/proxy.log \
  | tee evidence/fixed/forwarded-header.txt

The server result may be identical while the proxy evidence differs. Record that the defect existed at the network/trust boundary, not in the SonarQube database, rules, users, or projects.

5. Prove the external origin contract

external_url=https://localhost:9443
server_base_url=https://localhost:9443
saml_reply_url=https://localhost:9443/oauth2/callback/saml
proxy_host=localhost:9443
proxy_forwarded_proto=https

Now deliberately set the offline server_base_url record to https://localhost:9444, run the Lesson 4 origin validator, preserve its assertion failure, restore 9443, and preserve the passing output. This is the checkpoint’s required deliberate configuration failure.

6. Required trust-boundary diagram

flowchart LR
  B[Browser] -->|HTTPS + validated cert| RP[Loopback reverse proxy :9443]
  RP -->|HTTP trusted backend| SQ[SonarQube :9000]
  SQ -. fake SAML contract .-> IDP[Synthetic IdP metadata]
  IDP -. identity + groups .-> SQ
  SQ --> GRP[Existing SonarQube groups]
  GRP --> PERM[Global / project permissions]
  A[Local recovery admin] --> SQ
  SC[Scanner / CI token path] -->|separate authentication| RP

Annotate the real production design separately if it differs. Do not pretend the local Python proxy is production architecture.

7. Synthetic identity/group validation

{
  "identity_provider": "fake-saml",
  "login": "alice-lab",
  "display_name": "Alice Lab",
  "email": "alice@example.invalid",
  "groups": ["sq-ch22-developers"],
  "forbidden_groups": ["sonar-administrators"]
}

Run the offline claim validator and store the output in evidence/identity/claims-validation.txt. Then write a short mapping note explaining which SonarQube permissions the sq-ch22-developers group would receive and which privileged permissions it explicitly would not receive.

8. LDAP and OIDC boundary notes

Your evidence packet must include:

• LDAP: fake LDAPS URL, bind/search/group fields, required Java trust-store note, and statement that no real directory was queried.
• SAML: fake IdP entity/login URL, external callback, identity/group attributes, and statement that no production assertion was used.
• OIDC: fake issuer/discovery endpoints plus a statement that current Community Build native authentication documentation does not list generic OIDC; any third-party plugin would require separate plugin compatibility/security approval.

9. Prove rollback/recovery

1. Restore the pre-lab Server base URL if you changed it.
2. Verify the local administrator can still authenticate through the normal local/backend route.
3. Stop the proxy.
4. Delete only the local private key and temporary proxy process/state after evidence capture.
5. Do not delete server logs before extracting the relevant window.
6. Do not modify the database/search indices directly to “undo” authentication changes.

10. Required evidence packet

11. Residual-risk statement

This checkpoint proves the local reverse-proxy/TLS/header/base-URL contract and validates synthetic identity/group mappings for the recorded Community Build release. It does not validate a production CA, DNS, WAF/load balancer, corporate LDAP/IdP, MFA policy, SCIM lifecycle, Internet exposure, third-party OIDC plugin, or enterprise failover. Production rollout requires a separately authorized nonproduction integration test and normal change control.

12. What this adds to the governed operating model

Chapter 22 adds explicit network and external-identity trust boundaries to Chapter 21’s RBAC model. Authentication, TLS, proxy state, external group ownership, and SonarQube authorization can now be tested and rolled back independently.

Chapter 23 continues with Web API, Webhooks, Automation, Provisioning, and Policy as Code, turning these manually verified controls into safe, observable automation.

Knowledge check

Official references and version notes

• Community Build — authentication and provisioning overview — current native delegated-authentication list and JIT/group-synchronization model.
• Community Build — LDAP — LDAP/AD authentication, group synchronization, LDAPS/trust guidance, logs and migration notes.
• Community Build — SAML overview — SP-initiated SAML, IdP certificate, attributes and group synchronization.
• Community Build — Server base URL — canonical external URL required for authentication/integration correctness.
• Community Build — securing behind a proxy — inbound HTTP model, TLS termination, required forwarded headers, and proxy examples.
• Community Build — networking requirements — external systems, base-URL reachability, HTTPS/proxy topology, and network rules.
• Community Build — SAML with Microsoft Entra ID — Reply URL format /oauth2/callback/saml and base-URL dependency.
• Community OIDC plugin (third party) — optional generic OIDC path; explicitly not a first-party SonarSource native authentication guarantee.