Custom Domains in Cloud - Our Approach

43 comments

Comment

Log in or Sign up to comment
Sebastian Mendel May 17, 2023

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.

Like # people like this
Remie Bolte May 18, 2023

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 

Like # people like this
Aaron Kraft May 18, 2023

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.

Like # people like this
Boris Berenberg - Modus Create May 19, 2023

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.

Like # people like this
Remie Bolte May 19, 2023

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.

Like # people like this
Craig Castle-Mead
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 19, 2023

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

Like # people like this
hbunjes May 21, 2023

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 June 3, 2023

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?

 

where_do_I_find_this.png

Like Sonya Spangelo likes this
Scott Dudley _Cenote_ June 7, 2023

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?)

Like # people like this
Bill Bailey June 8, 2023

I think I will just use wiki.wiki.domain,com for our instance. And then add a note "Why wiki.wiki? 'Cause Atlassian thinks it is more secure than just one wiki."

Like # people like this
Marc-A (Nimbax) June 9, 2023

Hey @Luke Liu and @Dave Meyer ,

I will try to be as constructive as possible.

Currently we are using an xxx.atlassian.net domain. Since this is a first level domain can you please confirm Atlassian does not consider this domain to be safe? Just want to know cause I will advise my clients about this possible vector of attack.

 

Can you please to bring peace to this matter present the community with evidence that the first level domain is a possible vector of attack. All the community seems to be unanimous regarding this matters and everybody who does not work on that project seems to thinks this is B.S.

I would guess that you guy will never implement an unnecessary features that probably makes things more complexe in the process of releasing that feature...

So if you guy in the next couple of day could bring out an update on that matter. You probably already have all that information available since you guys took that decision for the product. 

If you could share that with the community, the exact SECOPS reports or at least a brief of that report that explain the necessity of having this feature implemented that way...

Like # people like this
Sebastian Lutter June 9, 2023

If you don't want to do something but you don't have any arguments than blame some blurry MITM security issue. Either this is not the real reason and just an excuse or your system architecture is so insecure and bad that this is true (worsed case). I am pissed off!

Like John Funk likes this
Johnathan Raymond June 12, 2023

I've been hoping to migrate my support team to servicedesk for a long time (Right now they're still using Redmine). One of their objections to jumping ship is that our customers have put in place URL whitelist exceptions for our current support URL, and the support team doesn't want to deal with the ramifications of migrating users to a new URL. This restriction might be the nail in the coffin for getting this migration approved.

Like # people like this
Sebastian Lutter July 18, 2023

This is complete nonsense! What kind of MITM do you have in mind? How are longer URLs more secure? And if that is really the case in your plattform what about fixing your plattform instead of declaring us stupid.

Like John Funk likes this
Wyatt Best July 21, 2023

Hundreds (thousands?) of other SaaS products have managed to implement product.customer.com domain names. Figure out how to implement it or tell us, plainly, why you can't.

Even extremely complex and/or silly architectures like blockchains make some kind of sense if you study them, but this looks like a snow job of buzzwords. Many of your customers are highly technical and do not appreciate the hand-waving.

Like # people like this
Matt Reiner _K15t_
Marketplace Partner
Marketplace Partners provide apps and integrations available on the Atlassian Marketplace that extend the power of Atlassian products.
July 26, 2023

We had fun making a little video update on where we are with this feature, in case you're looking for something quickly shareable for teammates: https://www.youtube.com/shorts/FzWqjGDsiSM

Like # people like this
Gaber August 2, 2023

Could this work? 
 wwwsup.JPG

update: this got suspended shortly :(

Sebastian Lutter August 7, 2023

Was the ignoring of customer requirements a deliberate shitting on the customer or rather an oversight that will still be corrected?

Like Wesley Caldwell likes this
TAGS
AUG Leaders

Atlassian Community Events