atlassian_{confluence,jira}: clarify API authentication

[efd6]

What does this PR do?

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Closes [atlassian_jira] Update username / password descriptions for Atlassian Cloud #3692

Screenshots

[elasticmachine]

Pinging @elastic/security-external-integrations (Team:Security-External Integrations)

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-09-13T01:08:53.956+0000

• Duration: 15 min 12 sec

Test stats 🧪

Test	Results
Failed	0
Passed	18
Skipped	0
Total	18

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[elasticmachine]

🌐 Coverage report

Name	Metrics % (covered/total)	Diff
Packages	100.0% (2/2)	💚
Files	100.0% (6/6)	💚 2.537
Classes	100.0% (6/6)	💚 2.537
Methods	100.0% (45/45)	💚 9.77
Lines	98.822% (839/849)	👍 7.921
Conditionals	100.0% (0/0)	💚

[andrewkroh]

I was reviewing the README to see if there were any additional changes that could help. I noticed something that makes me question the original intent of the "Personal Access Token". It says

JIRA Cloud only supports Basic Auth using username and a Personal Access Token.

That makes me think the "Personal Access Token" was intended for use with Atlassian Cloud. If that's the case then perhaps we can just fully remove the "Personal Access Token" and only support Basic Auth for both self-hosted Jira and Atlassian Cloud.

@legoguy1000 Do you recall the intent behind the "Personal Access Token"? Was that for the Atlassian Cloud case?

[legoguy1000]

So if I recall everything from my testing, the self hosted confluence and JIRA support basic auth with user/password OR Bearer auth header with a PAT. Cloud versions only supported basic auth with email/token. When I updated the integrations to support cloud, I let the basic auth option for either and Auth header only for self hosted.

[efd6]

Is there a decision on this?

[andrewkroh]

the self hosted confluence and JIRA support basic auth with user/password OR Bearer auth header with a PAT

Yeah, it looks to be true that a PAT can be used with self-hosted JIRA via a Authentication: Bearer <pat> header. https://developer.atlassian.com/server/jira/platform/rest-apis/

So I think we should clarify the readme by

• stating the two options for authenticating to "self-hosted" JIRA,
• stating that only basic auth can be used to Atlassian Cloud (mention the specific field names from the UI),
• and adding links to Atlassian documentation like
  • https://developer.atlassian.com/server/jira/platform/basic-authentication/
  • https://confluence.atlassian.com/enterprise/using-personal-access-tokens-1026032365.html
  • https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/

In UI description of the "Personal Access Token" I think it should mention that this is only for self-hosted JIRA (or not for Atlassian Cloud). This will help steer users toward the correct fields if the don't read the README.

[legoguy1000]

I would make it clear that the PAT in the Auth header is only for self hosted. U CAN use a PAT with ur username in Basic auth for cloud.

…

On Mon, Jul 25, 2022 at 8:42 AM Andrew Kroh ***@***.***> wrote: the self hosted confluence and JIRA support basic auth with user/password OR Bearer auth header with a PAT Yeah, it looks to be true that a PAT can be used with self-hosted JIRA via a Authentication: Bearer <pat> header. https://developer.atlassian.com/server/jira/platform/rest-apis/ So I think we should clarify the readme by - stating the two options for authenticating to "self-hosted" JIRA, - stating that only basic auth can be used to Atlassian Cloud (mention the specific field names from the UI), - and adding links to Atlassian documentation like - https://developer.atlassian.com/server/jira/platform/basic-authentication/ - https://confluence.atlassian.com/enterprise/using-personal-access-tokens-1026032365.html - https://developer.atlassian.com/cloud/jira/platform/basic-auth-for-rest-apis/ In UI description of the "Personal Access Token" I think it should mention that this is only for self-hosted JIRA (or not for Atlassian Cloud). This will help steer users toward the correct fields if the don't read the README. — Reply to this email directly, view it on GitHub <#3693 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADEEL4HRE62CDKTTA4NYPX3VV2KWBANCNFSM53M3ASZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[andrewkroh]

IMO if we removed the abstraction from the UI / manifest.yml then determining what options to set based on use case gets simpler. Like if the UI had three config field, Basic Auth Username, Basic Auth Password, and Bearer Authentication Header then when I'm reading the Atlassian documentation I have a straight forward way to map things into our UI.

The descriptions of the fields can still be there to guide users as to what to enter based on whether that are connecting to Jira Server (self-hosted) or Atlassian Cloud.

[legoguy1000]

typo

[efd6]

😆

The consequence of using hot-row modifiers.

[efd6]

/test