Why is security an afterthought for Atlassian?

[Phil Oliver]

Although (deliberately) provocative, this is a real question. I want to know why, in 2015, in the age of ever rising hacking sophistication, Atlassian chooses to treat security concerns as a second class citizen (if even that.)

Two specific examples illustrate the question.

https://confluence.atlassian.com/display/CROWD/Configuring+Crowd+to+Work+with+SSL

Which is prefaced with:

"Atlassian applications allow the use of SSL within our products, however Atlassian Support does not provide assistance for configuring it. Consequently, Atlassian cannot guarantee providing any support for it."

Well, isn't that special? And exactly what besides SSL would anybody be using to help secure sensitive data such as usernames and passwords (which is basically what Crowd does)? Some magical alternative protocol, unspecified?

The other is the now, as I understand, two year old request, amplified by hundreds of concerned individuals, to add two factor authentication to Bitbucket. A feature now routinely supported by other competitors.

While this is a very serious question, and it would be nice to get a serious response, this is part of what I think Atlassian should be doing to make both security, and customer satisfaction, a first class concern:

• Assume the need for high security in all installations. Don't make the lame claim that SSL is "allowed"; make it *routine*. Don't send people off into extremely frustrating, extremely time wasting exercises in figuring out ridiculously obscure proxy settings
• This ties into another issue: how about providing actual installers the way that every other reputable software company has done for, oh - decades? Rather than a hackfest of modifying parameters, copying files in/out manually between updates, etc. That's completely amateur hour.
• So to combine the two: Atlassian ought to actually have installers that assume that a customer wants and needs security to access the products (or optionally, to relax it for, say, intranets.)

[Deleted user]

In our world, we are mandated to use the Federal PIV card per FIPS 201. PKI is critical...

[Caspar Krieger]

2 factor auth for bitbucket (and the rest of our Cloud!) is in the works. I won't give a timeline because these things are apt to slip, but rest assured we're working on it :)

[Phil Oliver]

So a multi-billion dollar company is incapable of creating an installer which works with the most common configurations of Apache/Nginx/IIS? Why is that? The permutations are hardly infinite. There have been Linux installers for more complex software for years.

I disagree that the documentation is "extensive". It's piecemeal at best.

This would be more useful if it specifically dealt with an SSL configuration on the Nginx side (and why wouldn't that be documented unless Atlassian assumes that nobody installs internet-facing applications, unless the idea is that an SSL connection is a luxury when entering passwords? This is my point.)

https://confluence.atlassian.com/display/CROWDKB/How+to+use+NGINX+to+proxy+requests+for+Crowd

I have Nginx successfully SSL proxying for Confluence and JIRA. The issue I'm having now is specifically with Crowd, which has many more (poorly documented) configurable parameters all over the place. It would be an immediate help for me (and likely others), and I would be grateful, if you could point me somewhere to that "extensive documentation" on how to do that, or describe how specifically NGinx and Crowd would need to be configured to properly use SSL. I actually do have Nginx SSL proxying for Crowd, up to the login (https://MYSITE/crowd) page, but then it's failing with:

The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

It isn't clear how CROWD_HOME/crowd.properties needs to be configured for crowd.server.url and application.login.url - a "localhost" reference, or an external-context reference? And what about the other property files associated with Crowd? (This is exactly what I mean about a hack-fest. Somehow other companies have managed to figure out how to make installers for their software that deal with this stuff.)

[Alejandro Conde Carrillo]

Hello Phil. This seem to be a problem with nginx rather than Crowd. Have you tried contacting nginx support? In addition to that, you should create a question with what you describe here to see if someone has faced a similar problem and they are willing to share their knowledge. I also think you should include the server block(s) from your nginx, as I believe it will be useful to troubleshot this problem.

[Alejandro Conde Carrillo]

Hello Phil.

I would like to answer why SSL configuration is out of the scope of Atlassian support. There are many ways to set a SSL connection which often involve third party applications (apache, nginx, IIS,...) and also different certificate formats. This makes impossible to have a support team which is familiar with all elements involved. Never the less, the support team always tries the best to help customers even with unsupported issues. This does not mean support will always be able to help you with unsupported issues but I can assure you we'll try our best.

In addition to that, there is also extensive documentation on how to set up SSL in different ways. For example, in Conflunece:

• Running Confluence Over SSL or HTTPS - to set SSL in the Tomcat connector.
• Using Apache with mod_proxy - to do it with Apache + mod_proxy.

Other products also include settings for nginx which should be easily extrapolate to other products since this documentation is not product specific. I addition to that, there are also lot's of threads here in Atlassian Answers discussing other options.

SSL settings may not be supported but I think there are enough resources there to successfully run Atlassian products over SSL.