Jira two-way SSL authentication

With two-way SSL authentication, you can validate that the Jira requests are both encrypted and coming from a guaranteed source. Two-way SSL authentication works as shown on the image below: the SSL client application (A) verifies the identity of the SSL server application (B), and then the SSL server application verifies the identity of the SSL-client application.

Firewall (logical or physical)

• Connections are always initiated by Jira Align.
• All requests are over SSL/TLS port defined by your side.

Authentication

• The layer 5 does authentication of parties using the SSL handshake request as part of the mutual certificate validation process.
• There should be no authentication at the API gateway tier.
  • This authentication would be redundant with mutual certificate process, thus adding another layer of potential breakage.
  • Adding two authentication processes would be very complex and is not currently supported in our software solution.
• The Jira tier does the authentication per your recommended Jira authentication process to match your version of the Jira application.

Encryption

• The Jira Connector only supports TLS v1.2 for SSL communication.

REST API Support

• Our solution requires access to the full suite of REST verbs such as GET, POST, PUT, and DELETE.
• Our solution also requires access to the entire Jira REST API.
  • GET /rest**
  • POST /rest**
  • DELETE /rest**
  • PUT /rest**

Note: These are strict requirements because our application cannot support a subset of these.

Certificates

• We typically use our *.jiraalign.com certificate for the validation process.
• If you require a certificate defined within a pre-approved domain, we can generate a CSR on behalf of your domain and use this for the Jira connector.

Two-way SSL authentication is known as client authentication or mutual authentication because the SSL client application sends its certificate to the SSL server once the SSL server has authenticated itself to the SSL client.

To establish an encrypted channel using the certificate-based two-way SSL:

1. A client requests access to a protected resource.
2. The server sends its certificate to the client.
3. The client verifies the server’s certificate.
4. In case of success, the client sends its certificate to the server.
5. The server verifies the client’s credentials.
6. In case of success, the protected resource requested by the client receives access from the server.

From the server side view, if the client shows a certificate and uses the private key as part of a CertificateVerify message and the server validates the client certificate with regards to a set of trust anchors which does not include a hostile or incompetent root certificate authority (CA), then the server has a guarantee that it is addressing the right client. The guarantee holds for all subsequent data within the connection.

If SSL with mutual client-server authentication is used, the attacker will need to plant rogue CA both in the client and the server to conduct a successful man-in-the-middle (MitM).

To identify roles:

1. Identify a security/network level owner of Jira and security device in the client data center (Jira Sec).
2. Identify a Jira user account manager (Jira Mgr).
3. Identify a Jira Align administrator (Jira Align Admin).
4. Identify a Jira Align Ops (Jira Align Ops).

To set up public key exchange and security device configuration:

1. Jira Align Ops sends public keys in a secure way to the Jira Sec.
2. Jira Sec configures *.jiraalign.com keys in their mutual TLS certificate management solution.
3. Jira Sec connects a test Jira server to an external network.
4. Jira Sec validates public Internet connectivity.
5. Jira Sec enables Jira REST API to pass through a security device. Note that Jira Align requires all REST verbs and access to the full Jira API set.

For example in APIGEE, the rule configuration looks like this:

• GET        /rest**
• POST     /rest**
• DELETE /rest**
• PUT       /rest**

Note: In the Azure API Gateway, the public key must be all caps. 

To create a Jira application proxy account:

1. Jira Mgr creates proxy accounts for the Jira connector in Jira Align production and test environments.
2. Jira Mgr sends proxy information to Jira Align Ops in a secure way.
3. Jira Mgr determines the application-level authentication protocol for REST API requests from {Oauth, Cookie}. 

Jira to Jira Align Rest API validation – Test Environment:

1. Jira correlates the URL of the test server to the work performed by the Jira Align Admin.
2. Jira sends the URL to the Jira Align Ops and Jira Align Admin.
3. Jira Align Admin selects and configures Jira in Jira Align administration user interface.
4. Jira Align Admin reviews sync success or failure in UI.
5. Jira Align Ops reviews connector Jira logs on the Jira Align test server.
6. Jira validates the request is received at the security device tier.
7. Jira validates the request is received at the Jira Rest server tier.

To set up production configuration:

1. Jira Align Ops finalizes production site and servers for operational readiness.
2. Jira Sec, Jira Mgr, Jira Align Admin, and Jira Align Ops repeat all steps from the Jira to Jira Align Rest API validation – Test Environment procedure.
3. Jira Align Ops performs database transfer from the test site to production.