Introducing the new Developer ID to Marketplace

Announcements
,
1

As we embark on an exciting phase of architectural enhancements for Marketplace, we want to announce the introduction of the new Developer ID system that will replace the existing Vendor IDs. This transformative change is integral to our long term vision of unifying access and profile management across both the Developer console and Marketplace.

Why are we making this change?

Currently, Atlassian Marketplace identifies new vendors through incremental identifiers for their Vendor ID, while the Developer Console uses AAIDs and permissions without a dedicated ID entity. Our new Developer ID will use UUIDs (Universally Unique Identifiers) instead of the previous serial number system, and is planned to be utilised across both platforms in the future, providing a seamless and cohesive profile management experience. This change is more than a mere update, it’s a significant upgrade aimed at enhancing security and efficiency.

The introduction of UUIDs enhances security. UUIDs are globally unique, eliminating the risk of identifier collisions and ensuring each entity has a distinct and secure identifier. UUIDs are randomly generated, making them difficult to predict and significantly enhancing security against unauthorised access.

Our Commitment to a Smooth Transition

We understand that this transition might create unrest among our partners, especially since many existing APIs rely heavily on Vendor IDs. However, please be assured that we are here to support you every step of the way. We are fully committed to making this transition as seamless and smooth as possible for all our partners. Here’s our high level transition plan:

  1. Six-Month Transition Period: All new APIs featuring Developer IDs will be introduced with a six-month transition period, allowing the use of both old and new APIs during this duration.
  2. Conversion API: We will offer a dedicated API that allows you to obtain the new Developer IDs using the existing Vendor IDs. This conversion API will be available well before the full retirement of Vendor IDs from the Marketplace.
  3. Phased Rollout: The new APIs will be released in carefully planned batches. Once all new APIs are live, we will ensure partners have ample time and overlap to transition smoothly.
  4. Clear Communication: We will maintain clear and timely communication throughout this process here on CDAC as well as Partner Portal, providing regular updates and detailed timelines to help you plan and implement the necessary changes with confidence.

This transition is a crucial step towards the new architecture providing a more secure and unified Marketplace. We appreciate your support and cooperation as we move forward with these improvements. Our team is here to assist you every step of the way, ensuring a successful transition with minimal disruption to your operations.

2

Hi @Yamuna,
Thanks for the heads-up!

Could you please explain how UUIDs would enhance security? Should developer IDs be considered private data that cannot be shared publicly? What happens if a developer ID “leaks”? Will we be able to “rotate” developer IDs in that case? Will we be able to see developer IDs of other vendors as it is currently the case?

We found it very useful to have short numeric Vendor IDs in the past (I have memorized ours and I’m sure other vendors have as well), since it’s often required when raising tickets in ECOHELP. However that’s not a blocker for us, we’ll find a way to copy/paste our new UUID developer ID as well :slight_smile:

10 Likes
3

Perhaps good to also note that there has been discussions about this on the Partner Portal (Log in with Atlassian account)

In general, the gist is that apparently there have been DoS attacks using incremental number on the vendor ID and that enhancing reliability is considered “security” by Atlassian. To make it harder to compose a list of vendor IDs, the API to retrieve all vendors will be deprecated (see Log in with Atlassian account)

Atlassian did not go further into questions about whether they will also remove the vendor ID from other API’s, as this information can still be scraped from MPAC and/or the API to retrieve all apps.

They also did not go into questions about the nature of the DoS attacks: whether the goal was to actually bring down the service (which could also be achieved without vendor ID, thus making this change unnecessary) or if this was about finding vulnerabilities. In case of the latter, it is still very much unclear what an attacker would want to achieve.

I think the overall stance of Atlassian is that security is improved “in general”:

From a security perspective, the point is to provide defence in depth to the systems; providing multiple layers of protection is a general security practice.

we should (not) wait until that is exploited and a production issue must happen before fixing it

My understanding of this conversation is that there currently isn’t an issue with the vendor IDs but Atlassian wants to change them for efficiency reasons and is adding the “security” argument on top out of principle.

3 Likes
4

How will customers identify a vendor? Currently customers can visit the marketplace and go to the vendor page, based on the vendor ID.
We would like that customers have a unique way to identify a vendor, and that all customers have access to this ID, i.e. in practice this implies that vendor / developer IDs are public.

5

We can discuss all day long if this is truly a security enhancement to the marketplace APIs or not. Personally I don’t think so, but that is just me.

What does annoy me a lot more, is the announcement of this change was first announced on the Partner Portal on June 3rd, 3 days before hitting CDAC.
As far as I can tell this will effect ALL vendors whether they are partners or not. Not all vendors have access to the Partner Portal and this this should be posted on CDAC not the Partner Portal.

It also lacks information what APIs are effected by this change. ALL vendors use there vendor ID, for support tickets, ECOHELP tickets, but also for automations like publishing new versions to the marketplace, or getting reporting data.

This conversion API will be available well before the full retirement of Vendor IDs from the Marketplace.

What is “well before” in this context? Are we talking hours, days, weeks, months? “well before” can be hours for some but months for others.

2 Likes
6

It is even worse… there are a lot more of these types of announcements (like Log in with Atlassian account) which was posted Oct 16, 2023 :exploding_head: and got completely unnoticed by the community

3 Likes
7

Why??!!

Is the only question that comes to mind.

I’m utterly dumbfounded by this.

Keeping track of all the changes is hard enough as it is, why hide important announcements like this? This is really hurting the vendors and partners. It’s needless, causes friction, delays, issues, and we end up with unhappy customers, developers, vendors, partners and so on and on and on.

I’m curious is there is someone in a leadership position at Atlassian that is noticing this “method” of communication with the ecosystem.

1 Like
8

Completely unrelated from this topic, but this has some history.

A couple of years ago, when CDAC was launched, Atlassian centralised all marketplace comms to this site. Which… was a bit problematic, because this is a forum. For instance, CDAC was also used for reporting cloud incidents, change logs, etc. You can see with the current Platform 7 release what the shortcomings are of using CDAC as a source of documentation.

So Atlassian went on a journey to decentralise comms into multiple channels, including Partner portal, change logs, CDAC, ECOHELP, etc. When that project was halfway, Atlassian decided that it needed to follow industry best practices of laying off staff (because investors) and randomly selected 5% that needed to go. Obviously, this was not so random: it almost completely involved all Marketplace programs staff, incl. marketplace marketing. The ones that were left decided to leave on their own terms.

The whole comms strategy got stuck in limbo, with no driver left in the seat. So now teams can just decided by themselves where to post what and there is nobody left within Atlassian to check if vital information isn’t missed by the Atlassian partners. In the context of “no news is good news”, if you don’t get any pushback because partners never read your announcement, you can just continue as planned!

At some point DevRel / DX teams were still doing some of the heavy lifting, but now the team has been put on tour to sell Forge I don’t think many have time to keep track of all the different comms channels (just like we don’t).

Anyway, so much for some much needed Atlassian history as to why comms are a mess and partners stay uninformed about many changes, despite Atlassian best effort to provide clear and timely communication!

10 Likes
9

I did see changes over the years, but I must say I missed the point in time where is went sideways, thanks for providing the historical picture.

As for the history, as I read it I would say it is directly related to this topic, and all other announcements made. Choices made for better or for worse have created this situation. The absence of leadership/ownership for comms makes the problem bigger.
I would think that if this announcement was completed with all the API changes, and was made back when those where announced, this issue would potentially not be seen as such a big issue to overcome.

10

@remie and @markrekveld,

I’m willing to engage on your assertions about a larger comms problem and accept that it was reasonable to post about it as context. I would ask that we do that as a separate topic, which I’ll start soon. With that, could we please turn future comments back to the original topic?

5 Likes
11

There is no requirement to keep the new IDs a secret.

12

Hi @marc

Thank you for your question. Today, each partner already has a unique, human-readable slug associated with them, which is the name of the partner. This slug will be embedded in the new URL, enabling easy identification and distinction of each partner. Customers can search for this slug in marketplace to locate the exact partner they are looking for. I hope this clarifies your query.

13

Hi Ben,

Thank you for the response. Hope your queries have been answered. Let me know if there is anything else you need.

1 Like
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.