Internal and External JIRA access

tims January 28, 2014

Hi,

We would like to deploy an internally hosted JIRA instance for both internal users and our exeternal clients.

Basic requirements are:

  • Internal support staff will use JIRA to manage internal and client support tickets
  • Internal staff will use JIRA for Project Managment
  • Clients will have external access to log and view support tickets
  • AD authenticaiton for both internal and cleint users
  • No internal projects are exposed to clients
  • Clients can only view their projects
  • Two facter authenticaiton if possible?

Our primary concern is from a security aspect. What is the suggested approach.

I have seen some informaiton on partitoning and public/private instances. We are looking for advise primarily on how to secure both internal and client data form the outside world whilst making our JIRA instance available to our external clients via a web login.

Would two instances of JIRA be preferable, one public instance for clients and one private instance for internal users? If so, how would Issues be moved between the two instances.

Thanks,

Tim

4 answers

1 vote
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 28, 2014

For your case, I'd suggest sticking with a single instance for both groups. It's perfectly possible to set up a Jira so that various sets of users have different access, including sections that are completely hidden to some users.

The one piece of advice I would give you to begin with though - Jira's default permission scheme is completely useless for this. It's permissive, and it encourages users to continue to be permissive because it uses the same group for "can log in" and "can use all the projects".

Before you set anything else up, it is worth correcting this and educating your administrators. You can either create a new group or re-use "jira users", but you need to define a group that defines "these users CAN log in, but they can do NOTHING else" (well, ok, if you've got a "jira support" project, or you want to allow everyone "browse user" and/or "bulk edit" by default, you can use it there too).

Do NOT use the group in ANY permission schemes, roles or default roles.

Then, you'll be able to put your internal and external users into other groups or roles and control their access that way. But separate out "login / jira user" from all of that.

0 votes
tims January 28, 2014

Nic, Tarun,

Thanks very much for the answers. I'll re-post if additional questions are raised here.

0 votes
tims January 28, 2014

Thanks, Tarun.

So a single instance of JIRA with locked down group permissions is a standard approach to making JIRA available to external and internal users?

I am keen to emulate a tried and tested approach to this.

Thanks again,

Tim

Tarun Sapra
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 28, 2014

Hi Tim,

Yes, just make sure you have well defined groups, and customize the permission schemes of your projects and map the scheme to correposding groups.

Cheers,

Tarun

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 28, 2014

And make sure you separate out "can log in" group from all the permissions as I said earlier. That's absolutely critical, or you'll accidentally walk into "can log in = can see everything"

0 votes
Tarun Sapra
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 28, 2014

Hi Tim,

JIRA already is equiped with pretty advanced group management, if you put all your external users in a certain group and make sure those groups don't have permissions for read/write for your internal projects, wouldn't that fix your problem?

Cheers,

Tarun

Suggest an answer

Log in or Sign up to answer