Introducing single-space guests beta in Confluence Cloud!

[NidhiRaj]

Confluence is the collaborative content hub for organizations’ teams, but we know not all teamwork happens inside the (sometimes virtual) walls of a single organization. Teams need to collaborate externally — with other companies to build integrations, with agencies to bring marketing campaigns to life, with contractors and consultants to help get big projects over the line.

And now you can do all of that without leaving Confluence!

Single-space guests make Confluence the tool for your team’s collaboration needs, no matter who you need to work with.

Teams don’t just collaborate in Confluence - they collaborate across many essential apps as well. We know partners have questions about how these changes will impact them. In this post, we’ll discuss three details: 1) how this change impacts app pricing, and intended benefits, 2) how you can opt out of these changes if desired, and 3) technical implications.

Read more about the beta version of single-space guests feature on our Atlassian community post.

Long term growth - for apps as well as Confluence

After extensive competitive analysis and user research, we found that allowing guests to use Confluence free of charge and fall in love with it as a collaboration tool will drive more paid licenses (and more revenue) over the long term, than charging for guests would. So we have made the decision not to charge for guests.

This also means that by default, guests will be able to use the apps on the Confluence instance for free.

We believe this will similarly drive more revenue for you in the long term as more users get to try and fall in love with your apps and convert into paying customers with their own instances of Confluence.

We encourage you to monitor and see what guest usage is like during the beta phase of this feature, to ensure your customers have the best experience. However, if it becomes a challenge, or you aren’t seeing benefits from the increased usage of your apps, there is a way to block guest access to your apps by following the steps in the section titled “How to control guest access to apps”.

What else you need to know

• No change to underlying permissions model
  Apps are associated with system users that are bootstrapped with permissions / group enrollments. API requests from apps are checked against their permissions so an alteration of permission schemes can impact apps. As a feature, single space guests is based on the same underlying model of permissions that already exists, i.e.current permissions model works the same for guests as it does for regular users. Guests will show up as normal users for third-party apps as well. However, guests are restricted from performing certain actions like installing a new app on the instance or changing the permission of page/space/site. Detailed information on what a guest can and can’t do to follow.
• No changes to existing APIs
  You do not need to take any additional actions since there are no changes to APIs. There is no removal of a REST endpoint, path parameter or query parameter. The user search API also allows to search for guests now using the additional sitePermissionTypeFilter param.
• No changes to existing agreements
  Marketplace Partner Agreement continues to apply to Marketplace Vendors. The guests’ use of an App would be covered by the End User License Agreement between the Customer (who owns the Confluence space) and the Marketplace Vendor, as a “user” of the App. Also, use of Confluence External Collaboration is a Beta Version subject to Section 14 of the Cloud Terms of Service.

How to control guest access to apps

There are two options for disabling guest access to your app for Connect, listed below. The entire Beta period of single-space guests (4+ months) allows you to implement these opt-out changes before we make the feature generally available, if you wish to not participate.

1: Use Connect conditions

In the Connect application descriptor, user_is_external_collaborator condition may be specified to display the web item if the condition is met. Setting the invert field to true in this condition hides your app if the user is a guest.

Example:

"conditions": [
    {
      "condition": "user_is_external_collaborator",
      "invert": true
    }
]

Note: Connect conditions are not supported for some modules, like macros, webhooks, and blueprints.

2: Use context parameter

We’ve added a new condition user_is_external_collaborator . We’ve also added a new context parameter user.isExternalCollaborator. Apps will be able to receive that context whenever Confluence calls a URL to the app. Then the app can decide how to handle the call.

Share your feedback

Marketplace Partner-specific resources are published on the Partner Portal here*. We welcome your feedback as we provide developers and partners with a consistent way to stay updated with Atlassian changes.

We understand this is a completely new feature that provides advanced collaboration and could present some unanticipated challenges or use cases. To help mitigate these risks, we’re releasing it as a beta and are prepared to make changes and improvements based on feedback.

If you have any concerns or questions about these changes please don’t hesitate to drop a comment below so we can take any necessary steps.

Thank you in advance for working through these changes and for your continued support!

–

*Marketplace Partners with at least 1 paid-via-Atlassian app qualify for Partner Portal resources. If you experience any issues getting access, and meet the eligibility criteria, please open a support ticket and our team will work to get things resolved as quickly as possible.

Best,
Nidhi Raj
Confluence PM

[marc]

Hi @NidhiRaj ,
Thank you for posting the announcement also here.
I believe there is a risk to leaking information in the way the guest users are implemented.

As I understand, guest users can’t @ mention other users. However some apps implement a “user picker”. Through this user picker, guest users can get to know other users, while that should not be the case.

Related to that, some apps do workflows and change the permissions of content based on what users do. If a guest users takes such an action, the permissions of content can be changed by an app if the app is not aware of the guest user status. This is in contradiction to the expected case that:

@NidhiRaj

However, guests are restricted from performing certain actions like installing a new app on the instance or changing the permission of page/space/site.

I believe there might be many more cases where (unintentionally) security issues might arise, i.e. through actions in webhooks initiated by a guest user. Many apps do an action based on the underlying permissions model and the understanding that the user is a regular user. If that changes, the underlying permissions model changes by adding a new permission type for guest users.

Can we get more detailed information on the impact of information leakage, and what apps are supposed to do?

[jens]

Hi, thanks for the heads-up and the beta phase!

Our exporter apps use user impersonation (connect scope ACT_AS_USER) to access content in the scope of the user launching an export. Will this also work for guest users?

For data residency support we’re planning to move user-created data from our servers to Confluence as custom content. We were planning to designate a single space as “config space” where shared data to be used in all spaces would be placed in. The limitation for guest users to have access only to single spaces conflicts with this of course. Any recommendations to handle this?

Will you move them into a ‘guests’ group etc. so it’s easier to control access within spaces via page restrictions?

Thanks,
Jens

[scott.dudley]

Hi @NidhiRaj ,

Thanks also for the information.

1. I second Marc’s question about the user-picker and potential security issues. As part of this, I understand that you have planned to supply a context parameter indicating whether the current user is an external collaborator or not. This parameter is partially helpful, but this information also needs to be surfaced in the correct domain (the user object). Some apps may be doing maintenance tasks on separate threads, handling webhooks, or otherwise manipulating user data and needing to decide how to treat a user outside of a web context. How soon can this be done, so that when we fetch a user object via API, we get the external collaborator status? And how can apps retrieve the ID or key of the single space to which the user has access?

2. Introducing the concept of partial functional access to Confluence for a subset of users raises a set of concerns, and it’s a bit of a slight of hand to say that apps can truly “opt out” of this feature. For example, if a Confluence app provides a macro, what would it even mean to “opt out”? The idea of “External collaborators can’t create new instances of macros” is one interpretation, but there will also be apps whose resources are consumed just by viewing macros. And even the first interpretation of preventing creation could be tricky (Can external collaborators edit existing macros? What happens if they edit a page containing one?).

3. Can you confirm that external collaborators are prohibited from having personal spaces?

4. This is described as a four-month beta, but per the rollout schedule on the partner portal, this is actually rolling out live for all paid sites soon. This feature is apparently already live today for some customers, so providing limited information like “Detailed information on what a guest can and can’t do to follow” is really far from ideal. What significance does “beta” have in this context, when it is rolling out to everyone? It seems like Marketplace partners should have had much more advance notice of this entire feature, and also have had an Atlassian involved in the design process who could act as a champion for Marketplace vendors.

Scott

[remie]

Given the questions raised in this thread it is absolutely astonishing that the Confluence team did not consider this feature to have any impact on partners / 3rd party apps. @dmeyer can you please shed a light on what happened here (esp. considering your past tenure in the Atlassian Marketplace team) and how this is going to be prevented moving forward?

[marc]

@NidhiRaj How can we actually test the single-space guest feature?

[NidhiRaj]

Hi All!
Thank you for engaging with the feature and for your questions.
With regards to security concerns - this is no different than today when a space or page may be restricted to only specific people yet, there may not be that extension of the restriction into an app that has access to the page or space. Information that is shared into apps and the accessibility of that information is the responsibility of the customer to ensure the right security measures are in place.
I have now included the new context parameter that we have created, giving you option 2 to control guest access to apps.
The feature will be rolled out to all paid customers by end of next week. You can test single-space guest the same way that you would test any other feature that is on the paid editions of Confluence.