Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

What are the best practices with Confluence restricted pages regarding outsourcing?

Sebastien Ribiere October 19, 2016

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

1 answer

1 accepted

2 votes
Answer accepted
Rob Woodgate
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 19, 2016

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.

Sebastien Ribiere October 20, 2016

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"

Rob Woodgate
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 26, 2016

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?

Sebastien Ribiere October 26, 2016

Yes, thank you for your insights

Brian Catanzaro October 8, 2018

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.  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?
Rob Woodgate
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 9, 2018

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.

Brian Catanzaro October 9, 2018

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

Rob Woodgate
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 10, 2018

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.

Brian Catanzaro October 11, 2018

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).

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events