nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What to do if we can't verify 10 different external 3rd party domains (and using Okta)

Eric Karlinsky

Hi,

We're a global service provider and we're setting up a Jira / Okta integration where several employees of large global 3rd parties need access, each with their own domain. So users will be onboarded in Okta and Okta will do the Authentication and Authorization before accessing Jira.

The issue we have now is how to verify all these different domains? Can you imagine what it takes to add something to global companies websites or DNS?? And these are companies with more than 100.000 employees, so imagine the process to get this approved and done..

And why would you verify domains if Atlassian trusts Okta to do Authentication and Authorization? It really doesn't make sense.

I really would like to know how you would solve this. More and more companies will connect to each other, it is simply not doable to do all these domain verification.

Please suggest some best practices.

Thanks,

Bert deRoos

Accepted answers

All comments

Daniel Ebers

Hi Eric or Bert,

are you at this point specifically referring to the article "Verify a domain for your organisation"?

https://confluence.atlassian.com/cloud/verify-a-domain-for-your-organization-873871234.html

Doing so this would require putting a TXT record to all relevant domains (all you want to verify).
There is an alternative uploading a HTML file - which is probably not better.

Am I getting you right that this is what you are currently tasked with and the steps are clear but you wonder why this is such a huge effort?
Let me share my experience - recently I verified four domains using DNS but working this out with IT staff went great.

On why the conception is like this with Okta I cannot say much. The validation itself was something I could understand (by means of the technical todos, as well as to why it is necessary) - but yes, a somewhat nicer way would also have been okay

Let me know if I misunderstood something.

Regards,
Daniel

Eric Karlinsky

Thanks Daniel,

Indeed I'm referring to the article you mentioned about verifying the domain and I understand what it technically means.

I foresee huge impact on the processes around it. we're setting up as integrator (dxc.com) a jira project for a large customer, xyz.com. Now, other 3rd parties need access as well, people from ibm.com, microsoft.com, oracle.com and accenture.com (this is the scale we're talking about)

Now as I understand correctly, to verify domains, I need to reach out to these global companies and ask them to adjust DNS record or add a HTML file to their website. Can you imagine the efforts, simply finding the right people, approvals and their willingness to do this?

I somehow can understand why initially Atlassian has created this idea of verifying domains but it is simply not doable anymore if you grow to a global scale in a connected world and it is blocking Jira deployments tremendously.

But maybe my interpretation is wrong and you can do it on a much easier way?

Thanks,

Bert

Daniel Ebers

The domains you mentioned (ibm, Microsoft, oracle, ...) do not need to be verified on your own instance - it will not be possible as they are not yours.

I assume the following is meant:

you verify the domain of the company your are working for so that they are in charge of all user accounts under this domain (exampleenterprises.tld)
you want to work together with ibm, Microsoft and so on - therefore they log in with their Atlassian-Accounts registered to their mail address (john.doe.xyz@ibm.com) into your cloud site

Dave Meyer

This is correct. Atlassian accounts can be used across multiple cloud tenants, so SSO is tied to the organization that owns the account. In this example, IBM would own @Inessa B.com accounts, and those accounts would authenticate with IBM's identity provider (Okta or an equivalent).

We are currently working on support directory syncing for external accounts (so if you have users in your identity provider that are external/on domains that you don't manage), those users will still sync as part of your groups, but authentication for those accounts would still be determined by the organization that manages the account.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

identity-manager