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
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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 must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Many thanks, good to hear that it should be much easier than I initially thought.
So, the steps are then:
1. verify the domain we're working for, in our case exampleenterprises.tld. Verifying this domain enable the possibility in Atlassian Access to setup SSO integration with Okta
2. Integrate with Okta. Okta will be used to perform MultiFactor Authentication
3. Users from exampleenterprises.tld and ibm.com (e.g. john.doe.xyz@ibm.com), authenticated by Okta, should have access to Atlassian.
As you work on "directory syncing for external accounts" it is currently not possible to provisioning users from external domain e.g. ibm.com, this has to done manual, right?
Do you know when this feature comes available?
Thanks,
Bert
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Bert deRoos ,
verify the domain we're working for, in our case exampleenterprises.tld. Verifying this domain enable the possibility in Atlassian Access to setup SSO integration with Okta
Correct
Users from exampleenterprises.tld and ibm.com (e.g. john.doe.xyz@ibm.com), authenticated by Okta, should have access to Atlassian.
This will depend on what security policies the owner of those domains has configured on the account. We are also about to release a new feature that will show you (as a content owner) whether these external users are logging in with SSO or 2SV, even though you don't control it.
As you work on "directory syncing for external accounts" it is currently not possible to provisioning users from external domain e.g. ibm.com, this has to done manual, right?
Yes you can follow the instructions for inviting users to your Jira instance here. And you can create and use local Atlassian groups with these users.
Do you know when this feature comes available?
We are generally targeting the end of this calendar year.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Dave,
We'll start to setting everything up, so hopefully everything works as expected :)
Best Regards,
Bert
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.