Technical Advisory: IO Integration Switch to Product Profiles

[#1]

The Launch API was first made available to customers about two years ago in the earliest alpha state.  At the time, true role-based permissions were not available through Adobe IO, and so in order to limit IO integrations (technical accounts) to certain permissions, we created roles that mapped to sets of permissions.  One of these roles was selected when you created your technical accounts.

Fast forward a few years and Adobe IO is now integrated with the Admin Console.  This means that API users can be managed in the same way that flesh and blood users are managed - that is, API integrations can now be assigned to the same product profiles that regular users use.

As of September 4, 2019 (see release notes), Integrations of both types are supported in Launch and the older role-based permissions are deprecated.  In February of 2020, the older role-based Integrations will be removed entirely.  Before that happens, someone from your Org will need to login to the IO Console and switch over to the profile-based permissions.  This post will be updated with a more specific date when it becomes available.

1) Ensure you have a suitable product profile

Before you log in to the IO Console to update your integration, you should first make sure that an appropriate product profile exists.  An appropriate product profile will have the necessary permissions you need for your application to run, but not more.  If you need to create a new product profile you should do this now.  Org Admins or Launch Product Admins can create and modify product profiles as needed.  For more about user permissions in Launch, please read User permissions.

2) Update your integration

Any user with the role of Org Admin or Developer can log in to the I/O Console to assign your Integrations to a product profile.  There are two basic approaches.

Option 1: Update your existing integration

This option is simplest, but does not give you the opportunity to test your changes before rolling live.  Depending on what you're using your integration for, this may be fine or it may be a show stopper.  If you need to test your changes, you should use Option 2.

Assuming that you do not need to test, then you can simply log in to the I/O Console and change an existing integration.

1. Login to the I/O Console
2. Select "Integrations" from the top nav
3. Choose the correct Org from the dropdown in the top left
4. Click on the Integration you'd like to update
5. Click "Services" in the Secondary Nav
6. Hover the Experience Platform Launch API card, and click Config

Here you'll be presented with a list of existing product profiles (as configured through the Admin Console).  Simply select the product profile you'd like this integration to belong to and click Apply at the bottom.

You may want to take this opportunity to update the certificate on your Integration as well.  These last for 360 days and depending on when you first created the Integration, you may soon be due for an update.  If you want to do this, then go back to "Overview" in the Secondary Nav, click the Add a public key button, and go from there.  If you'd like more info on generating a new key, the Access Tokens guide should be a useful resource.  In particular the section about generating a certificate.

Option 2: Create a new integration

If you need to test the new permissions in a development setting before you make updates to your application in a production context, then you should probably create a new integration.

Detailed instructions for creating a new integration can be found in the Access Tokens guide.  If you proceed down this route, your process will be something like:

1. Create a new integration (see the guide immediately above)
2. Update your development application to use the credentials for your new integration
3. Test/fix
4. Update your production application to use the credentials for your new integration

We recognize that in the short-term, this change will create a bit of extra work for you to switch your integrations over to the new model.  However, we believe that unifying permission management for both user types has long-term benefits that outweigh the short-term cost.

Happy tagging =)