Restricting certain projects based on IP

[Sameera Shaakunthala [inactive]]

Hi,

Is it possible to restrict certain projects in a JIRA system to be accessed only from a defined set of IPs/ locations?

For example, let us say we have two projects called ABC & DEF.

The system is open to the general Internet. Requirement is to make ABC project accessible only from the client's *premises*, and DEF as usual. If someone who is a member of ABC project attempts to log into JIRA from his home, he should not be granted access. But when he attempts the same from office, access should be granted.

Such a restriction should not apply to DEF. DEF clients should be able to log into JIRA from anywhere.

Could you please let us know how this can be done?

Many thanks!

--

Shaakunthala

[Nic Brough -Adaptavist- · Accepted solution]

I'm afraid this is a non-starter.

Even if security by IP isn't really a good idea, Jira simply isn't set up to expect it. You can use Apache to prevent access the specific issue views and the project urls, but there's no way of preventing your users from running filters, reports, gadgets and so on.

Example - if I'm not supposed to see project "Fred", and you bar my access to http://yourjira/browse/FRED* that will work. There is no way that you can block me from running a filter for "all issues in FRED" and downloading it all via the navigator, excel, xml. I can help myself with SOAP/REST stuff. It'll show up in a list of projects, so I'll be able to add it to gadgets.

The best you can really do with IP restrictions is nothing more than "let ip range see Jira", and even that's pretty much useless given that it's a doddle to spoof IPs.

[Andrzej Pasterczyk]

I guess having separate Jira instance you can have a VPN tunnel or something so that it's only accessible from your (jira hoster) and customer network without exposing it to the outside world. Then IP spoofing should not be a problem.

[Nic Brough -Adaptavist-]

Oh absolutely, VPN is a much better solution to "I want to limit access" than "use IP addresses".

[twong_atlassian]

Any ip based solution that is piecemeal isn't going to really be encompassing enought be called "security."

If it really is necessary for some projects to have restricted access from offsite; I'd suggest moving these projects to a separate jira instance that is completely restricted from the outside world, then force people to either be in the private network or vpn to access this box.

[Harry Chan]

Agree to this. Separate JIRA instance is the way to go. It will get very messy with IP based restrictions that can get out of hand very very easily. It is also very hard to maintain.

[Nic Brough -Adaptavist-]

As I said before, IP restrictions will only block part of the project information - there's no way to block the information appearing in reporting, summaries, and other parts of the system unless you block them entirely.

The whole prospect is a non-starter, even if you choose to ignore the fact that IP restrictions are useless as "security" because they are a doddle to bypass.

[twong_atlassian]

The above is a pretty good summary of facts.

I'm not sure how this plugin you speak of works, so I couldn't really speak to how effective (from a security standpoint) that would be, but I believe the common advice of separating secure vs less secure elements and sequestering the more secure content in it's own jira instance that is controlled by more stringent network security rules is the best practice if content is deemed secret.

[Sameera Shaakunthala [inactive]]

Many thanks for everyone who answered the question. Few things that I may need to highlight based on your answers to this question,

1. Apache/httpd URL filtering does not work. Projects can be blocked, issues can be blocked, but viewing attachments can't be blocked. Attachment URL does not contain any project ID.
2. Blocking projects won't prevent users from downloading project data in other formats.
3. Still IP spoofing is possible.

An alternative and intermediate solution would be restricting users based on their IP addresses, rather than the project. We accomplished that with an in-house built plugin.

Further RND is required to find out whether it is possible to implement any security mechanism like a public/ private key pair.

Cheers!

[Pranjal Shukla]

Why go with IP, I guess best is to have a permission scheme restriction and restrict those projects to only some set of users. This would also give them flexibility to login from any IP they want.

[Nic Brough -Adaptavist-]

Don't forget that it's a doddle to spoof an ip address.

[Radu Dumitriu]

It is actually very simple to do it. The very basic solution is this:

1) Place an apache httpd in front of Jira (or ngix)

2) Configure the reverse proxy to access jira http://httpd.apache.org/docs/current/mod/mod_proxy.html

3) Use:

<LocationMatch "^/jira/browse/PRJKEY.*">

Require ip 192.168.0.0

</LocationMatch>

What I would do, though:

a) Alternatively, you can play with mod rewrite, and rewrite the request from home to point to a page which is says "This project is only accesible from office".

or

b) You can even augment the java application if you do not want to put apache httpd in front of your jira. Check this filter http://urlrewritefilter.googlecode.com/ I heard that it works ok.

[Andrzej Pasterczyk]

As I've mentioned I believe such solution has holes in it or requires complicated config to make it more or less secure.

1. You can't enter particular issue but you can still search for issues in restricted project
2. You can get the issue content from search results (e.g. exporting to XML)
3. You can probably register new issues in restericted project
4. You can do everything using REST API (unless you specify another set of url filters)

From my perspective it is not a good way to go if security is primary concern here. Another alternative would be to setup a second Jira instance just for this project and fully protect it on firewall but this requires separate license.

[Radu Dumitriu]

I can agree that putting together the entire URL collection is not easy, but it's doable. You may prohibit certain operations like export. It is of course a partial solution, but Shaakunthala does not want to completely remove access to the project for those users, the solution may be good enough.

But, yes, you're right, the correct way to do it if you want to tight up the security is creating a separate server.

[Andrzej Pasterczyk]

I have not given it too much thought but I can't see a way to prohibit getting search results based on URL :)

[Andrzej Pasterczyk]

True... but I belive we both agree that it probably is cheaper to buy another Jira instance than to build some sofisticated security around it (considering that it'll probably have new holes after upgarding jira instance) :)

I'd say it's either the easy way with (very) low security, or proper security on a separate instance.

[Radu Dumitriu]

Do you suggest that I should extend the mod_rewrite to modify the POST variables ? For sure that can be done :) if not already.

[Nic Brough -Adaptavist-]

You can generate urls that will return data from a "protected" project that you have no way of knowing contain data from the protected project.

It doesn't matter how clever you get with apache and urls, there is no way to do this (in a single instance of Jira). I can think of one way to hack Jira so that it would be possible, but it is not pleasant, and separate instances is a far better approach.

[Andrzej Pasterczyk]

There's nothing like that out of the box in Jira. Personally I agree with this response https://answers.atlassian.com/questions/30775/how-to-restrict-jira-access-browsing-only-to-a-certain-set-of-ip-s You should try to configure this on firewall level or put a web server infront of Jira.

You could set up some rules that would prevent access to issues and project itself based on user IP and target url that in general matches pattern http://[server]/jira/browse/[projectkey]-123 but this will have holes in it (you'll still be able to get search results, access xml view, etc.).

If you're into development you might create a proxy that would require authentication on first request, check the user agains Jira project assignements (e.g. using REST API) and then switch to pass-through mode if user is OK to access Jira or block the connection if not.