To second @PaoloCampanelli’s comment - now that you have proposed RFC-97 REST APIs in Forge, you will have to make a decision regarding RoA and configurable egress.
There is effectively no difference between the two in terms of control and visibility - an app can egress arbitrary data through either mechanism, and in both cases, it’s the product user who approves the egress and configures authentication between the app and the external system. Whether the egress is initiated internally or externally is an irrelevant detail.
Digging into this farther, it appears that the list of set remotes and domains is not available when there is no user present, such as in the context of a scheduled trigger. If an app requires access to this information, it must separately store this configuration. What’s driving this? It requires duplicate storage and different patterns in different places, neither of which is desirable.
Having the configurable egress feature can unblock many formatting apps to be ROA like markdown, html, reporting. These apps can fetch resources like scripts, images, css from different CDN’s which are customer usage specific.
Thanks for the feedback and good catch; it’s important that backend functions also have awareness of when/where/what permissions have been established, so that they can act accordingly (particularly if a feature if gated by egress being enabled). A lot of the focus of this RFC was on front-end enablement. I’ll take this away for further exploration with the team.
@SeanBourke, can you elaborate more on the timeframe? Because I would expect based on these quotes that the implementation of this RFC will be shipped without a distinct position.
In my interpretation, this means that the initial release of configurable egress will not be RoA compliant. Is that incorrect?
In html snippets can fetch static resources like images, scripts, css which can be data ingress and they cannot send any data. But with out allowing all content permissions as ‘*’ for the resources cannot be loaded due to CSP. I think data ingress for static resources can be considered.
Thanks Sean, for this great RFC that will definitively unblock use cases for us.
For us, I see 3 types of use case:
egress/remote to known domains that we would like to enable by default, but that the admin could disable, if they are really privacy centered. Like analytics, Sentry, SaSS tools for in-app communication (like Beamer) … For each of these, we should be able to provide to the admin a little text to explain why it is needed and what they will lose by disabling them. Maybe also a link to our documentation for more info.
egress/remote to know domains, certainly owned by us, to enable specific features. This could be disabled by default, but we will need a way to trigger the Atlassian own dialog to ask the admin to enable it, with a text provide by us to explain what it is about. I have in mind a service hosted by us on AWS to provide specific features, like notifications to an external system, fetching data to a customer own SQL database, a REST proxy (own by us) to an LDAP directory …
dynamic egress/remote to fetch data with REST APIs from the customer’s system. This will be configurable from our app admin, and will trigger the Atlassian own dialog for validation.
This is for us the most important use case.
Note: 1. and 2. could be the same things, with a property like enabledBydefault: true/false in the manifest.
Could we see the list of egress/remote, with their status enabled/disabled, in the Developer Console ? That would help the support team a lot, because we already know that customers will complain on non-working features because of disabled egress/remote.
A global admin uses an app and configure in the app a URL to get data from/to. Will the popup to confirm it triggered straight away
A none-global admin users configures things - how does it work in his case?
Answering your questions:
Whether this unlocks new use cases for you on Forge which were previously inaccessible? No, it brings parity with Connect.
Does this implementation make sense for your app/s? The UI is OK. Admins need to go to a page to allow URLs, come back to the app and continue configuration..
The implementation proposed to configurable egress applies to all egress types. Is this acceptable, or would you prefer a more granular approach? Seems OK.
Can you foresee any significant constraints of this implementation? Are there things which you would not be able to achieve which should be unlocked through this? Tons of issues: needs to support IP, not internet URL potentially, easily name the URLs and manage from an app etc. Would be good if there is a permission to the app to manage URLs and admin just needs to confirm (enters URL in the app and confirms it straight away, deletes a URL in the app and it is deleted from the managed urls)
Is there anything you believe we are missing, or which should be reconsidered in the above proposal? Manage URLs by apps, delegate to the none-admin users.
Thanks for the feedback and suggestion. This would require further validation, but I appreciate the significance this could have in enabling support teams to quickly and easily debug capabilities. I’ll take this away for further exploration.
That is our current ambition - we would prefer the popup to be exposed in the context during which the admin is asked for the permission. For example, if an admin toggles on a feature in your app which required egress, you could opt to display this to them then, or when they save the page.
This approach leverages the existing permission scheme, where the org/site/product add is delegated to determine app installations and the permissions/access which comes with them.
While an end-user may not be able to add these, it would be feasible for an app to build an experience which made this possible by (for example):
Storing the user requested URL in KVS
Exposing these URLs to admins in a central configuration page
Providing a mechanism for admins to approve/remove requested URLs from other users
This feature would enable us to manage a single forge application for all of our customers’ self-hosted version of our api/auth. Without configurable egress our customers need to deploy and manage their own forge application which is a pretty unfortunate experience for them.
Our apps are heavily dependent on this feature. Based on the initial description, it was expected to be resolved by June 24th.
Could you please confirm if this is being taken forward for implementation?
Thank you for the RFC.
First of all, I see a lot of concerns about RoA eligibility from commenters. I’d like to emphasise that dynamically defining app integrations demonstrates a significant added value, regardless of the RoA matter.
(FYI @JamesDumay) For example, such a feature would unlock essential functionality in our main app, a Jira email client, as customers could specify connections to custom mail servers besides some well-known default providers (Gmail, MS Outlook/Graph). Another use case is to send webhook alerts to/via user-defined services: here we can also hard-code the URLs of some popular providers (Slack, MS Teams), but the flexibility to add custom service endpoints is a big plus.
Of course, there is a valid subset of use cases, where a dynamic egress or remote integration should not preclude an app from being eligible for RoA, but it is another topic, how to verify that the external connection is benevolent and the corresponding traffic does not involve undue communication of any (sensitive or product/app-scoped) data.
Currently I cannot see major flaws in the proposal.
A big thank you for your feedback on the RFC - it’s helped validate that we’re heading in the right direction, but has also supported some introspection of the capability and mechanisms to improve it. Covering some key feedback and questions below to close this out.
Runs on Atlassian support
We appreciate the feedback related to Runs on Atlassian and understand the motivation which a lot of apps have to achieve this. As @JamesDumay noted in this post, we are performing further exploration of how customer would perceive a capability such as configurable egress within Runs on Atlassian.
Major / Minor Updates
We’ve further explored scenarios where updates would need to / not need to occur. Similar to recent work with bulk-upgrade and the inheritance of Connect scopes, we’re striving to apply a principle of privilege escalation leading this. For example, if adding configurable egress would be a minor update, as the admin would later approve the elevation of permissions in the modal. Similarly, if a remote is changed to configurable and retained its existing remote as the default, that too would be minor.
For those wanting to follow our delivery of this, we have added it to the Forge Roadmap and will continue to provide updates here.
Our Forge app for Confluence needs to call different specially trained generative AI models to process user content. These models are hosted on the customer’s own servers. Since Forge requires all external domains to be hardcoded in the manifest.yml, we currently have to make a separate deployment for each customer with their specific domain, which is not scalable.
Support for dynamic or admin-approved external domains would let us maintain a single Forge app for all customers, even when they use their own self-hosted AI models. This would greatly improve manageability and adoption for privacy-focused organizations.