Limit confluence anonymous to ip range

[Michael Schwessinger]

Hello,

We use our confluence with anonymous read access throughout our company. About 75 users have named logins, for write access, and another 175 or so have only read access through anonymous, like documentation or announcements.

Now there's a request to create a space for collaboration with external companies, but these should not be able to access all the anonymously available content, just their new collaboration space.

We can identify them by coming in over our VPN IP range or via outside https access, both different IPs than our internal network.

Is there a way to restrict anonymous usage based on the client IP? Either whitelist or blacklist?

Best regards,

Marco Dieckhoff
(posted this while logged in with the wrong company account)

PS: Please note that this is different from the question "https://answers.atlassian.com/questions/184476."

[Trever Furnish]

Nic's responses above are helpful insomuch as they note that Confluence can't do this, but unless "doddle" means "exceedingly difficult and unlikely to be accomplished", it isn't "a doddle" to spoof an IP address for bypassing web connections, and it would certainly be helpful if Confluence had this functionality.

We do want confluence to be public-facing, but we don't want every anonymous space to be public-facing.  It is entirely reasonable for confluence to provide such functionality, but given that the request has been out there for 10 years, it seems unlikely to ever happen.

As another suggestion: Spin up a dedicated confluence installation internally for such spaces if you can limit your named users such that they fit into the $10 cost tier.  That's what I'm likely to do for our new-hire documentation -- I only need a tiny handful of people to be able to edit that documentation, and I need 5000 users to be able to read it anonymously.

Other alternatives I considered were Sharepoint Online (where our users are already licensed enterprise-wide) and a static site (ie mkdocs).

[Kesha Thill]

Hi @Michael Schwessinger ! 

I know this is from a few years back, but I wanted to give you an update on your request above. We've recently launched a beta program for IP allowlisting that's available for Confluence, Jira Software, and Jira Service Desk Cloud Premium customers and evaluators. I'm not sure if you're on server or cloud, but if you're still interested, you can learn more about the feature and how to enable it by visiting our documentation for IP allowlisting here.

Please reach out if you have questions!

[Boris Simanovich]

Hi Kesha,

This is a pretty basic/standard feature, however it seems to be only available in the premium plans. Is that going to change?

Thanks!

[Michael Wensley]

Agree that this should be a basic security feature implemented for the cloud platform!

[Nic Brough -Adaptavist-]

Not with Confluence, it really doesn't care where the access is coming from (it shouldn't have to either, it's job is not network control)

You should control this at a network level, using the proxy and/or firewall between Confluence and the outside world.

[Nic Brough -Adaptavist-]

No, I'm sorry, you simply can't expect an application (that isn't dedicated to network control) to do this. IP addressing is a function of your network (and I should point out, a doddle to spoof and bypass). Confluence's permissions are based entirely on who you are, not where you appear to come from. You need to do this with something that is designed to do it, not at the application level where it's far too late.

[Marco Dieckhoff]

It's not about network control, it's about content control. Confluence does have mechanisms to allow/disallow viewing of pages. The knows I know are based on anonymous access and user logins, and my question is, if there is an option, or a way to implement it, to work with IP ranges, combined with the possibilities above. A proxy/firewall would not be able to distinguish between a confluence-logged-in user, and anonymous access. As many pages and other resources are internally managed by IDs, it's also nearly impossible to set up some kind of block for specific URLs, as managing a whiteliste would include to add every resource id ever added to the space. (Sorry Nic, was just in between changing to my username when your reply came, did not want to puzzle you)

[Marco Dieckhoff]

Sorry, but cannot see how a network-only solution could work here. Allowing access only to my local network would be no problem. Allowing access only to outsiders, even that would be no problem. But: As soon as I allow any, outside or inside, access to my confluence instance, all anonymous content can be read. As mentioned above, due to ID usage, a simple block regexp or whitelist would not work. So the network connection would have to be aware of the content delivered and it's storage in the database, or logged in user, and that's application level. Now, we do have outside access, and limit that by http (apache reverse) authentication. But as soon as someone is through this proxy auth, and does not log into confluence, he can read everything anonymously. And I cannot get rid of anonymous access, because for one we don't have the neccessary licenses, but even more sincere, we use confluence as starting page on all clients, PC, iPads, otherwise, allowing access to information and web based applications to workers outside, without the need to login. A neccessity to login would not be acceptable for them.

[Nic Brough -Adaptavist-]

And as I stated already, you can't do IP access control at an application level - a) it's too late, and b) Confluence doesn't have the code for it (because it would need to re-implement a whole network security system). The network does NOT need to be aware of content or any of the rest - it only needs to be aware of the source and destination of the exchange of data, along with an authentication to say "although this person is on a restricted IP, they are allowed to reach Confluence" Sounds to me like you need to require authentication to get into your network, even if Confluence remains completely anonymously accessible.

[Marco Dieckhoff]

Yes, we do have that in place: From outside the company, you need to authenticate to access Confluence - or to be more technical: to access the Port 443 on your confluence instance. But as soon as you have access to that port, the network alone can not determine whether you are anonymous or logged in user. It will show anonymous content to everyone. Goal is to have anonymous access from our local network, and no anonymous access from outside. If the answer is, that Confluence can not do that, and cannot be modified (by server administrator and local programmer) do to that, so be it. But "do it on the network level" does not fit the problem, unfortunately.