Skip to content
Browse files

Merge pull request #1192 from Wadeck/JENKINS-27027_AUTHENTICATION_FLOW

[JENKINS-27027] Documentation for Authentication flow
  • Loading branch information...
rtyler committed Nov 28, 2017
2 parents 5293a1d + 68c9899 commit b953d6c376cc099c0ed9c008c781b444f639ffe6
@@ -7,6 +7,8 @@ references:
title: Script Security Developer's Guide

:imagesdir: /doc/developer/security/resources

// this is a straight import of
// TODO check contents and remove wiki page

@@ -96,6 +98,68 @@ To do this, write Jelly like this:
NOTE: This is not to be confused with the +checkPermission+ invocation in your operation.
Users can still hit the URL directly, so you still need to protect the operation itself, in addition to disabling the UI rendering

=== Authentication ways

In Jenkins the security engine that is used is Acegi Security (ancestor of Spring Security).
Without any special plugins to manage authentication, an instance of Jenkins is packaged
with the following authentication ways:

* Web UI
** When you use the form on the login page, using the fields +j_username+ and +j_password+
** Using Basic with login / *password*
** Using Basic with login / *apiToken*
* Jenkins CLI jar
** (deprecated) using remoting transport with login / logout command
** (deprecated) username / password as parameters on each command
** +-auth+ argument with username:password or username:apiToken that will do something like HTTP calls
** using SSH transport mode with your local keys
* CLI over SSH
** directly using the native SSH command, without Jenkins CLI

=== Authentication flow

Depending on the authentication method you use, the processing flow will differ drastically.
By flow we mean the involved classes that will check your credentials for validity.

==== Web UI and REST API

image:web_rest_flow.svg["Web UI and REST API flow", role=center]

In the diagram above, each arrow indicates a way to authenticate.

Both the Web UI and the REST API using login / password will flow in the same +AbstractPasswordBasedSecurityRealm+
that delegates the real check to the configured +SecurityRealm+.
The credentials are retrieved for the first method by retrieving information in the POST and for the second by using the Basic Authentication (in header).
A point that is important to mention here, the Web UI is the only way (not deprecated) that use the Session to save the credentials.

For the login / apiToken calls, the +BasicHeaderApiTokenAuthenticator+ manages to check if the apiToken corresponds to the user with the given login.

==== CLI (SSH and native)

For the CLI part, the things become a bit more complicated, not by the complexity but more by the multiplicity of way to connect.

image:cli_flow.svg["CLI flow", role=center]

The first case (remoting) is deprecated but explained as potentially it's still used.
The principle is to create a sort of session between the login command and the logout one.
The authentication is checked using the same classes that we use for the Web UI or the REST API with password.
Once the authentication is verified, the credentials are stored in a local cache that will enable future calls to be authenticated automatically.

The second way put the username and the password as additional parameters of the command (+--username+ and +--password+).

For the third and fourth ways, we pass the parameters to connect like in an HTTP call in the header.
The authentication is checked exactly the same way as for the REST API depending on the provided password or token.

Last possibility for the Jenkins CLI is using the SSH transport mode offered by SSHD module (also available for plugins).
It uses normal SSH configuration using your local keys to authenticate.
It shares the same verifier with the Native CLI way.

==== Other ways
The plugin have the possibility to propose a new `SecurityRealm` or implements some `ExtensionPoint`s
in order to provide new ways for a user to authenticate.


0 comments on commit b953d6c

Please sign in to comment.
You can’t perform that action at this time.