You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
We are part of a family of organizations that all share the same domain name for email addresses. Let's say we have a domain example.com and Company 1's users are email@example.com but Company 2's users are also firstname.lastname@example.org.
If we are Company 2 and we use Atlassian Access the way the documentation is written we will have to claim example.com as our domain. This will involve all Atlassian accounts for Company 1 and Company 2 becoming managed users for us. (I have verified this with Atlassian billing support. They say that we would have Company 1 users as billable accounts if they had access to any managed product, not just those belonging to Company 2's Atlassian account.)
I can potentially get all our users to have an alternate email address on their Active Directory accounts so they would be email@example.com and firstname.lastname@example.org. I could then claim example2.com as our domain. But can Atlassian Access (with Okta) support passing along the email address to the identity provider as an alternate email address and have the logging in still work?
Unfortunately as best I can tell, this doesn't work. Okta does not allow users to authenticate with the secondary email. So if the user attempted to log in to with Atlassian with email@example.com and you had verified the example2.com domain, it would certainly be redirected to Okta. However, the user would only be able to log in to Okta with their firstname.lastname@example.org, which is what Okta would send back to Atlassian and the SAML assertion would fail, since email@example.com would not match any user in Atlassian.
We are definitely aware that there are cases where several companies share the same domain and that the domain-based implementation of SAML that Atlassian Access usage is a problem in this situation. We'll be looking at how we can resolve this in the future.
Atlassian Access Product Management
Hi @Dave Meyer, after talking with our Okta people it looks like this should actually be possible. They said that as long as we can get our users to have two valid emails (firstname.lastname@example.org and email@example.com) then they can support it.
Basically we would register example2.com with Atlassian and make all our users update their email addresses to that (unfortunately it seems there is no bulk way to do this). Then we would turn on Atlassian Access for example2.com.
In the Okta configuration for the Atlasisan connection they would enable a simple rewrite so that when sending back the email address of the authenticated user to Atlassian it will change it from firstname.lastname@example.org (their _actual_ username) to email@example.com (what Atlassian thinks the username is). Then because they can receive email at example2.com the notifications would also continue to work.
We're going to give it a try and I will report back in a couple of months.
We actually do provide an API for you, as an admin, to update users' email addresses in your organization:
In the Okta configuration for the Atlasisan connection they would enable a simple rewrite so that when sending back the email address of the authenticated user to Atlassian it will change it from firstname.lastname@example.org (their _actual_ username) to email@example.com (what Atlassian thinks the username is).
I didn't know this was possible. That's great to hear!
The only caveat here is that if users log in to Atlassian directly (rather than via the Okta dashboard) I think they will need to know to enter their @example2.com email address on the Atlassian account login screen.
Yeah, the support rep mentioned that. Problem is that to use it we would have to claim example.com in order to be able to leverage the organizations API in order to change their email addresses to example2.com. And claiming example.com is part of the problem in the first place!