Applying password policy when company emails are internal only

Question

I have read documentation that says that you cannot apply a password policy unless you verify a domain for your organization (https://confluence.atlassian.com/cloud/verify-a-domain-for-your-organization-873871234.html).

However at my company our email addresses aren't a publicly accessible domain. It is only used for our email address (me@abc.com) as well as internal routing to a company intranet page when you're on our corporate network. (www.abc.com is only accessible in the corporate network and assume there's no such public website as www.abc.com otherwise)

Additionally we send invites for Jira & Confluence to external business vendors and international business partners as well. Whlie Atlassian specifies:

You want to verify a domain that you don't own

To protect the privacy and security of Atlassian's users, it's not possible to verify domains that you don't own.

If you'd like to apply Atlassian Access security policies for these users, ask them to change their email address to a domain that you can then verify, or invite them to create Atlassian accounts that use email addresses from the domain.

In actuality many corporate security teams have mandates on password policy criteria, much of which Atlassian does not enforce by default and therefore a security issue in itself (I believe I read passwords just have to be 8 characters, and that's about it).

Are there any plans to allow for account administrators and owners to take more control over those contributing to their cloud based Jira/Confluence/Bitbucket accounts by allowing for more security enforcement without the overhead of domain validation which cannot be satisfied?

Trinh Nguyen · Answer

Hi Geoff,

I appreciate and understand the explanation. However I will say as a customer that it is very challenging. Although my part of the organization adopted Atlassian, I wouldn't be able to claim the entire domain because there might be part of the organization that also uses Atlassian on their own and I wouldn't want to be accountable to their groups. You have to think +60k enterprise org here.

While we could go the DNS method, reaching out to the main security/networking team that manages for the email/domain for the company, they're not likely to want/understand the request from one individual business owner or Atlassian admin to get the domain verified. Culturally it's a stretch - and security wise has a high barrier when talking about groups that live and breath Change Management Process.

It used to be that Bitbucket had it's own account management and password system (however that had since been merged to the same login that Confluence and JIRA uses) and the problem I'm running into now is that security practices industry wide have tightened up a lot. If anything it should be Atlassian's stance to have a much more rigid password policy system in place that helps cover many security practices around the industry rather than only 8+ character count by default. It would at least make security teams happy (not that I'm coming from that space) I'm just voicing my concern as a technologist that is trying to make cloud platforms more widely accepted in Huge Enterprise environments.

Geoff · Answer

Hi Trinh
Just to clarify, are you saying that the domain used for emails isn't accessible from the public internet at all, meaning that you can't send emails to these addresses from outside your corporate network? If so then you are unfortunately right, you will be unable to claim your domain and set a password policy for the users with email addresses at this domain.

If you can actually send emails to this domain (even though there may not be a public website hosted at the domain) then you will still be able to claim domains using the DNS method and set a password policy. This is most likely the situation you are in as your users would have had to verify their accounts before they could use them which is done by sending them an email with a verification link from Atlassian.

We currently don't have a good solution for external business vendors which you grant access to your site if they are on a different email domain. Atlassian accounts are global in nature which means that once you authenticate and are granted a session, that session will work with all cloud sites where you have access. This means that you can authenticate on any site, such as the external business' own Jira Cloud instance, and then navigate to your instance and be granted access. In essence, password management is on an account level, and not on a site level

I hope this helps