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
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.
Thank you for your answer
A good very way to start the discussion
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"
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?
I'm struggling a bit. I think I understand the concepts. Here's my test configuration:
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.
A few questions:
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:
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.
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 confluence-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
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.
Removing a user from Confluence-Users created a big problem for me.
I attempted to configure the following:
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).
Hi team, I’m Avinoam, a product manager on Confluence Cloud, and today I’m really excited to let the Community know that all customers can now try out the new editing experience and see some of the ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs