Better Auth option for JIRA

[JKrag]

In Issue #55 @buep suggest that we add specific issues for specific auth requests.
I now have a need for some better auth for JIRA specifically.
It is my understanding that the only authentication option currently available against JIRA is basic auth (and no auth, but that is hardly useful).
This means that my only current option for setting up PAC is to provide my own user account and password. I am currently trying to use PAC in a corporate setting where we use only AD authentication and it is not easy/viable to get a "dummy"/jenkins account set up with read access. (especially during vacation time).

I don't know what is the ideal solution. I believe that JIRA only has a limited number of authentication options beside basic (i.e. cookie and full OAuth), so some investigation might be needed.

[buep]

I get your problem, and I don't see you can get around a service user. It is the usual discussion in big orgs.

OAuth is probably not possible as this seems to involve a authentication workflow back and forth between the consumer/provider service.

• https://oauth.net/core/diagram.png
• https://confluence.atlassian.com/jiracoreserver073/allowing-oauth-access-861257138.html

Cookie based seems easy to support, that requires you have and supply a user.

• https://developer.atlassian.com/jiradev/jira-apis/jira-rest-apis/jira-rest-api-tutorials/jira-rest-api-example-cookie-based-authentication
• https://community.atlassian.com/t5/JIRA-questions/JIRA-API-Authentication-Cookie-No-JSESSIONID-but-cloud-session/qaq-p/607903

So no matter how much we would like to help you, I think you need a service user.

Do you need an estimate on implementing cookie auth? Maybe first checking it OAuth is possible?

[JKrag]

I think I read on one of those pages yesterday (but can't find right now) that Atlassian does not recommend cookie-based auth. If that is true, then we shouldn't go that route.

Maybe we should have someone look into the OAuth solution in general as this might be useful for other platforms as well. (and probably other Praqma projects).

For my current use-case I have now done a survivable workaround by using the Jenkins credentials store to store my user/password, and then I use the new (to me?) -c switch to inject them into pac. This prevents it from being printed in plaintext in the console or being stored in a file in the repo or workspace, but it does not prevent any other "malicious" user from echo'ing the credentials to a file by adding a single line to the shell block in the job (or a temporary copy of the job).

I can probably live with this for now, but would like to encourage at least a preliminary investigation of the OAuth solution.

Maybe, as a minimum, we should document how to do this credentials setup in Jenkins.