[JENKINS-57154] Fix configureSecurity HTTP 403 err

[samrocketman]

If an admin visits the configureSecurity page in Jenkins, then every user queried will attempt to be impersonated as part of determining if they're a user. However, it's possible for some users to revoke the OAuth app or no longer have access so impersonation is not possible due to an invalid token.

The GithubAuthenticationToken class did not properly surface an error when a token authentication was not valid.

See also:

• JENKINS-57154 Regression in github-oauth-plugin 0.32 breaks /configureSecurity page

[samrocketman]

@Wadeck @agentgonzo I've tested this locally in a Jenkins instance after replicating the bug JENKINS-57154 and verified the fix is good. I'm not sure how to test this automatically as code, though.

[samrocketman]

Unrelated to JENKINS-57154. This is to fix the following warning.

WARNING: Use of toString() on hudson.util.Secret from java.lang.String.valueOf(String.java:2994). Prefer getPlainText() or getEncryptedValue() depending your needs. see https://jenkins.io/redirect/hudson.util.Secret/

[samrocketman]

I'll leave this open for a day before merging. We could always write tests later after the fact as well.

[samrocketman]

I still get

HTTP ERROR 403

Problem accessing /configureSecurity/configure. Reason:

    No valid crumb was included in the request

When attempting to save the security page so this isn't fixed...

[samrocketman]

Every time I visit http://localhost:8080/configureSecurity/ then http://localhost:8080/crumbIssuer/api/json?pretty=true changes... this is different from what I recall

[samrocketman]

Every time I visit http://localhost:8080/configureSecurity/ then http://localhost:8080/crumbIssuer/api/json?pretty=true changes... this is different from what I recall

Replicates the same behavior as logging out and logging back in... I think my the security realm searching the matrix auth is to blame because it basically seems like a complete re-auth.

[samrocketman]

Well this isn't a complete fix because the CSRF token keeps getting regenerated when visiting the security page.

[Wadeck]

Not tested manually but nothing seems wrong :)

[samrocketman]

SecurityContextHolder.getContext().setAuthentication(token); is what kept throwing the CSRF errors because global security page would generate a new CSRF token for the authenticated user every time the page was visited. So the form on the page would have an out-of-date CSRF token since doCheck would generate a new one for the logged in user (admin).

[samrocketman]

• ✔️ Tested impersonation.
• ✔️ Tested CSRF state vulnerability fix.
• ✔️ Tested resolving users and groups in global security configuration page when matrix authorization is configured.
• ✔️ Tested updating settings on the global security configuration page when matrix authorization is configured. I did not receive any CSRF form errors.

Impersonation script console code (click to expand)

---

import jenkins.model.Jenkins
import org.acegisecurity.context.SecurityContextHolder

Jenkins.instance.ACL.as(User.get('samrocketman')).with { ctx ->
    try {
        // access Jenkins job only user has access
        println "Can delete? ${(Jenkins.instance.getItemByFullName('test')?.hasPermission(Item.DELETE))? "Yes" : "No"}."
        println "Granted Authorities"
        println "    ${SecurityContextHolder.getContext().getAuthentication().authorities.join('\n    ')}"
    } finally {
        ctx.close()
    }
}

---