Do you keep your Atlassian APIs safe and clean? Your Shadow-IT department sure does not!

The interconnectivity of our day to day application suites has allowed application administrators and integration specialists to carefully design and implement integrations such as collecting worklogs from JIRA and sending them to be processed by billing and payroll systems. 

Due to the sensitive nature of this data the implementers take into consideration the security of such an integration to guard against unauthorized information disclosure, system performance as well as making sure it can be maintained. These are aspects that everyday users can’t be expected to consider –and historically have not needed to. However, this has recently changed with the cloud-first world and the arrival of easy to configure automation platforms.

The everyday user with lack of awareness of API security

With the advent of no-code automation platforms like Zapier, Unito, IFTTT or automate.io any user with 0-programming abilities can set up integrations in minutes without permission and knowledge of the IT department. All they need to do is to supply their credentials in cleartext to these third parties and they will happily impersonate the user in the system and act on their behalf with the user’s full-access level.

From a user perspective these automations are very tempting, promising solutions for auto resolving annoying customer tickets without waiting for development. T

he user only has to supply their password and a minimal amount of configuration.
In companies that take security seriously and put in place 0-trust policies, users are prohibited from actions such as these but if disregarded even once the information can be disclosed and never be made a secret again.

The negative consequences of no-code automations

There are several consequences for rogue integrations such as these, not only information disclosure and having external systems crawling through your application while impersonating a trusted user. 

Failed and half-setup integrations are often forgotten by the unskilled users who tried to set them up, still leaving the users’ credentials available to the third party. 

A disgruntled user who just doesn’t want to manually create multiple TPS-reports might set up an integration to attempt to do so automatically but fail to consider redundant queries and loop/exception handling, potentially causing vast unnecessary load on the application server. 

And negative consequences can also happen with a complete setup: a successful yet undocumented integration might grow vital to an unknowing team, but come crashing down after such a simple thing as a field name change.

The hero gives tokens to the masses to make API connections secure

In the Atlassian ecosystem there are two apps that can be combined to give a great and flexible solution to the problem of rogue integrations while bringing along additional benefits for both the end user and the application administrator. I’m talking about resolution’s SAML SSO and API Token Authentication for Jira and Confluence.

-> Get rid of credentials in the Atlassian application

If user credentials aren’t stored locally in the Atlassian application, then they can’t be used for authenticating REST calls. As simple as that. With applications such as SAML SSO the main intended use is to allow your users to only authenticate once across your applications and to give you administrators a central place for managing users and their authentication options such as MFA-tokens. But an added bonus is that SAML SSO can be set up so that users don’t have a local password in JIRA and thus can’t set up REST integrations.

-> Set up authorized API tokens

Users will now have to contact IT when they need an integration and IT can make sure that it’s set up in a secure fashion and is well documented. A tool for realizing this is API Token Authentication. It can allow administrators to:

• Centrally manage tokens that can be used to REST-calls
• Create tokens on behalf of users
• Delegate the permission to create tokens to specific groups
• Restrict the validity time for a token.
• Restrict the IP addresses that are allowed to use tokens.
• Define the privileges for each token, read-only or read&write.

These tokens can then be used to access the REST-API much like before, but now with the added oversight of the IT department.

Conclusion

The Atlassian applications by default give all users the ability to set up automations such as these, and the ability to programmatically exfiltrate all the data that the user has access to. Many two-factor authentication solutions give the illusion of stopping this but in reality leave the API-access untouched. 

Defaulting to not granting API access to all users and only delegating it to trusted parties is a good strategy. Given that you have the tools to manage it, it can be easy and give your users added bonuses such as SSO.