Critical Limitations to Centralizing in a Single Identity Provider

[#1]

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.

History matters

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.

User Centricity

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.

Other issues?

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.

[Simone Avogadro]

Since our company has a strong take on the "Single Identity Provider" I really enjoyed this post. Thanks @Capi [resolution] for this lucid analysis!

Over the time awareness toward singe-identity and more broadly over identity management has increased. Security is a thing and mergers and acquisitions don't always end up with a "single system" approach. All of this points to a simple, key concept: federation!

Currently Atlassian Access does not provide federation features but this does not mean that a large company cannot implement it: our approach here is that if the corporation needs to use Okta in the US and ADFS in the EU then we add an on-top IDP which will be appropriately routing users to the currect regional IDP and then function as a proxy towards the client (Atlassian Access here).

IDP proxing+federation is a thing exactly for the reasons that you mentioned:

• customer has multiple IDPs but not all the cloud services support that directly
• customer wants to go for OAuth (or rather OpenID Connect) but the service supports only SAML federation
• customer does want to expose only a subset of his users/attributes to the SaaS cloud

all of this poits toward a middle layer to manage the intermediation. We've seen this with API Management, WAF , Message Queues etc... and now we're seeing it in the IDM/SSO field.

The issue here is the lack of a cheap/free out of the box solution: large corporates can affort to shell out 50k to implement such a system but smaller companies simply don't have that budget: not even for the whole cloud migration journey! That's exactly why the current journey to the cloud will see us lose mid-small customers to other options.

[Capi [resolution]]

Ciao Simone! Grazie per i commenti!

You make a very strong argument for federation and raise a last and very critical limitation with the unaffordable pricing. Let's see, as you say more and more companies are seeing IDM as a core piece of their strategy, so perhaps we'll find new vendors filling in the gaps for those smaller customers.

[Simone Avogadro]

grazie a voi!

More generally mid-small customers will smoothly transition to the cloud when they don't have customizations/special requirements.
Those customres will simply adapt to the new CX and maybe drop/change some workflows, obtaining all the advantages of the cloud in the process and thus maximising product usage.

Mid-small customers which had on-premise custom plugins, scripting heavy customizations, fragmented installations (jira, confluence, bitbucket with different users sets etc...) will usually just stay on Server until EOL and hope that something happens in the meantime or otherwise plan phase out. We'll see if the cloud will be ready to bring them in 2 years from now!

To us the #1 showstopper is usually the lack of the power of ScriptRunner, which might land in the cloud before those customers need to make their choice ! :-)

[John Fetzik]

My organization has always used the cloud versions of Atlassian apps. We are a medium sized manufacturing company and two things have slowed our adoption of SSO with Atlassian.

First is cost. Management here is very sensitive to pricing. For many other systems we use SSO with AzureAD is included with the base price, at no extra cost.

Second, is how to handle guest users that are not part of our organization. Once again cost comes into play. Adding guests into AzureAD has a cost. Using a third party identity provider adds cost. And as mention we are cost sensitive.

[Capi [resolution]]

Thanks for your comment, John! Yes, handling guest users can be both expensive and complex. 

It does seem that right now a strong Identity Management program with Atlassian tools has quite a price tag, no matter whether you look at cloud or at on-prem, where we have our stronghold. 

[Jack Brickey]

Great article @Capi [resolution]

After spending 30+ years in telecom much of which was focused on high availability solutions I can certainly appreciate the importance of not losing access to any critical service.

[Capi [resolution]]

Thanks for the praise and for the comment, @Jack Brickey!

Do you feel that there are implications for availability in not having a centralized identity architecture? Or can you offer the same level of access with parcels of Identity Providers for different sets of users?

[Jack Brickey]

Fair question @Capi [resolution] . I can’t say definitively but my educated guess is that a decentralized solution could certainly work. I can’t see why it would not. The only potential downside would be the complexity of such a solution. That is, having multiple identity providers adds complexity I would think. At the same time my experience shows that high availability solutions always present complexity challenges.

[Simone Avogadro]

@Capi [resolution]  care for a brief call about that? can you share and e-mail where I can contact you?

[Capi [resolution]]

Always happy to learn from the experts, @Simone Avogadro . You can write me a message to j.capitel@resolution.de

[M Amine]

Thank you @Capi [resolution] for this article