IP Allowlisting by Space?

[Alec Fields]

Good Morning!

Our company is fairly new to Confluence. We have clients that are large organizations, and each organization has their own Confluence space. We would like to be able to open the space up to the entire organization as anonymous users with read-only permissions. 

I was excited to learn that anonymous access can be IP allowlisted, but it doesn't look like you can set a list by Confluence space. Is this feature being discussed or is it already on the roadmap?

As a potential workaround: If I have 2 spaces that are read only to anonymous users, will anonymous users of these spaces be able to navigate from one space to the other in Confluence? My thinking is I could send each organization a link to their Confluence space, and they wouldn't be able to access the other organization's spaces without a link. (even though technically they would have permission to view the space since both organizations would be on the IP allowlist)

Interested to hear thoughts from the group. Thanks!

[Fabio Racobaldo _Herzum_ · Accepted solution]

Hi @Alec Fields ,

welcome to the Atlassian community!

Allowlisting is per instance basis and not per space basis.

About your workaround, if two different spaces are visible to anonymous user, he will be able to navigate through both spaces so your workaround will not work.

A possible workaround is to create a company user and provide access to that user per space basis. The pro is that you can manage permissions, cons is that a license will be consumed.

Fabio

[Alec Fields]

Thanks Fabio! If we have a company user that is shared by multiple individuals, can they be logged in at the same time?

[Fabio Racobaldo _Herzum_]

Hi @Alec Fields ,

yes, the could login at the same time.

[Nic Brough -Adaptavist-]

But you should never have a shared account, it breaches your licence, and can't be audited (it's illegal in most industries)

[Alec Fields]

Understood. What would be your solution? It seems like overkill to have a premium licenses for 100+ people just so they can read a knowledge base.

[Nic Brough -Adaptavist-]

It's a security nightmare, let alone audit.

To use a knowledge-base, either make the space anonymously accessible, or use it as part of an ITSM project (Jira Service Management has customers, who don't consume paid licences, and automatically get access to spaces set up as Knowledge bases)

[Alec Fields]

In testing this out, it appears that this won't work for our situation either. We will have spaces that we want Group A to see but not Group B. When you make the knowledge base visible to all logged in users, Groups A and B could both see each others spaces.

It doesn't seem like there is a way to do what I want it to do without either paying for multiple licenses or exporting the pages as HTML and posting to a webpage that our organization can control access to. Do you agree?

[Nic Brough -Adaptavist-]

I'm not quite sure what is happening here:

You say "When you make the knowledge base visible to all logged in users, Groups A and B could both see each others spaces"

A knowledge base is a single space in Confluence.  If you make it anonymously available, then the world can see it, but it has no effect on how group A and B can see other spaces.

So I'm a bit lost on where the problem is.  Allowing "all logged in users" to see "space 1" can't have any effect on the groups that can see space 2 and 3

[Alec Fields]

So I'm a bit lost on where the problem is.  Allowing "all logged in users" to see "space 1" can't have any effect on the groups that can see space 2 and 3

The problem is that in my case, spaces 1, 2, and 3 need to be tied to separate KBs through separate Jira Service projects. With the "all logged in users" being required to read w/o a license, I cannot keep a user in space 1 from seeing spaces 2 and 3

In my testing it looked like all 3 spaces would be visible to a logged in user, even if they aren't a member of the accompanying Jira Service project.