Custom Domains in Cloud - Our Approach

[Sebastian Mendel]

We already set up a redirect, thanks for nothing.

However, we would like to remove it for security reasons. We want to make sure our users can trust the websites they visit by being able to verify that it's on a corporate domain.

But I also want the URLs to be easy to remember.

And it's not that you *give* us a feature, it's that you *deprive* us of it by forcing us to move from our on-premises installation under corporate domain to the cloud. Data center is not an option in terms of price.

[Remie Bolte]

Hej @Dave Meyer

Seems like sometimes you don't speak in years, and sometimes you get to chat twice in one week!

I really hope you were not referring to my comment with regard to the warning not to cross into personal criticism of Atlassian staff. Please know that any feedback I provide should always be considered to be aimed to Atlassian as a company, and not individual team members.

Now with regard to my comment:

I think the point that many are trying to make is that the issue is not with the frequency of the updates, but with their contents. Apart from cliche statements like "thank you for your feedback" and "we value your input" Atlassian does not engage in the large group of customers that challenge Atlassian on her decision.

Obviously, it is Atlassian prerogative to decide how to implement custom domains. Just like it is the prerogative of customers to decide that Atlassian' Enterprise solutions aren't worth spending their budget on.

The issue that is being addressed is that becomes difficult to feel sympathetic towards Atlassian' choices when Atlassian does not specifying how its architecture differs from other vendors that do provide 1st-level custom domains. There are plenty multi-tenant SaaS vendors that do manage to get it to work.

Due to the lack of details, from a technical perspective it feels like this has more to do with "won't" than "can't". Again, that is also for Atlassian to decide, but Atlassian would win the world if she would be open about this.

Instead of implying that it is technologically impossible to support 1st-level custom domains (which it isn't), Atlassian could also be saying: "The cost of implementing 1st-level custom domains in terms of architectural changes and/or observability do not outweigh the benefits, and we believe it is better to focus our attention to other highly requested long-running customer requests".

At least that way Atlassian makes it sound like a "you" problem, instead of externalising it. There are no external limitations to providing 1st-level custom domains. You just don't want to spent time & resources on it. Which is fine. But be open about it.

Cheers,

Remie 

[Aaron Kraft]

I don't know why you all are being so unbelievably stubborn about the two subdomains for custom domain support. Every other SaaS product on the face of the planet has been able to navigate security concerns around MITM attacks without implementing two subdomains. It is kludgy and unprofessional. The redirect, as has been pointed out, is more likely to get picked up in security scanners than having one subdomain for the custom domain. Please go and talk to any other SaaS company who has only a single subdomain for their custom domain and figure out why everyone else can do it this way and is not constantly being hacked via MITM. This does not make Atlassian look good at all. The redirect is a bandaid because the two-level does not show technical competence.

[Boris Berenberg - Modus Create]

My speculation on the situation:

• Atlassian is different from other SaaS vendors due to how they decided to implement their account system
• Atlassian ID uses a unified account that spans across customer (and Atlassian) sites.
• An account which uses Atlassian ID uses a single session that is valid across all sites.
• This allows for functionality that operates across multiple sites. I am not sure any of this actually works or provides meaningful value today, but there is a clear path to long term value through things like federated search.
• The downside of having a single session that is valid across all sites is that if Site 1 admin chooses to phish User 1 and User 1 also has permissions on Site 2, then Site 1 admin can now access Site 2.
• Specifically, phishing can be done because someone who controls DNS can reroute requests to a malicious form to capture the users credentials, or MITM the connection since they can issue valid HTTPS certificates (and many corporations do this as a matter of default security practice).

The question that I can't really figure out an answer to is given that enforcing subdomains does nothing to prevent the attack. How can enforced subdomains possibly mitigate such an attack. I get that Atlassian doesn't want to share this since this would empower an attacker to work around their defenses, but it feels like it's a weak defense, and not one which is sufficiently worth the tradeoff of requiring multi level domain names.

If my general threat model is correct, then a solution could be to change from a single session that spans across all sites, to one that is per property and perform mitigation at the edge of each property. This is obviously a lot more work than requiring multi level domains. 🤷

@Dave Meyer maybe you can comment on this? I think having a shared understanding of the technical side of things may help ameliorate some of the product frustration here.

[Remie Bolte]

I think @Boris Berenberg - Modus Create is hitting the nail on the head here. There is a real threat of MITM with any custom domain implementation: if an attacker gains access to DNS they can take control of the traffic flow and hijack user sessions.

This is a valid concern, and it applies to any custom domain implementation. Whether this gives you access to a single resource (most SaaS vendors) or multiple resources because of a unified account system (there are other SaaS solutions that do this BTW).

What is odd about Atlassian is that they claim that having a 2nd-level domain makes it more secure as having reserved keywords allows them to better detect threats.

I've never heard of anything like this in InfoSec before. That's why I suggested Atlassian somehow shares this information with the world. If you have some breakthrough insights on custom domain MITM attack threat detection, I would think the world would want (and deserves) to know.

[Craig Castle-Mead]

It’s alright - the other SaaS vendors are catching up. I’ve been getting emails from hosting companies saying I need to change all my domains to www.website.company.com 

🤦‍♂️ 

CCM

[hbunjes]

As far as I understand the keyword is used for internal filters like "only users coming from xyz.keyword.company.tld" are allowed to access the session. Introducing more domains than just the keyword filter would be negative for performance.

Also, it could help administrators to just look for the keyword in the logs (or domains missing it).

Although I'm not sure if this is the best solution, I agree that the global user account is a good idea (especially for those using multiple instances). I'm hoping that the future brings the custom URLs without keywords.

[Aleksandr Kamenev]

Is the screenshot of the custom domain settings (which is still under dev)? Or is that domain forwarding setting? Where can I find it under Jira administration settings?

[Scott Dudley _Cenote_]

Further to Boris's comment above, I am wondering if the unspoken reason for the subdomain restriction relates to cookies. If I've interpreted the standards correctly, you can set an authentication cookie for *.secure.example.net, and it then becomes possible to have that cookie delivered by the user's browser only to hosts on that specific subdomain. You generally need some sort of wildcarding in place for the authentication cookie in order to provide good UX, so that the user doesn't have to reauth between going to (say) jira.secure.example.net and confluence.secure.example.net.

However, if these sites are hanging directly off the top-level domain, your users suddenly start spraying those Atlassian authentication cookies at every single site in example.net, including non-Atlassian ones. At that point, you don't even need to bother with MITM: just set up your main www.example.net site to log cookies, and you can now impersonate any Atlassian user who also touches your public website. Thus, if any of your corporate users access a third-party vendor's support site (which uses the Atlassian stack), and if that support site so much as even links to a simple image hosted on the vendor's public website, your user's account could be easily compromised.

I am not 100% sure of these mechanics, but if this is truly the case, that would explain the proposed solution, and I can see how the absence of subdomains could create a problem with global user accounts. Then again, I'm surprised that there are no other possible mitigations. For example, if the user authenticates against a custom domain, I'm surprised that the JWT cannot be somehow annotated to restrict its privileges only to *.example.net sites, and to force the user to reauth directly against Atlassian infrastructure if they want to access anything outside of that. (Isn't that the ideal behavior from a security posture anyway?)