How to handle 'public' network user access when migrating from Server to Cloud?

[Michael Elso]

As we consider moving our Jira, Confluence and Bitbucket instances (which are behind our firewall and not available to the internet) to the Cloud hosted versions, what's a recommended way to handle what is currently our internal 'public' access to reference information (non-contributors) to our network users? Currently, we have about 25-30 users that create and manage content (primarily Confluence), and about 250 other users on our network that reference or view it.

By going to the Cloud hosted version, will we have to get licenses for the 250 reference users to be able to continue to access the information since this is internal business process info and not meant for the entire Internet to view, or is there another solution I haven't found yet? A shared Guest login, limiting access by IP, or some other scheme?

So far, our setup has mostly been used for our internal developers, a few departmental managers, and a handful of vendors. Going from 30 - 300 licenses is quite a jump, plus Access on top of it to sync AD is going to put the move out of our reach.

Any insights or explanations are greatly appreciated   -- Mike

[Charlie Misonne · Accepted solution]

Hi Mike,

That's an interesting question.

The first thing that comes into my mind is an IP filter indeed. This is available for premium plans only. See Specify IP addresses for product access. It is also the recommende solution on Confluence: Read-only access and licensing.

And if you are using Confluence knowledge bases linked to Jira Service Management projects you can enable access to those Confluence spaces for unlicensed users (the JSM customers). Give Access to Unlicensed Users from Jira Service Management.

[Michael Elso]

Thank you Charlie for the response, and the links! It looks like IP Allowlisting would pretty much give us what we have now, using our VPN to get to Jira/Confluence like we do now for external users. I was hoping to avoid the extra step of going through the VPN for licensed remote users though. 

How about this; what if we create an account in Jira, but not assign them a license for a product, allowing them access to the server as 'Guest', but unable to add/edit/delete content (except maybe comments!). That way I could use Access to sync Active Directory accounts, control licensed user access, allow 'public' access limited to AD without the VPN, and not destroy my budget!

I quickly tried setting up an testing account on our existing Jira Server, and that didn't work, but I'm not sure if I may have missed something.

Any thoughts on the above, and thanks again for your reply!  -- Mike

[Charlie Misonne]

Hi Michael,

I understand what you're trying to achieve but I'm afraid it's not possible.

You can add the users to Atlassian Access with the option "Has access on site" and without Confluence license. But those users will not be able to login into Confluence. They really need a Confluence license to do so.

This is true except for Confluence spaces linked to a Jira Service Managment project. You can grant unlicensed users access to a Confluence space in read only mode (without the ability to add comments).

[Michael Elso]

Charlie,

Thank you again for your quick response, and I truly appreciate your help!

Since I'll be new to Jira Service Management, I'll see if that can accomplish what I want. Otherwise it looks like IP Allowlisting will be the most likely path.

[Charlie Misonne]

Ok! Good luck :-)