What are the best practices with Confluence restricted pages regarding outsourcing?
Asked by Sebastien Ribiere:

We have sensitive information on our Confluence we don't want to share with anyone who has access to our instance.

Today each space administrator has his/her specific scheme to handle that. But now we want to standardize the "security" scheme of every space.

Has anyone any thought about this topic? any reference about best practices?

Thank you in advance


Answers:
author: Rob Woodgate
body: Best practise is to create groups, with each group having view permissions to just the spaces that the people in that group should be able to view.

Add users to the appropriate group(s) in the User Management console. Then they'll only be able to see the spaces that the group(s) they're a member of can view.

Remember to remove the confluence-users groups from the permissions for each space, as this is the default group that everyone is a member of.

comments: author: Sebastien Ribiere
body: Thank you for your answer

A good very way to start the discussion :smile:

That way, you implement security at the space level.

But my concern is also about the security within the space.

I'm aware about page restrictions but I wonder how would you structure a confluence space to limit access to some "sub-spaces"


author: Rob Woodgate
body: To structure a space so that people can only see parts of it you need to understand Confluence's inheritance and cascading structure.

Page permissions use inherited and cascading permissions.

"Inherited permissions" means pages you create inherit their permissions from their parent page.

"Cascading permissions" means changing a page's permissions will change the permissions of the existing child pages as well.

All new child pages **inherit** their permissions from their parent.

Changing the **View** permissions for a parent will **cascade** to all existing child pages, unless you've set specific permissions on those child pages individually.

Changing the **Edit** permission for a parent will **NOT cascade** to existing child pages. If you want to set Edit permissions on the child pages you'll have to do it on each page individually.

Does that cover what you want to do?


author: Sebastien Ribiere
body: Yes, thank you for your insights


author: Brian Catanzaro
body: I'm struggling a bit. I think I understand the concepts. Here's my test configuration:

* **Group A** (only permitted to see Space A)
* **Group B** (only permitted to see Space B)

The only user that is a member of both groups is ++me++.

I am logged in as another user to test the configuration and it is ++not++ as I expect.

1. **Log in as a user in A** . I can reference users from B merely with [@username](https://community.atlassian.com/t5/user/viewprofilepage/user-id/1677494). That's not what I want. I should never be able to see users from Group B, right?
2. **Log in as user in B.** This user was reconfigured to not be in Group A and only be in Group B. However, they can still see Space A. That's also not what I want.

A few questions:

* Is logging in as another user an effective test?
* When using Confluence Server, I had to reboot at one point to get settings to *stick* . Obviously I cannot do that with Confluence Cloud. Do I need to wait for configurations to take effect? Do I need to do something to make them *stick*?


author: Rob Woodgate
body: Hi Brian,

Any user can use a @mention to tag any other user, regardless of which groups they're in. There's no way for you to prevent this, as Confluence doesn't give you the functionality to prevent it.

There's nothing you should need to do to make a permissions change "stick" - once you make the change, the change is made, and that's it. I've personally never had to wait for a change to ripple through the system. So for your second scenario, where users in Group B don't have permission to see Space A, is best explained in one of three ways:

1. The user in group B is also a member of a group that has access to Space A (most likely a default group like confluence-users).
2. Group B does have access to Space A.
3. There is a bug in the permissions.

Options 1 and 2 are the most likely, but if you're absolutely sure the user isn't in any groups except Group B, and Group B definitely doesn't have access to Space A, you should log a ticket with Atlassian so they can help troubleshoot it.


author: Brian Catanzaro
body: I run a consulting practice. Clients should not interact nor know each other's names. It seems that I cannot implement multiple clients on a single Confluence site; I need to have ++*(x1) site for each client*++ if I don't want them to know each other (by name).

Do you believe this to be true?

I removed users from c*onfluence-users*. I thought that removing them from this Group would prevent them from having any group in common. This (of course) was a disaster.

Now that I have put them back as *confluence-users* , the Space access works properly when testing with *log-in as user*. Seems like a potential bug


author: Rob Woodgate
body: Hi Brian,

Yes, if you don't want users from different clients to be able to see each other then you'll need one instance per client. Bear in mind this is not a bug or an oversight: Confluence is a knowledge base, and it's designed to be open to the users, not closed. If you want to lock it down and be very proscriptive about exactly what any given user can see then you'll have a lot of work to do, because it's designed for the opposite of that.

I've removed users from confluence-users and given them access to just one space by adding them into a bespoke group, and it's never caused a problem. If you're having difficulty configuring the permissions the way you want (and especially if you think there's a bug) you should log a ticket. Atlassian's technical support is very good, in my experience.


author: Brian Catanzaro
body: Removing a user from *Confluence-Users* created a big problem for me.

I attempted to configure the following:

Groups

* **Group A**
* **Group B**

Users

* Me: **Group A, Group B, Confluence-Users**
* User A: **Group A**
* User B: **Group B**

When I removed users from *Confluence-Users* and tried to test it, I *logged in as user* and I got a screen from Confluence that said it was "preparing a landing spot". That screen never went away, so I assumed that removing them from *Confluence-Users* disabled them from using the application *Confluence*leaving a user without a page to display.

I got stuck in this mode. I could not even log in as myself since I could not log out of the users I was logged into (e.g. I was stuck as User A until it timed out).


Tags: cloud

confluence-cloud