10X: 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 SSL communication requirement is TLS 1.2. We do not support a less secure version.

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 *.agilecraft.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 T-Rex 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).

SSL vs. VPN for secure communications 

Why not VPN?

Why SSL?

No association to any specific application.

SSL is a common protocol and most web stacks have SSL capabilities built in.

The client computer with IPSec VPN is virtually a full member of the corporate network and is able to see and potentially access the entire network.

SSL allows more precise access control:

  • Tunnels to specific applications rather than to the entire corporate LAN.
  • The REST requests over the SSL connections can only access the applications they are configured to access rather than the whole network.

IPSec VPN solutions cannot operate without third-party hardware and/or software.

When combined with application authentication and authorization, the solution has more granular control access.

The client software on all remote machines needs to be maintained.

Direct access to the web-enabled SSL applications guarantees no access to network resources such as printers or centralized storage and users cannot use the VPN for file sharing or backups.

 

Authentication workflow 

Customer to provide

Jira Align to provide

  • A URL for the Jira server, for example, https://jira.customername.com/restapi
  • A proxy user account on the Jira server with which the Jira Align REST API will authenticate.
  • A test Jira server to validate connection protocols. 
  • Public Key of the T-Rex client which will attempt a request to a URL.

 

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 an Jira Align administrator (Jira Align Admin).
  4. Identify an 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 *.agilecraft.com keys in their mutual TLS certificate management solution.
  3. Jira Sec connects a test Jira Software 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 Jira Align T-Rex in 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 Software 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 T-Rex 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 Software to Jira Align Rest API validation – Test Environment procedure.
  3. Jira Align Ops performs database transfer from the test site to production.

 

Was this article helpful?
0 out of 0 found this helpful
Print Friendly Version of this pagePrint Get a PDF version of this webpagePDF

Join the Atlassian Community!

The Atlassian Community is a unique, highly collaborative space where customers and Atlassians come together. Ask questions and get answers, start discussions, and collaborate with thousands of other Jira Align customers. Visit the Jira Align Community Collection today.

Need to contact Jira Align Support? Please open a support request.