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.
Capi _resolution_Community Leader
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events