Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,553,550
Community Members
 
Community Events
184
Community Groups

Automation for Jira API Authentication - CLOUD

Markus
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Nov 28, 2021

Hey,

Starting a thread to hear what other Jira Admins/Users are doing to tackle this...

Keen to hear how you protect the base64 encoded authentication inside your A4J rules?

Occurred to me that maybe an attribute insight an Insight Object inside a locked down schema could potentially work? I just worry about project admin's accessing the rule and using the auth inside the web request. 

Aware it could be set as a global rule to prevent project admin's accessing but still not really great from a security perspective

1 comment

Mykenna Cepek
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Nov 30, 2021

Interesting question! Sounds like a good Product Suggestion to offer to Atlassian.

Thinking this through, I don't see a way to truly lock this down with Automation as provided today. If the rule is able to look up the value and use it, then it's either exposed or easy to expose.

As you say, a project admin having access to a (project-specific) rule means the content of that rule (and the rule itself) is vulnerable. For example, a project admin could just add an "Audit Log" (or other) action to expose the value, no matter how tricky the rule was in retrieving/decoding/etc that value.

This suggests that the rule itself needs to be secure, leading back to your global rule approach (which simply reduces the scope of admins with access). However, this approach isn't a slam dunk, because:

  • A rule set to "Multiple projects" but with only one project listed will revert to being set to a "Single project" (once you sneak past the first warning it gives).
  • Multiple project rules can cause automation limits to be exceeded (for non-Enterprise level plans).

Interested to see if anyone else has ideas on this!

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events