Confluence logged in users cannot access while anonymous can

[Roberto Rocha Rodrigues]

Hello,

In our Confluence instance we have configured Group AAA to have access to Confluence (Global Permission) to create some pages. And also, Anonymous Access to Confluence is Enabled.

The problem is: users from JIRA that aren´t in Group AAA can´t access Confluence when logged. Confluence shows an 'Restricted access page' instead of treat them as Anonymous. However, they can logoff and access Confluence and all pages.

When Anonymous Access is enabled, I think Confluence should handle users without permission as anonymous because it is very weird they can access when not logged and cannot access when logged... Please, what do you think? Our configuration is wrong?

[Rob Woodgate]

Hi Roberto,

JIRA and Confluence share a login system.  If your users are logged into JIRA then they are also logged into Confluence, and therefore they are not anonymous users.

You said:

"Confluence should handle users without permission as anonymous"

No, it absolutely should not.  By default every space and page is open to everyone; you have to take permissions away from people to tell Confluence that they shouldn't have access.  If Confluence treated users without permissions as anonymous then there would be no way to stop people accessing anything, except to also stop anonymous access.

To solve your problem, create a group for all of your JIRA users who aren't in Group AAA, and give that new group View Only permissions.

[Roberto Rocha Rodrigues]

Hello Rob,

Thanks for your quick response!

I understood your explanation and I only want to know Atlassian's opinion about this functionality / behavior.

These are my considerations:

By default every space and page is open to everyone; you have to take permissions away from people to tell Confluence that they shouldn't have access.

I didn´t take away any permission. In fact, if you only enable Anonymous Access and don´t give permission to your users, anonymous users will be able to access Confluence but not logged users. IMHO, this is not an intuitive behavior and doesn't make sense. You can access after logoff?! This make sense for you?

create a group [...] and give that new group View Only permissions.

Then, you are saying my configuration is wrong or that,  if I want give access to all, I need to set view only permissions to all users, even when Confluence is configured with Anonymous Access = Enabled. This is not practical.

If Confluence is configured with anonymous access, then everyone can read. Why do I need to configure for each new group and user?

[Nic Brough -Adaptavist-]

I mostly agree with Roberto here.  Whilst the behaviour is technically understandable, it is counter-intuitive and not really that sensible.

The reason it is understandable for me is:

• Let's say that you have a space that has anonymous access and a single user who is the space admin.
• Another user has not logged in, so they are anonymous.
• You grant anonymous access.  So the user can see the space.
• The user logs in.  You now know who they are.
• The bit that is counter intuitive, but technically right:  once a user is known, they don't now count as anonymous, so they can't see this space, because the security says "anonymous + space admin.  And only those two"

Not only is this counter-intuitive, it doesn't actually have any use.  I can't see a situation where you'd let an anonymous user see a space but deny it to logged-in users.  (I can see the point of informational text being hidden, but not much else - "you're logged in, so I am not going to nag you to create an account")

[Rob Woodgate]

Hi both,

I really don't see this as counter-intuitive, it makes perfect sense to me.  A user is logged in, or they aren't.  If they aren't, then they are an anonymous user, and anonymous users have specific permissions that can be (and usually are) different than the permissions for a logged in user. 

I agree that Confluence could set base permissions for logged in users to be the same as anonymous users - e.g. if anonymous users can see a page then logged in users can as well - but this would have to be an option that could be turned on.  Just because we can't think of a situation where an anonymous user is allowed to view or edit a page but a logged in user can't doesn't mean such a situation doesn't exist. 

I'd also suggest that the granular control over permissions is on of Confluence's strengths, rather than a weakness.

Roberto - with regard to your situation, yes, I'm saying your configuration is wrong.  I have sympathy for your circumstances and you make a fair point, but this is the way that Confluence works.  If your JIRA members are logged in, they have to be a member of group that has access to Confluence, otherwise they won't be able to access Confluence.

I suggested a view-only group because I assumed you wanted the same permissions for them as anonymous users, and anonymous users normally aren't given permissions to edit.  But that's up to you.  By default there's a confluence-users group with standard view/edit permissions for every space and page, just add all of your JIRA users to that and you're good to go.

[Roberto Rocha Rodrigues]

Roberto - with regard to your situation, yes, I'm saying your configuration is wrong.  I have sympathy for your circumstances and you make a fair point, but this is the way that Confluence works.

No problem that I did a wrong config. The problem was how I wrote. I just wanted to know exactly this, if that is the way Confluence works. Now I know... Thank you!

I suggested a view-only group because I assumed you wanted the same permissions for them as anonymous users, and anonymous users normally aren't given permissions to edit.

I can't. I want to use anonymous access because they are not included in my license count. Moreover, read only permission is what I need for them and is what I would have with anonymous access.  

I believe read only permission without counting in the license was the reason anonymous access was created, but doesn't work well on this scenario. It has been embarrassing to explain to them that they need to logoff to view the content.

I agree that Confluence could set base permissions for logged in users to be the same as anonymous users - e.g. if anonymous users can see a page then logged in users can as well - but this would have to be an option that could be turned on.  Just because we can't think of a situation where an anonymous user is allowed to view or edit a page but a logged in user can't doesn't mean such a situation doesn't exist.

I agree. If such configuration option were created, it would be wonderful. I think it will solve this situation.

Thanks for all the information and the configuration suggestion!

[Nic Brough -Adaptavist-]

I think it's counter-intuitive because of the implications.  Roberto asked this question precisely because it doesn't work the way most of us would naturally expect it to.  The requirement is "I want some read-only users to see my space (without using licences)", and the answer is "Enable anonymous access".  Nothing wrong with that, but most of us would then assume that known users are an upgrade from anonymous users - they'd see everything anonymous users can, and then more.  Not that they'd stop being able to see anonymous stuff because we know who they are!

The default settings tend to insulate us from that though, so it doesn't crop up a lot - we tend to have spaces that are visible to all logged in users, so you get access that way when you stop being anonymous, and you don't question why.

[Rob Woodgate]

I think licensing costs and the joint login are at the heart of this.  Really we're using a suite of software, and we pay per seat for each application in that suite.  But because you log into the suite, rather than each individual application, you end up with this situation: users of one application having to log out to see another application.

In that context I can see how it seems odd.  But from Atlassian's point of view the only option for this use-case would be to provide view-only permissions for logged in users for free, or split the user management functionality.  That provides another option for you Roberto - do any of your JIRA users actually need access to Confluence?  If they don't then I believe (and feel free to comment on this idea Nic) that you can have Confluence user management and JIRA user management separately.  This has its own pros and cons, but it might allow your logged in JIRA users to see Confluence anonymously?

[Nic Brough -Adaptavist-]

Good point, yes, you can easily do

group user is in	JIRA access	Confluence access
JIRA users	Logged into JIRA	anonymous
Confluence users	anonymous	Logged into Confluence
Both groups	Logged in	Logged in
Neither group	anonymous	anonymous

There is one other case as well - if you're using JIRA Service Desk, then you have "customer" accounts with some limited JIRA access (and no costs).  If you're on JSD 3.1 or above, then customers can also see Confluence spaces that are connected to JSD as "knowledge bases" without anonymous access.

[Roberto Rocha Rodrigues]

I haven't thought about this option of split the user management. Thank you for sharing!

If I understood correctly, in this case, we would need to 'duplicate' users (in Confluence user management) who write content. It is not that bad because they are a few.

I don't know if we will use it because we already know that in a near future we will upgrade our Confluence license to match JIRA license due to permissions restrictions we will need. Maybe we can live with this 'logoff to view Confluence' for some time, while we are creating pages and getting used to view / check Confluence.

Will Atlassian create that option ( "if anonymous users can see a page then logged in users can as well - but this would have to be an option that could be turned on." ) that works as "provide view-only permissions for logged in users for free"? or something similar?

[Nic Brough -Adaptavist-]

It's been this way for years, I don't think Atlassian are going to change it.

Yet another option with the "split user management" is another line on the table I gave earlier - have a group called JIRA-and-Confluence, which gives access to both.

[Balázs Szakál _META-INF_]

I can suggest you to trial the Ultimate Permission Manager add-on, which can help you to discover that who can view/edit which spaces/pages and why :) Might be very useful, especially if you have a complex permission system on a huge instance!