This is a Jenkins plugin providing authentication with CAS, with Single Sign-On (SSO) and Single Logout (SLO) support.
The latest version is available for download from the Update Center and from the Download Site.
- Jenkins 2.266 and higher require CAS plugin version 1.5.0 or higher.
- Jenkins 2.265 and lower require CAS plugin version 1.4.3 (1.5.0 is NOT compatible).
- Jenkins 2.160 or 2.150.2 LTS and higher require CAS plugin version 1.4.3.
In these cases, you will need to upgrade Jenkins and CAS plugin together to avoid issues. This means manually downloading and updating the cas-plugin.hpi file in your Jenkins plugins directory (rename to cas-plugin.jpi as needed).
- Checkout or download the source code from the current master or latest tag on GitHub.
- Execute
mvn clean verifyfrom your local source code folder (install Maven if not already done). - Find the
cas-plugin.hpifile in thetargetsubfolder. - Upload it to Jenkins from the Advanced tab of the Manage Plugins page.
- Install the plugin from Manage Jenkins > Manage Plugins > Available > CAS Plugin.
- Go to Manage Jenkins > Configure Global Security, check Enable Security and select CAS (Central Authentication Service) as the Security Realm.
- Next to CAS Server URL, enter the base URL to your CAS server, e.g.
https://cas.example.com/cas - Next to CAS Protocol, select the protocol to use to communicate with CAS, e.g. SAML 1.1 if you are using Apereo CAS Server 3.x or higher, or CAS 3.0 if you are using Apereo CAS Server 4.x or higher.
- If there are no warnings, click the Save button at the bottom and attempt logging in.
Additional configuration options are available under the Security Realm section:
- Force authentication renewal: when checked, Single Sign-On (SSO) is disabled: even if a CAS session is already open, the user will have to provide credentials again to confirm his/her identity.
- Use CAS REST API for external/scripted clients: when checked, the CAS REST API will be used to authenticate Jenkins API requests (in addition to Jenkins API keys) using a username/password.
- Process Single Logout (SLO) requests from CAS: when checked, Single Logout is enabled: whenever the user logs out of CAS (e.g. when logging out of another CAS-enabled application), the corresponding Jenkins session will be destroyed and the local user logged out as well. Note that for this to work, the CAS server must be able to communicate with Jenkins using the service URL that was passed to it during login.
- Logout from CAS when logging out of Jenkins: when checked, Jenkins will redirect to CAS after logging out the local user, in order to destroy the SSO session.
Several protocols implemented by CAS are available in the CAS Protocol dropdown (click the Advanced... button to reveal more options):
- CAS 1.0: a text-based legacy protocol. Custom extensions may provide support for roles, which can be parsed with a Groovy script specified in Roles Validation Script.
- CAS 2.0: a XML-based protocol. It supports Proxy Tickets, allowing external applications already secured with CAS to authenticate in Jenkins without requiring user input or password. Custom extensions may provide support for attributes.
- CAS 3.0: a XML or JSON-based protocol. It supports Proxy Tickets, allowing external applications already secured with CAS to authenticate in Jenkins without requiring user input or password. It fully supports attributes out-of-the-box, without requiring custom extensions. This is a recommended protocol for Apereo CAS Server 4.x and higher.
- SAML 1.1: a XML-based protocol. It fully supports attributes out-of-the-box, without requiring custom extensions. This is a recommended protocol for Apereo CAS Server 3.x and higher.
Attributes are an easy (and recommended) way to add full name and email address information to an authenticated user, as well as roles/groups membership. CAS 1.0 response parsing with a custom Groovy script is made available as a legacy option for backward compatibility with the CAS1 Plugin.
By default, when using the CAS plugin for authentication, you cannot use a regular username/password for remote authentication into Jenkins. This is by design, as the CAS protocol does not allow "direct" authentication and works with secure redirections, which are not compatible with remote calls such as SVN or GitHub hooks.
You have two options:
- Use the user's API token as the password; you can find it by going to the Configuration page of the Jenkins user you intend to use for external access. This API token does not expire and you may regenerate it as you need.
- Enable the REST API option in the plugin configuration, to use the CAS REST API to process the real username/password. The CAS REST protocol must be enabled server-side for this option to work.
See the following page for more information: Authenticating scripted clients
When using Jenkins behind a reverse proxy, depending on configuration the URL users get redirected to after authentication may be wrong. If this is the case:
- Go to Manage Jenkins > Configure System.
- Under Jenkins Location, make sure the Jenkins URL is valid and can be reached by users. It will be used by CAS to redirect back to Jenkins after authentication.
Please see the Troubleshooting Guide from the CAS Project.
If Jenkins systematically fails to validate SAML 1.1 tickets, make sure to check whether the system clock of your Jenkins and CAS servers are synchronized. Indeed, the timestamp at which SAML 1.1 tickets were generated is checked when validating them, with a configurable tolerance (see "Time Tolerance" plugin option). Out-of-sync clocks may log errors such as "skipping assertion that's not yet valid" in Jenkins.
By default, using normal username/password is not possible from external/scripted clients when using CAS. You may use an API token instead and/or enable the REST API support. See "Usage" section above for more details.
This issue (JENKINS-20064) is fixed in Jenkins 1.556 and higher, provided that the user logged in through the web interface at least once. This limitation does not apply when the REST API option is enabled along with the real username/password.
If Jenkins is behind a reverse proxy, it may not be able to detect its own URL by itself. In this case, you need to manually configure the Jenkins URL. See "Usage" section above for a solution.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent