DevOps AcademyLearn the delivery system
Chapter 30Lesson 03~190 minutes

SSO, LDAP, OIDC/SAML Plugins, External Identity, RBAC Patterns, and Enterprise Access Governance: Configuration, Design Choices, and Tradeoffs

Select authentication and authorization patterns by trust, lifecycle, audit and failure behavior—not by whichever plugin is easiest to install.

LDAP vs OIDC/SAMLMatrix vs rolesProvisioningSessionsRecovery

Learning objectives

  • Compare LDAP, OIDC and SAML operationally.
  • Choose matrix or role-based authorization based on scale and governance needs.
  • Decide where groups should be owned and how mappings are reviewed.
  • Design recovery without creating a permanent bypass.
  • Identify provider/plugin/version prerequisites and rollback evidence.

1. LDAP versus OIDC versus SAML

All three can support enterprise login, but they fail differently and expose different configuration surfaces. Choose based on the organization’s identity platform and lifecycle controls, not on protocol fashion.

Choice Strengths Operational costs / risks Evidence to require
LDAP Direct directory lookup; mature group models; common with AD/OpenLDAP Network reachability/TLS, search filters/base DNs, bind account handling, referral behavior, directory schema quirks TLS endpoint, bind scope, base/search filters, group lookup, disabled-user test
OIDC Modern web SSO, issuer discovery, standard ID/access tokens, cloud/self-hosted IdPs Redirect URI, issuer/audience validation, claim naming, client secret, token/session lifecycle Exact issuer, client ID, redirect URI, group claim, logout/relogin tests
SAML Widely used enterprise SSO and mature federation ecosystems Metadata/certificate rotation, assertion attributes, clock/time validity, service-provider config Metadata source/fingerprint, ACS URL, group attribute, logout/session tests

Current plugin baselines for the chapter are LDAP 825.v2fca_37dd5b_cb_, OIDC 4.718.ve731df6ca_88a_, and SAML 4.623.v7875d61cd9f5. Pin and test the exact plugin set with your Jenkins LTS before migration.

2. Matrix versus Role Strategy

Model Best fit Watch-outs Rollback/evidence
Matrix Authorization Small-to-medium permission maps where explicit principal/group rows are easy to review Large environments become verbose; project-based inheritance needs careful review Export/config snapshot; group→permission diff
Role Strategy Larger platforms with repeatable global/item/agent roles and group assignments Role regex/pattern scope and role assignment become another policy layer Role definitions + assignments + target-pattern tests

Neither plugin decides who belongs to an IdP group. They consume identity/group names returned by the realm. A clean design gives the IdP lifecycle ownership of workforce groups and Jenkins ownership of what those groups mean inside Jenkins.

3. IdP groups versus Jenkins-local groups

Prefer externally governed groups for workforce lifecycle when the IdP can reliably supply them, because hire/transfer/termination processes can update membership centrally. Keep the Jenkins mapping declarative and reviewable: idp:team-a-ci → specific Jenkins role/permissions.

Jenkins-local groups or local user assignments may still be useful for narrow service/platform cases, but they create a second lifecycle system. Every local exception needs an owner, expiry/review date and deprovision path.

4. Local fallback admin versus external-only

A permanently active local admin can become a forgotten bypass; an external-only design can make an IdP outage or bad realm configuration hard to recover. The safer compromise is a tested, offline recovery procedure: a protected configuration/snapshot can restore a local security realm and temporary recovery administrator under incident control, then revert once the IdP recovers.

Pattern Availability Security posture Recommendation
Permanent alternate admin bypass High apparent availability High bypass/credential-aging risk Avoid unless a specific plugin-supported mechanism is explicitly governed and tested.
External-only with no recovery rehearsal Normal until IdP/config failure No bypass, but lockout/MTTR risk Incomplete design.
External realm + offline tested recovery configuration Strong normal controls + recoverable outage Recovery path is explicit, audited and normally inactive Preferred chapter pattern.

5. Automatic provisioning versus controlled onboarding

Many realms create/observe Jenkins user records when a person first authenticates. That is not the same as granting useful permissions. With group-driven authorization, “automatic user appearance” can be acceptable if unknown users still receive no protected permissions. For high-risk roles, use controlled IdP group membership and approval workflows.

Do not pregrant permissions to broad identities such as “all authenticated users” merely to simplify onboarding. Treat external groups as versioned policy dependencies.

6. Session and API-token design

Interactive SSO session length is partly controlled by the IdP/plugin/browser interaction; Jenkins API tokens are Jenkins-side credentials. Therefore governance needs separate rules: maximum SSO session expectations, reauthentication for sensitive changes where supported, token naming/ownership/rotation, and incident revocation.

When a group membership changes, test a fresh login and an existing session. When a user is terminated, test any known API tokens too. “Disabled in IdP” is an input to deprovisioning, not the entire proof.

7. Worked decision: a 60-team Jenkins platform

Requirement Choice Prerequisite Observable proof
Corporate SSO already exposes stable OIDC groups OIDC realm OIDC plugin current; issuer/client/redirect registered; TLS Fresh login shows expected principal/groups; issuer/audience validation succeeds
Teams need repeatable folder-level access Role Strategy role-strategy 898... compatible with Jenkins 2.568.3 Role→pattern→group export and allow/deny tests
No permanent local bypass Offline recovery config Protected controller/JCasC access, owner, rehearsal cadence IdP-outage drill restores temporary local admin then cleanly reverts
Immediate termination response IdP disable + Jenkins session/token checks Runbook can revoke Jenkins API tokens/session access Fresh login denied; existing session/token tested and revoked as policy requires
Plugin rollback Pinned plugin manifest + controller snapshot Test clone and backup compatibility Recorded plugin/core versions and restore validation

8. Design anti-patterns

  • Group name equals permission: a claim called admins has no safe meaning until Jenkins mapping is reviewed.
  • Authentication success equals authorization correctness: login proves identity, not least privilege.
  • Mutable plugin set: identity plugins are privileged controller dependencies; pin, review advisories and test upgrades.
  • Fallback means anonymous: never use anonymous access as an outage recovery strategy.
  • One-time mapping test: role/group behavior must be reverified after IdP claim, plugin, realm or authorization changes.
Next

Diagnose identity failures without widening privilege

Lesson 4 engineers the failure modes that cause the most damaging enterprise-access incidents and repairs them from preserved evidence.

Knowledge check

Answer before revealing the explanation.

1. When is Role Strategy preferable to a simple matrix?

2. Why is a permanent local admin not automatically a good break-glass design?

3. Who should own workforce group membership in a group-driven design?

4. Does automatic creation/observation of a Jenkins user on first SSO login imply that person should receive job permissions?

5. Why test both fresh sessions and existing tokens after deprovisioning?

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.
Verified baseline — 17 September 2026. Concrete plugin versions above were checked against current Jenkins plugin pages. Provider-specific OIDC/SAML/LDAP settings, logout behavior, token lifetimes and group claim names remain IdP-dependent; production designs must verify the exact provider contract rather than copy this lab verbatim.

Keep the academy open

Support free, practical DevOps education.

Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.

Ethereum / ERC-20
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0Send only Ethereum/ERC-20 compatible assets to this address.