Atlassian Connect App installation lifecycle updates or checks

[YatishMadhav]

Hi all
I have gone through a few articles relating to the security improvements of our Jira Connect App

Action Required - Atlassian Connect installation lifecycle security improvements

[Update: 12 JUL 2021] Enforcement date is extended from 20th August to 29th October 2021. [Update: 15 JUL 2021] Please upgrade Atlassian Connect Express(ACE) versions to v7.4.0 or later. Previous versions ( v7.1.5 ~ v7.3.x ) automatically opts in to this new feature that results in creating a new app version without the vendor’s action. This new ACE upgrade( v7.4.0 ) will not modify your app descriptor which may result in removing "signed-install" field that could have been added unintentional…

Connect is returning to per-installation secrets

What is changing? After some time using a per-app secret model, Connect will be returning to a per-installation secret model. Why is it changing? Historically, Connect used a different secret for an app in every installation (unique secret per-tenant/per-app secret model). The initial installation of an app would be unsigned and contain the secret for all future interactions, which would be signed. This included any subsequent installs, even where those installs changed the app secret. We ha…

Per-installation sharedSecret rotations

Hello Community! In the announcement about getting back to per-installation secrets @HanjooSong mentioned sharedSecret rotations and we have some questions to clarify what does it mean. All current app installs will have their secrets rolled and apps will receive a new install payload with a new secret Do you have any exact date when it will happen? What does it mean technically? Would you just send installation hooks with a new sharedSecret? Receiving follow-up install payloads for exis…

Connect App Shared Secrets Stopped Working

Atlassian is currently rolling out new sharedSecrets for each app & instance in an effort to move away from single sharedSecret to per-app / per-tenant shared secrets. You will probably have received new installed lifecycle events. It is absolutely paramount that your app is capable of receiving these updated sharedSecrets, i.e. that your code supports updated client information whenever a lifecycle event occurs. Could it be that you are currently not handling these updates in your app? See als…

Simple verification procedure to prepare your app for single shared secret...

We currently have/do the following:

• We have a private connect app that currently just has custom fields added
• on the connect app side, we limit the installation of the connect app to only 2 tenants (based on baseUrl)
• we install (and update/reinstall) by copying the URL of the app descriptor and click on the ‘Upload app’ link on the UPM page
• using the secret, client id, etc, we make REST API calls to the tenant(s)
• on updates, we re-install the app using the URL of the app descriptor as above

One other question I have is: If we update the app descriptor the version is updated on the vender marketplace listing … BUT we have to reinstall the app by copying the URL as mentioned above. Is this the correct process? How can we better manage this as this step seems a little manual right now? I did see the comment “There is no plans for scheduling a periodical rotation” but I wonder …

Basically when should we look out for the install payload, what specifically is advised to be stored from the payload on our and and what needs to be updated?

If possible, hoping for responses from the authors like @HanjooSong @AdamMazur @rwhitbeck @natashbar …

Please advise on some checks we can do as well as confirm if there is any process updates we can do based on the above.

Thank you in advance
Yatish

[HanjooSong]

Hi,
Can you elaborate bit more around this?
limit the installation of the connect app to only 2 tenants (based on baseUrl)

We recommend apps to identify installations by the clientKey, not by the baseUrl.
If there is an existing installation record for a site (baseUrl) under a different clientKey , your app should associate the site with the new clientKey and the sharedSecret.

Also, if you publish a new app version to your marketplace, it will be automatically installed to the tenant over the next 24 hours unless there was a scope change in the app descriptor.
(Please note that this automatic upgrade will only be triggered for the apps installed from the marketplace, not for the apps installed manually by using the app descriptor via developer mode)

For more detail around the automatic upgrades please visit below.
https://developer.atlassian.com/platform/marketplace/upgrading-and-versioning-cloud-apps/#automatic-app-polling-and-versioning

[YatishMadhav]

Hi @HanjooSong
RE limit install on 2 tenants … I mean we restrict the connect app descriptor to only be used and installed on our 2 Jira clound instanced based on the baseUrl. If install elsewhere, a 4xx reponse is given.

Would you advise we store the clientKey on the app side if that is preferred? When would the clientKey change if at all? Meaning it will only be installed and reinstalled one 2 instances ever, how would the clientKey and sharedSecret look?

We have had updates to the connect app decriptor JSON and it did not auto install on the 2 instances. Might be because it is private? Think you just answered that

Thank you
Yatish

[HanjooSong]

Hi,
WE have recently updated lifecycle section on DAC describing when clientKey and sharedSecret can be changed.
We do recommend apps to use clientKey as an identifier instead of the site baseUrl. However, I assume you own those 2 instances as well and if there isn’t any plan for importing/exporting site data in the future, there won’t be any issues with using baseUrl as the identifier instead. I will leave this up to you.
And yes, the automatic app versioning won’t be triggered for a private app.