RFCs are a way for Atlassian to share what we’re working on with our valued developer community. 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!
Publish: Jun 30, 2023
Discuss: Jul 12, 2023
Resolve: Aug 7, 2023
Summary of Project
Multi-User App Ownership makes it easier for you to collaboratively build Forge apps by allowing multiple people to work together on the same app simultaneously.
Proposed roles
As part of the project, we are planning to introduce roles and permissions. We would like to receive your feedback on the two predefined roles that can be assigned to contributors.
Can the role membership be pulled from SAML or perhaps Atlassian access? This will simply ISO/SOC2 (and general good security practices) where we have to remove users within X days of termination. It would also help with access reviews.
Not sure if a Developer should see who else has access to the apps (a user in Jira today doesn’t see who else can access a project for example). Ditto with the activity logs.
Not sure if a Developer should automatically be able to download logs (or have access to logs). This really depends on the developer and the app - not the general “Developer” role. The same thing goes with the deploying to non-developer roles (A new developer shouldn’t be able to shoot themself in the foot by elevating an artifact to the staging/qa/test server by accident).
From my perspective, most of the things marked “Developer” should be custom per app/per environment. Think of Jira - there isn’t an “Assignee” role or “Reporter” role. The project administrator can create their own “roles”/assignments. I would love to see some type of customizability here for the Developer. This way we can also add in our customer support team to see warnings etc in production.
First of all, thank you for this RFC, it’s exciting to see the progress on this field.
Personally I would have liked the option to add roles myself, selecting the appropriate permissions of my choice whenever possible. It’s hard to make a common hard-coded template that would match the policy and setup of any development team developing Marketplace apps, so I think customizability would be better here. I second @danielwester in the SSO consideration. Of course approved domains and such will have to follow as well, so we can keep control of who can be added as a participant. I would also like to see the option of access expiry, where we can choose betwen “Never” and a set of time periods like for example x months, 1 year, 2 years. Another access thing I would have liked to see, is OAuth Access to app ownership privileges for a service account that does CI/CD, instead of having to register such an account as a “normal” user.
If I understand correctly, can there still only be one person with “Owner” privileges? I think this setup is brittle, and would very much like to have to option of adding several people as Owner as well.
Something like that - short of defining your own, a common generalization seems to be ‘Admin’ vs. ‘Maintainer’ vs. ‘Developer’, where the Maintainer has full control over the DevOps process, i.e. including production deploys/logs and related workflows, yet excluding the security settings of the project (that’s ‘Admin’).
“Multi-User App Ownership” should include the capability of having multiple users in the Owner role. Single-user app ownership is not only brittle…it’s also a security risk. (Though not a major one.)
As a not great alternative, the “Transfer of app ownership” permission should be assignable to non-owner administrators. That would at least remove the problem of having a single-point-of-failure. But of course, that would make the Admin role even more guarded, and so multiple users in the Owner role would be much better (IMO).
Question: The screenshots show a reference to “custom dev environments”. Is that an existing feature or an upcoming feature? If it’s upcoming, is that part of this RFC?
If it’s an existing feature, can someone please point me to more information? Sorry if I missed an announcement on it. It seems really great and I’d like to learn more!
Edit: Disregard. I just noticed the video link which includes a demo of the custom dev environments. Looks cool!
Hi everyone ! Thanks a lot for your feedback Please keep it coming
The common feedback received till now is Not wanting the app to be owned by a single person. The way we are planning to tackle this in the coming milestones is by allowing partners to have apps owned by a company instead of an individual and there can be multiple company level admins to take care of the app be it transfer of app or deleting the app etc.
You can choose to have a particular company level admin control everything about 1 app/some apps or across all apps in the company. Let us know if this works.
We are actually going with what others in the industry are doing like Heroku, Apple, Google etc where they show the list of users and their roles in an app. Our own products like Jira Product Discovery, Bitbucket and Admin Hub also has this provision. So, we are following the same path. We hope this will keep the contributors informed about anything happening with the app and take suitable action.
We agree that custom roles would be great where each org can choose their own set of permissions. However, we are planning to solve majority of use cases with predefined roles and keep the onboarding simple. Keen to know more about the extra roles you are thinking of. Given there is an option to choose your own role and set of permissions, what would you go ahead creating and why ?
I don’t think is just a mid to large sized organization (we’re a nine person organization). It’s really important from a ISO27k/ SOC-2 and other security certification frameworks. We’re actively avoiding solutions that doesn’t have a way for us to connect to our SSO due to the headaches the administration checks causes (it’s literally a 1000 paper cuts situation ).
So anything to get this in there would be awesome…
Hi @sopel ! Thanks for the suggestion. I am interested to know more about the need/use case for this role. Why would a Maintainer role be important for your team and why wouldn’t having only the above 2 roles suffice ?
May I know what permissions you expect for a service account that does CI/CD ? Is it something like a maintainer role mentioned in the comments or different ?
Restrictions to download/access logs → Just to confirm, is this due to security reasons alone or more ?
Security reasons mostly. Ie new developer or contractor comes onboard. They might have access to deploy to production - but they might not need view log access depending on what’s going on.
Customer support role to view warnings [like a read only role ? ]
Kinda - Our Customer support folks would love to be able to see that there is an issue (or not) when something comes in. (Health stats basically). However they’re not really interested in the logs (or if they do - it’s mostly for specific rows).
As already described, a Maintainer has full control over the DevOps process, including production deploys/logs and related workflows, but excluding security controls, which are the exclusive domain of the Admin/Owner. In contrast, a regular Developer might be a junior or an external contractor and thus not yet be burdened and/or trusted with production access on procedural and security grounds (matching your current ‘Developer’ role).
Two roles do not cover these crucial differences, because we need to prove that we are in control of our supply chain and CI/CD process in context of our partner agreements with AWS and Atlassian (e.g. Well-Architected certifications), and more importantly, for external audits (e.g. ISO 27001 and SOC2). This starts with sufficiently granular roles that allow us to delegate development work to employees and contractors, while maintaining organizational control on a) who has production access (Developer vs. Maintainer), and b) who is in charge of security controls (Maintainer vs. Admin).
Hi @ChandanaMeka – A little clarification: my primary concern is the ability to manage the app owner account itself. Specifically, companies will need the ability to remove an app owner’s permissions if they suspect the owner’s account is compromised. I assume the company-level ownership solution addresses that concern.
If so, what is the hopeful timeframe for reaching the company-ownership milestone? If it’s soon enough, then it’s a good solution (IMO). If it may be a ways away, I suggest opening the “transfer ownership” permission to non-owner administrators to address the security concern of a comprised owner account.
The solution where company owns the app will take more than a quarter to happen as we are also planning to integrate marketplace and dev console roles and permissions and smoothen the journey for partners right from building the app to listing the app.
I suggest opening the “transfer ownership” permission to non-owner administrators to address the security concern of a comprised owner account.
A slight concern with the above point is people may misuse this permission and transfer the app to themselves making them as the new app owner. However, I will get back on this.
Summary of Project
Proposed roles
User Experience
Feedback
EAP Sign-up
Please keep it coming 