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
Many have their favorites. Okta. Azure AD. Auth0. It'd be nice to roll out a single vendor across the entire org.
A centralized identity infrastructure is in the wishlist for many enterprises, but it’s often times unreachable. In very simple terms, I like to say that reality is stubborn — and technology even more.
What are the critical limitations that enterprises find when they try to convert to a pure centralized model and a single source of identity? And why do we say so often that a single IdP model simply does not work and will not work for large, complex organizations?
I don’t have the final answer. Here are some considerations that I know come into play and that we see every week talking to customers at resolution.
Data Residency and regulations
Basically, you want to keep things separate to make sure that you comply with data residency regulations. In some cases, this means that each country should have a separate tenant of the Identity Provider, even if harmonization has come as far as to implement the single vendor across the board.
You can see how important an argument this is in the thread of comments to the request for multi-IdP support in Atlassian Access. Often times, it’s simply a blocker for cloud migrations.
Sometimes, harmonization is not as important as an organization’s legacy. The bigger a company, the more likely it is that a relatively large percentage of it has been built through mergers and acquisitions. With each M&A, the mother company inherits employees, know-how, customers, culture… and infrastructure. It’s simply not possible to make a blank slate and start from scratch.
The IT team may prefer to implement everything on OAuth, but be aware that many of their applications still need to make do with SAML. Or there may be a mandate to implement SCIM, but only a percentage of applications and directories can be rolled out under this project. Transformation goes step by step.
When loose works better
In other cases, there’s a conscious choice for a looser, decentralized structure over a centralized one that also reflects on how IT is organized and how information architecture is designed. More power for regional branches is usually tied to autonomous user directories, even when they (make an effort to) fall under the same policies and principles.
Smaller companies implement an SSO solution for their employees. Corporations must connect highly intricate collections of applications and devices to offer SSO solutions to employees, consultants, partners, customers, and other stakeholders.
Many of those constituencies will have their identities stored outside the org’s assets, and will have to play by a set of very specific rules.
What are other considerations that you have discussed in your team? Do you find that the Atlassian Data Center SSO support for Multiple Identity Providers offers enough in its current stage for you to meet your goals?
Somewhere else in the community I have discussed other possible methods to select and trigger the relevant IdP that might be interesting to look at for anyone considering this move.