Enterprise-Wide Jira Software to GitLab Integration
Asked by Dorene Watson:

Can anyone provide guidance on how to configure the needed non-human Jira Service Accounts for an **enterprise-wide** **Jira Software to GitLab integration**?

The integration will potentially include hundreds of projects/groups on each side and will need to maintain user privileges between the two. *GitLab users who don't have the Jira privileges to access a Jira projects'* *data won't be able to and vice-versa.*

* Using a single Service Account allows GitLab Users to access Jira project data across all Jira projects so is a non-starter.
* Using multiple Service Accounts poses resource and process maintenance issues. We want to avoid managing hundreds of accounts if possible.
* Having Jira Project Owners create/use a Personal Access token from their own Jira account to use for their teams' integration seems feasible but might pose other issues.

Has anyone out there ever implemented a large-scale integration like this? If so, I'd love to hear how you designed this piece of it.

Specifically, we plan to set up the Jira Issue Integration and/or the Jira Development Panel mentioned in this article from GitLab: [https://docs.gitlab.com/ee/integration/jira/\\#privacy-considerations](https://docs.gitlab.com/ee/integration/jira/#privacy-considerations)The instance is Jira Software Datacenter and the Gitlab instance is Self-Managed.

Thanks!

Dorene


Answers:
author: Josh_Unito
body: Hi [@Dorene Watson](/t5/user/viewprofilepage/user-id/5363471)! I'm from Unito, we're an Atlassian partner with integrations for Jira (cloud, server, JSM, and DC), GitLab, and \~50+ other apps and tools. Our integration platform is designed to support teams like yours with large-scale integrations that sync issues between Jira and GitLab so that users who *don't* have access to one repository in one tool can still collaborate from *another* tool while keeping their work synced in real-time.   

The flow building process is much simpler than the heavier automation solutions out there. It takes me around 15 minutes to set up a secure connection between Jira and GitLab to send issues back and forth with 2-way updates.  

Here's a tutorial I wrote on [syncing repository data between Jira and GitLab](https://bit.ly/ATL-GitLab-Jira-Guide). It includes a video demonstration of Unito in action.  

Let me know what you think and I'd be happy to set you up with a free trial account or connect you with one of our integration experts to help you plan out a workflow that meets your needs.

Thanks!

- Josh

comments: author: Dorene Watson
body: Hi Josh.

Couple of questions for you...

Do you need to set up a Flow for each Jira to GitLab project in order to keep users from having access to projects in the other tool that they shouldn't. For example, if I link all projects in both tools under one flow, can a GitLab user access a project in Jira that they don't have access to within Jira itself? Or would this open up all synced Jira projects to that user?

How is the connection between tools made? Does it use Oauth2 or another authentication method? Need to be sure it is secure.

<br />

Thanks,  
Dorene


author: Josh_Unito
body: Hi Dorene,  

Here are some answers for you!  
**Security:** I know our Jira Data Center connector uses OAuth 2.0, API tokens and username/password authentication methods. But I haven't personally tested the Gitlab Enterprise connector. In terms of security, we're SOC 2 Type II compliant and you can find more details in this [security overview](https://unito.io/security/). We don't store data from work items; we compute checksums of field data which enable us to sync information.  

The platform uses Transport Level Security (TLS) version 1.2 to encrypt data in transit, and Unito maintains an "A+" rating on [Qualys SSL labs tests](https://www.ssllabs.com/ssltest/). Data at rest is encrypted with AES 256 algorithms or better.  

![Unito Qualys SSL Test.png](https://community.atlassian.com/t5/image/serverpage/image-id/341014iF3B074EB25BC264D/image-size/large?v=v2&px=999 "Unito Qualys SSL Test.png")  

If you'd like, I can put you in touch with a member of our internal data security team.  

**Flow Building:**   

In Unito, **one flow connects one** **GitLab repository to one Jira project**. Unito will then create new issues automatically in GitLab and/or JDC with all the fields synced over from the other.

**Here's my attempt at a summary:** the platform doesn't provide direct access to a project in another tool, it essentially creates copies of specific issues from one project and places them in another. In your field mappings table, you then set an **update direction** that decides how manual changes to a specific field in one tool affect the other. So if all fields are set to 2-way sync, any changes in GitLab or JDC would appear in the other automatically.

**Here's what you then configure within the flow itself:**

- **A Flow Direction:** From GitLab to JDC, from JDC to GitLab, or both. This tells Unito where to create new issues. You can still set 2-way sync for updates later on.

- **Rules:** by default, Unito syncs all issues created after you launch the flow. There's a **creation date** rule that acts as a safeguard so you can test the flow before syncing all your historical data. Once you remove that rule, the flow will sync all issues.

**- Add exclusions:** you can exclude issues from syncing with additional rules, such as: label, assignee, a custom field, etc... So for example, you could set up a flow that *only* syncs Jira issues with a specific label or status.

- **Field Mappings:** The final step lets you link individual fields between Jira and GitLab issues. So even if your labels have different names in each tool, you can tell Unito that one is equivalent to another (e.g., a "ready for review" label in one is the same as a "ready for QA" label in the other). This *also* lets you get even more granular about what information to sync between issues. If there's something in JDC that you don't want GitLab users to see (or vice versa), you simply don't include it in your field mappings table.

**Duplicate flows:**

So if you're working with a *lot* of projects, you don't have to go through the above process from scratch each time. You can instead duplicate a flow you've built (using it as a template), then modify the details in the second flow. We often see cases where users will do this to set up a "master project" which is then connected to dozens of "child" projects which all send data to the master.

**I know that's a lot of information, so feel free to reach out by DM or LinkedIn and we could book a call or I can connect you with an integration specialist on my team. Good luck!**


author: Dorene Watson
body: Thans for the info Josh. One last question for you if you don't mind...

When using a "master project" connected to dozens of "child" projects, are user privileges maintained? For example, if a master project contains Projects A, B \& C. And User #1 only has access to Project A. Will they be able to see data in Projects B \& C?

Dorene


Tags: data-center

gitlab

integration

jira-data-center

jira-software