SSO, LDAP, OIDC/SAML Plugins, External Identity, RBAC Patterns, and Enterprise Access Governance: Guided Hands-On Workflow and Core Operations

1. Mandatory lab path: simulated enterprise identity on a disposable controller

The lab uses the Mock Security Realm plugin because it supports synthetic users/groups, simulated delays/outages and JCasC. The plugin itself states that it is insecure and intended exclusively for testing/demonstration. It is therefore appropriate for this chapter’s mandatory local path and inappropriate for production.

Use Jenkins 2.568.3 LTS with Java 21, Mock Security Realm 134.v31b_1cc496b_43, and Matrix Authorization Strategy 3.3. Keep the built-in node at zero executors. No cloud account, commercial IdP, proprietary repository or real credentials are required.

2. Step 1 — Define synthetic identities before configuration

Create the access contract on paper first. This prevents the UI sequence from becoming the design.

3. Step 2 — Preflight and evidence capture

Record before mutation
----------------------
controller URL and instance identity
Jenkins 2.568.3 / Java 21
mock-security-realm 134.v31b_1cc496b_43
matrix-auth 3.3
current security realm
current authorization strategy
built-in executors = 0
folder: identity-lab/team-a
job: identity-lab/team-a/smoke
current anonymous permissions = none
recovery configuration snapshot/commit = recorded

Also capture a configuration snapshot or Git-managed JCasC commit from Chapter 26. If the realm change locks you out, the recovery action is to restore the known configuration through trusted controller access—not to weaken authentication.

4. Step 3 — Configure the simulated realm

Install the pinned lab plugins on the disposable controller through your reviewed plugin manifest. In the Mock Security Realm configuration, define only synthetic identities. The plugin’s user definition format is newline-delimited and supports user/group membership. A conceptual inventory is:

alice jnk-viewers
bob jnk-viewers jnk-builders
carol jnk-platform-admins
dave

In this test realm the password convention is intentionally trivial; do not treat it as a production authentication pattern. The point is to create deterministic principals/groups so you can test Jenkins authorization separately.

5. Step 4 — Map least privilege in Jenkins

Use Matrix Authorization Strategy for the mandatory lab because it keeps the group→permission mapping explicit. Grant the smallest global permission necessary to enter Jenkins, then apply project/folder permissions to the lab hierarchy. Do not give jnk-builders Overall/Administer, credential administration, controller configuration or agent configuration merely because they can build.

For production organizations that prefer Role Strategy, create named roles such as viewer, builder-team-a, and platform-admin, and assign IdP groups to roles. The same least-privilege principle applies.

6. Step 5 — Test with fresh sessions, not one cached browser

Use separate private-browser profiles or explicitly log out between identities. Authentication testing is invalid if every role is tested through the same already-authenticated administrator session. Record principal name, groups as observed by Jenkins, and the exact permission test.

Evidence row example
principal=bob
fresh_login=true
groups=jnk-viewers,jnk-builders
target=identity-lab/team-a/smoke
action=Job/Build
expected=ALLOW
observed=ALLOW
build=identity-lab/team-a/smoke #7

7. Step 6 — Simulate deprovisioning

Remove bob from jnk-builders in the simulated external identity source. Then start a fresh session and prove that build permission disappears while viewer access remains. Do not stop at “the directory entry changed.”

If the lab user has a Jenkins API token, revoke it or prove its behavior under the configured realm. In a production runbook, deprovisioning includes both IdP state and Jenkins-side credentials/sessions whose lifecycle may differ.

8. Step 7 — Simulate IdP outage and rehearse recovery

Use the Mock Security Realm’s outage capability or configuration-only simulation to make authentication unavailable. Confirm that anonymous access remains disabled. The expected outcome is controlled inability to create new authenticated sessions—not a security bypass.

Then execute the pre-authorized break-glass procedure on the disposable controller: restore a known recovery configuration that uses a local realm and a recovery administrator, validate administrative access, record the incident evidence, and then restore the external-realm configuration after the simulated provider recovers. Rotate any temporary recovery credential.

9. Small challenge: choose the layer, not the click sequence

Bob can authenticate and Jenkins shows jnk-builders, but Job/Build is denied only under identity-lab/team-a. Which layer do you inspect first?

Answer after investigation: authorization/folder inheritance, not LDAP/OIDC/SAML authentication. The realm already proved Bob and supplied the expected group. Capture the folder/item mapping and inherited permissions before changing anything.

Knowledge check

Answer before revealing the explanation.

Official references and version notes

• Jenkins LTS changelog — chapter baseline: Jenkins 2.568.3 LTS; labs use Java 21.
• Securing Jenkins — security realm versus authorization strategy, least privilege, controller isolation and access-control fundamentals.
• LDAP plugin — version 825.v2fca_37dd5b_cb_ (requires Jenkins 2.504.3); current release includes fixes beyond earlier LDAP referral/SSRF advisories.
• OpenID Connect Authentication plugin — version 4.718.ve731df6ca_88a_ (requires Jenkins 2.539); issuer/audience/group-claim behavior is provider configuration, not Jenkins authorization by itself.
• SAML plugin — version 4.623.v7875d61cd9f5 (requires Jenkins 2.504.3).
• Matrix Authorization Strategy — version 3.3 (requires Jenkins 2.528.3); supports granular global/project authorization.
• Role-based Authorization Strategy — version 898.vc050ed2424ca_ (requires Jenkins 2.559); supports global/item/agent roles and group assignments.
• Mock Security Realm — version 134.v31b_1cc496b_43; intentionally insecure and suitable only for disposable testing/demonstration.