RFC-9: Blocking Guest Access to Apps

[MorganWang]

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines : keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Summary of Project

We plan to block Guest users from using/interacting with an app for most UI-heavy modules as a security measure to prevent apps from accidentally leaking information to Guest users who are limited to access content within a single Confluence space.

• Publish : Apr 28, 2023
• Discuss : May 15, 2023
• Resolve : May 31, 2023

Problem

The Guest feature was released as a Beta in October 2022 and we are now preparing to make the feature generally available in mid July 2023. Standard+ Confluence Customers can add up to 5 free Guest users for every 1 Paid Seat. Guest users can be assigned to only 1 Confluence space and their permissions are limited to creating, editing, commenting, and viewing pages within that Confluence space. Guest users cannot view the user directory, mention other users, or create their own spaces. For more details about this feature, please read this announcement.

Guest users were able to use Apps for free in Beta. Why are we now deciding to block Guest users from using Apps?

During the Beta, we identified a potential data privacy concern where Guest users, who are given access to a single space in a Confluence instance, could potentially view and access information across any spaces using Apps. The main security issue is with Apps having more access than Guest users. When an App displays something on a page/space, it can get data from other spaces that it has access to (by using the app’s permission), and exposing that to Guest users. Apps are installed and priced for all users wall to wall within an instance and there’s no way today to:

• Limit licensing/usage of apps based on user role type
• Limit licensing/usage of apps based on Confluence Space

By allowing Guest users to use Apps and asking Partners to enforce checks on Guest permissions, we are subjecting our Customers to use the Guest feature at their own risk or not use the Guest feature at all.

Proposed Solution

User Experience

Guest users will not be able to see content rendered by some Connect Apps. Here’s what it will look like for Guests:

Impact on Connect Modules

We have prioritized blocking apps with the highest usage by Guests starting with Connect Apps.

Connect Modules - Guest Access Blocked

1. Content Byline Items: Content byline items will not be shown to Guest users.
2. Custom Content: Similar to content properties (mentioned below), apps will remain to be able to create, update, read and delete custom contents, including all API operations around it. There is a similar risk on apps storing confidential data within the body of the custom content, but this risk is the same as having any other content on a page or blogpost. UI components (view, edit and list) of the custom content will be blocked, as these components are general pages.
3. Macros (Dynamic content macro and Static content macro): Macros will be blocked and won’t be shown to Guest users (see image above).
4. Page: General pages will be blocked and won’t be shown to Guest users. Post-install pages and Configure pages will NOT be blocked, as these are only accessible to site admins and not Guest users
5. Web Item, Web Panel, Web Section, Dialogs: All the web fragments and dialog UI elements will be blocked and won’t be displayed for Guest users. Publish condition’s dialog will handled differently and will not be blocked.

Connect Modules - Guest Access Enabled

1. Blueprints: No change in behavior. Blueprints are app defined templates, and risk of accidentally exposing data here should be pretty low.
2. Content Properties: Apps are still able to create, update, read and delete content properties, including all API operations. Guest users CAN access content properties via APIs, so there’s risk that if apps store confidential data in content properties, it may be easily accessible.
3. Publish Conditions: Publish conditions will not be blocked, and behavior should remain the same. Publish conditions can also define a dialog URL, which, if defined, opens up a popup when “Publish” is clicked. The risk of accidentally exposing data here should be pretty minimal. Publish condition’s dialog will handled differently than the general Connect dialog as above, so publish condition’s dialog should not be blocked.
4. Webhooks: There won’t be any change in behavior for webhooks. Apps will continue to receive webhook events even for operations done by Guest users.

Connect Modules - Guest Access Not Applicable

1. Admin Page: Guest users are not able to access admin pages, so behavior will not change
2. Space Tools Tab: Space Tools Tab will not be blocked, as Guest users shouldn’t have access to the space settings.

Impact on APIs

For the most part, APIs will not be affected, so any API calls that any users and apps can execute will remain the same, with the exception of a few cases:

• Any APIs that will generate a “view” of the macros will return a view that says “You don’t have access to see this content” (final copy pending). This includes getting the “view” or “export_view” of a page with a macro, body conversion APIs.
  • A regular user, or an app calling the API for a regular user will get a response of the rendered macro. This means an iframe for dynamic ones, or rendered element from the app for static ones.
  • For Guest users, the “rendered” macro will be blocked (see design above), and no calls to the app to render the macro will be executed.
• All other APIs will remain the same, and the same permission checks will still apply.
• For more reference on impact to APIs, see more details here.

Impact on Developer Experience

We believe most app developers will not need to make code changes to apps to support guest users. The only difference would be that Guest users wouldn’t be able to access their apps, especially the UI modules as defined above.

But there’d be special cases where apps may want to add some special handling for Guest users to handle them differently. More importantly, app may want to have additional control for Guest users.

As mentioned above, apps will continue to receive requests from Guest users in some cases, like webhooks, and apps may want to handle Guest users differently. For example, apps may want to completely ignore webhooks coming from Guest users, or for an app that sends notifications after receiving webhook events, they may not want to send notifications to Guest users. More information on how to recognize Guest users can be found here.

What kind of special handling would App Developers need to consider to handle Guest users?

Apps can have insights on the whether the user calling their apps are Guest users or not. More details here. Apps can use this information to decide whether or not they’d want to handle Guest users differently

How might App Developers easily determine impact for their own apps?

Review the Impact on APIs and Impact on Connect Modules sections above and cross-reference them with your app architecture to determine whether changes are necessary to gracefully handle guest users.

How might App Developers prevent scenarios that pose data privacy risks for Guests?

• Check which user is currently logged in and whether that user has the Guest role
• Ensure that if your app is storing data it is not leaking data across multiple spaces for Guests.
• Ensure your app is only accessing and rendering information from the current space that the Guest is in.

Actions

Known Issues around Broken App Experiences

Apps that need the UI module as part of the whole app experience

These will be apps that will have a broken experience if we block a certain part of the experience. An example is the Confluence Slack app using the General Page UI module to do the OAuth dance. A Confluence link may be pasted to Slack, and it’ll ask the Guest user to authenticate, which they’ll be redirected to a general page. But since we’re blocking general pages, they wouldn’t be able to authenticate.

Another example of apps that might get affected are apps doing document control, where page approval and status are done through content bylines.

Apps that track analytics and usages

Some apps uses analytics tracking by adding “hidden” code in footers or headers (web panels). Since web panels will be blocked, the analytics code also won’t be executed.

Request for Feedback

• How might we improve the blocking experience?
• Can you identify other modules or areas where your app could show data to a Guest user that we haven’t considered?
• Is the information provided sufficient? Do you need additional information to programmatically identify the impact of this change?

[BorisBerenberg]

I would like to see the error phrasing adjusted to show that this is Atlassian’s responsibility and not the apps. The current copy may result in an increase in support tickets and missed customer expectations.

[marc]

I agree with @BorisBerenberg , and would recommend to show a text like:
“Confluence does not allow access to this content for guest users”

This makes it clear that Confluence/Atlassian is blocking access, not the apps.

@MorganWang Are you aware of this post: Introducing single-space guests beta in Confluence Cloud! - #2 by marc

[daviddrawio]

Could we have an option to opt out of this? We follow only Confluence permissions, only store data within Confluence and have no method to work around confluence permissions exactly for this reason.

[scottohara]

@marc

This makes it clear that Confluence/Atlassian is blocking access, not the apps.

I’m reminded of the experience with macros in the mobile app showing as “broken macro”, which led to numerous support tickets from customers who thought there was a problem with the macro as opposed to it being a limitation of the mobile app’s ability to display them.

(See: https://jira.atlassian.com/browse/CONFCLOUD-57654 and Broken macro in iOS/Android app )

I don’t know if that is still the case with mobile (and the above ticket was closed as stale many years ago), but I would like to see Atlassian avoid similar confusion this time around.

[remie]

Thank you @MorganWang for such a detailed RFC and for bringing this to the Atlassian ecosystem far in advance to allow us to voice our opinions!

I must say that I’m a bit taken aback by this proposal, as it basically translates to “we don’t trust or partners nor our customers”, both expressed nicely in this sentence:

@MorganWang

By allowing Guest users to use Apps and asking Partners to enforce checks on Guest permissions, we are subjecting our Customers to use the Guest feature at their own risk or not use the Guest feature at all.

Based on the request for feedback, it becomes clear that the decision has already been made and that the discussion on whether or not guess access to apps will be blocked is not part of this RFC. So feel free to ignore this comment, but I’m going to voice it anyway:

Atlassian, you are making a mistake.

If you are really scared that Atlassian Marketplace Partners can leak customer information, you should stop selling apps. We can leak information on any given Sunday if we like. This is a risk your customers are fully aware of when they consciously install and purchase apps.

Telling Partners that they cannot be trusted with the responsibility of handling customer data, with implementing proper permissions checks (which we are already doing???) and telling customers that they are incapable of deciding for themselves whether or not they trust app vendors is… a bit rude and patronising.

I would have somehow understood if you would have told us it was to difficult (or not a priority) for Atlassian to implement a proper mechanism for customers to have control over which app (or even macro) they want to enable guest usage on. I can totally understand that you just want to ship this feature and not want to deal with the intricacies of adding guest support for apps. But what happened to “open company, no bullshit”?

I’m also curious how, in light of this decision to not trust partners nor customers, Atlassian views having apps on public pages/spaces in Confluence? We can also leak data on those pages

[daviddrawio]

I think there’s a fairly simple solution here.

@MorganWang

When an App displays something on a page/space, it can get data from other spaces that it has access to (by using the app’s permission)

Doesn’t this boil down to whether the app has the “Act on a user’s behalf, even when the user is offline” permission? Otherwise, the app is only acting with the permissions of the user logged into that browser. If the app doesn’t have that permission, please explain in technical detail what the attack surface is.

[ernst.stefan]

I’m not affected as a vendor by this proposal, but I know a lot of customers that already rely on the guest feature and disabling essential macros and plugins will make guest accounts unusable for them, so I expect quite a lot of negative feedback from this side.

I would suggest letting vendors opt in to the guest feature by explicitly enabling guest access in their apps

[PhilipFeldmann]

Agreed with @BorisBerenberg and @marc. If you cannot add an opt-in as suggested by @daviddrawio, please at least make it clear to the customer that the macro has been disabled by Atlassian.
As vendors, we want to focus on building features, rather than dealing with support requests and bad reviews that are not even on us.

[remie]

I think what they are referring to is that the app itself also has a user account with privileges based on the app scopes. If the app has ADMIN scope, it can call the API with its own credentials (not impersonation) retrieve data and (unintentionally) leak that to the guest account.

Atlassian is basically saying they don’t trust us to be able to determine which data should not be exposed to guests.

[daviddrawio]

Thanks for the clarification. admin scope is relatively rare looking through a selection of apps. What about:

• allow those without the scope to display automatically, unless atlassian can provide a security reason not to do this
• provide conf admins with a switch to enable/disable it for apps with admin scope, disabled by default.
• Display the message “this app has been disabled for guest users for security reasons”.

[remie]

Oh sorry, I should have elaborated that the ADMIN scope was only an example. Technically, the unintentional data leak can also occur with just READ scope.

Let’s say your macro is to display a list of spaces (again, just an example), or show which users have access to which space, or even a list of similar pages (incl. titles). The guest user typically does not have access to this information, but the APP user with READ scope does.

If the Marketplace Partner is using their own APP credentials to fetch this information on the back-end (instead of doing it in the front-end with AP.request or with impersonation), the default permission checks from Confluence are not applied. Unless the vendor has implemented permission checks themselves, the macro might leak this information to the guest user.

[daviddrawio]

@remie

The guest user typically does not have access to this information, but the APP user with READ scope does.

A client-side call by an app across the bridge should have the same permissions as the user logged into the browser. If that’s not the case that strikes me as a security hole. Is that really true?

If the Marketplace Partner is using their own APP credentials to fetch this information on the back-end

OK, but that’s if the app has a back-end and some kind of token exchange for auth. For a pure client-side app with no back-end that’s not the case. Maybe this isn’t such a common pattern, but I’m guessing that draw.io will be in the “apps with the highest usage by Guests starting with Connect Apps.” list. This would light up our service desk like insert date where your country uses lots of fireworks.

But there’s probably little point you and I working out the details of this without someone from Atlassian expressing an opinion.

[remie]

Oh I agree that Atlassian will need to answer this. I’m just trying to see if we can clarify all the possible use cases. Given that they failed to address this properly in the first run, perhaps we can provide them with language that makes it more clear for us.

So here is my shot at it:

• Client-side access to Confluence API using AP.request
• Client-side access to Confluence API using AP.request that requests app entities
• Client-side request to backend API that uses impersonation to access Confluence API
• Client-side request to backend API that uses app service account to access Confluence API with proper permission checks
• Client-side request to backend API that uses app service account to access Confluence API without proper permission checks
• Server-side background jobs hat use impersonation to access Confluence API
• Server-side background jobs that use app service account to access Confluence API with proper permission checks
• Server-side background jobs that uses app service account to access Confluence API without proper permission checks

More details
The client-side request to the Confluence API to request app entities is not a safe operation, as in this case the AP.request will impersonate the app, and not the user. This way you the app can leak information to guest users that should not be available (assuming that the Confluence API did not implement proper permissions checks for guests on that endpoint).

The two options with question marks are potential safe operations but require the availability of an API to check if content is available for the guest user. We can only do proper permission checks if Confluence allows us. If it is not possible to do permission checks for guest accounts, these two options can be ignored.

The last three options (server-side background jobs) are probably very uncommon, but still possible. For instance if the app allows users to schedule long-running jobs with the option to sent an email to allow them to download the content.

So there are basically two scenario’s in which data leakage can occur: when the backend of the app uses the app service account to access Confluence API and does not perform proper permission checks on the content it receives. This can be either based on a client-side request or during a background job.

@daviddrawio based on this list, I would say you are right to state that a pure client-side app with no back-end will not leak any data, as it will use the bridge and do not use app entities. We should be able to assume that the bridge respects access permissions.

[james.dellow]

Putting aside the issue of trust, isn’t part of the problem that past changes have raised the security bar. So apps that didn’t previously need to bother with JWT, now have access that they don’t really need.

[scott.dudley]

The premise in this RFC is that the guest user feature creates a unique permissions situation for which the response should be the blocking of all third-party apps.

The RFC mentions the following decision point:

During the Beta, we identified a potential data privacy concern where Guest users, who are given access to a single space in a Confluence instance, could potentially view and access information across any spaces using Apps. The main security issue is with Apps having more access than Guest users. When an App displays something on a page/space, it can get data from other spaces that it has access to (by using the app’s permission), and exposing that to Guest users. Apps are installed and priced for all users wall to wall within an instance and there’s no way today to:

When the guest user feature was announced, Atlassian said that there would be no change to underlying permissions model. As far as I can tell, this is still mostly true. Aside from the ability to at-mention users or see the user directory, I do not see how guest users are any different from (say) a paid user who only has access to one or two spaces.

Yes, app user accounts generally have more permission than the current user account, but this has always been the case, and it is not something new for guest users.

In both scenarios (a guest user and a regular user with a limited permission set), it is possible for an app to accidentally leak information. And as Remie pointed out above, an app doesn’t even need to have “ADMIN” scope to do this: simply making a request from the back end using its own app credentials (rather than impersonating with ACT_AS_USER) could be sufficient to inadvertently disclose information, since the app user typically has system-wide access.

So why are guest users treated differently here? This change would add significant handicaps to the user experience for partners, and apps that do handle permissions properly will still be penalized in terms of excessive support tickets and broken features.

For apps that do not handle permissions properly, this issue can already be addressed through bug bounties and raising incident tickets in the Atlassian ecosystem security project. And these apps were broken to begin with anyway, with or without the guest feature.

For the slight permission differences (like user directory access) that require apps to act differently from the current permission model, Atlassian provided a halfway solution of introducing a context parameter, but when the community asked for a way to get the “guest user status” from the user REST API so that the user’s status could be determined in other contexts, I could not find any response.

If Atlassian still wants to go ahead with this plan, I second the other calls to allow apps to opt-in to being accessible by guest users through the descriptor/manifest. Apps that are not regularly maintained will be excluded from guest access by default, which solves your problem, and those apps who do want to support guest users will have to make manual changes and effectively declare that they are compliant.

Also, the post suggests that guest-disabled apps will still receive webhooks, and that the apps may want to handle webhooks differently for guest users. I admit that haven’t looked recently, but I don’t believe that guest users are actually identified as such in the webhook payload, so it is not currently possible to do this (absent the REST API I mentioned above).

PS: There is some irony here in this app-blocking “feature” being rolled out only to Connect apps and not Forge…not just the irony of the rollout being an exception to the “Forge-first” mantra, but it’s especially poignant in that Forge does not even support the ACT_AS_USER feature that is essential for server-side permissions trimming, which is what vendors need to prevent this type of vulnerability.

–
Edit: OK, the last paragraph is more calling out a Connect-on-Forge shortcoming, rather than Forge overall (which I admit does have asUser())…but this is still a problem for Connect-on-Forge, as well as straight Forge for non-UIKit modules, background processing, etc.

[marc]

Thanks @scott.dudley for describing the history of this change.
We trusted Atlassian that the change to guest users would not require us to do different permission checks. I think it is in line with the announcement that Atlassian now is going to block access to apps for guest users.
Our app would leak information to guest users, if guest users would get access to our app. This is not by a broken permission model, but due to the design and intended use case for the app. The is mainly designed to be an internal tool, and e.g. has a user picker component. A guest user could use this user picker component and view users outside of their assigned space. This is by design, because our apps let users perform certain actions in a space where they have only read access, and assign users certain tasks to users in a different space.
So I’m quite happy that Atlassian will block app access for guest users.

[remie]

@marc thanks for sharing this, because I think it is good to have a use case that highlights the actual problem that this RFC is trying to address, instead of just discussing hypotheticals!

Would you agree that, instead of blocking guest access for all apps, either one of the proposed alternatives would also work for you?

1. Atlassian adds an opt-in for apps for those that feel confident they do not leak information
2. Atlassian allows you to identify guest users in your app so that you can implement your own notification banner that you do not support this

[marc]

Hi @remie ,

My impression is the primary issue is: What do Confluence users expect from single space guests? The feature was marketed as if the single space guest users lived in a “separate” Confluence instance with no information access to the rest of Confluence.
This is not really how the Confluence information architecture works, and this leads to issues.
Even without apps this can lead to information leakage. For example if someone authors a page, and then the page is moved into a guest’s space, the page author information is “leaked” to the guest, even if the author is not in the space.
We could re-architect our app, but I think then Atlassian would need us and Confluence users with a more formal “guest user capability and restriction model”.
Regarding your choices, I think 1. is clear cut only for simple apps without background processing “as app”.
Choice 2. is already possible in principle partially, but I’m not sure if/how that works with users changing e.g. between guest and normal and a number of other edge cases.

[scott.dudley]

I agree with @marc that the user directory visibility is a breaking change from an app’s point of view, although the limit of the breakage should be limited to only that for any well-behaved app (meaning that any extra space/page leakage should have already be addressed through the regular permissions model).

In terms of the user-picker itself, having an easy way to identify guest users in all contexts would be ideal, and I think some holes are missing in what is provided to apps (as described above).

But it seems like Atlassian could already fix this on their own, without vendor interaction or rolling out new APIs, by having the user search API return an appropriately-filtered list of users. This should already happen automatically on the front end without any vendor intervention. On the back end, this would require that the app vendor use ACT_AS_USER for the user search call, so it is possible this might require a change…but having the user picker run on the back end rather than front end seems like more of an exception than a rule to me.

This brings up two other points:

1. Is “is a guest user?” actually the correct information to be surfacing to apps? Would this not be more appropriate as a “Can see user directory?” value, given that guest users are not otherwise special from a space/page permissions perspective? This also becomes a future-proof decision if Atlassian decides to provide the ability to limit user directory access in other ways.

2. Blocking all apps for guests seems to go in the opposite direction of making the ecosystem seamless. We have first-class features built into Confluence and Jira that always have access to the entire platform, but we are starting to see more features shipped that were not planned with the ecosystem in mind (including the very feature we are discussing). This leads to apps being second-class citizens with broken or limited functionality. For example, try using Confluence macros on Jira Project Pages. While it is a balancing act, I think Atlassian needs to figure out how to provide a full experience for guest users to those third-party products that are able to support it. An opt-in approach seems like it would satisfy @marc’s needs as well as the greater community’s.