Securing JIRA's API over Basic Auth

[Taylor Huston]

JIRA'a API allows for basic auth. Right now I am in the middle of rolling out a new JIRA install onto Azure, and that is making the security team uneasy. For one thing, it allows anyone to bypass MFA. We have a plugin that enables MFA when you log into JIRA through a browser, but if you say curl against the server with a username and password it bypasses MFA.

So far the best workaround I have come up with is putting an Apache Proxy in front of JIRA, and in that Proxy I am using this rule:

RequestHeader unset Authorization

And that works, in a roundabout way. API requests are still passing through to JIRA, they just come through as anonymous, so as long as people follow good practices with their permission schemes people shouldn't be able to get or change any data through basic auth API calls.

But something about that method just feels like a hackish workaround. I feel like there has to be a more elegeant way to accomplish this goal. Now I am a JIRA SME, not really an Apache SME. I have used Apache in the past when I was a web developer, but it's never been my primary job focus and I wouldn't consider myself an expert. And as for the Azure end of things, we have an infrastructure person that's handling that. She's investigating anything on the Azure end (Azure API Management, for example) that might work.

But in the meantime I thought I would reach out to the community and see if anyone had any ideas. We can't be the first team that's had this concern, so I am hoping someone else has already solved this issue for me.

Thanks!

[Steven F Behnke]

The problem here is that JiraDefaultAuthenticator accepts basic Auth. If you want to remove that, you should obtain the source code for Jira, make your own authenticator as similar to JiraDefaultAuthenticator as possible, and be sure to deny basic authentication within that class.

This authenticator would be deployed to <install>/WEB-INF/lib. Then, you would modify the "seraph".xml file (I forget the name offhand) within <install>/WEB-INF/classes. Finally upon restart, you'll be using your custom class 

To be frank, this is the "Jira" way to handle it, but I'm not certain it's "easier" than the apache header command. If you do use apache, I would make sure that Tomcat only accepts incoming connections from the apache server ip (ie local host), otherwise people can bypass your hack by targeting Tomcat directly.

If you have more questions, happy to help. If you want help with the authentication class, can you raise this question on the developer community forums instead? Happy to help there too.