Identity & Access management in under 10 — Identity Providers
Before we head into this second blogpost of my series “Identity & Access Management in under 10”, which is about identity providers, have a look at my introduction and what I want to achieve with this series!
What is an Identity Provider (IDP)?
A technical definition for an Identity Provider could be: A system, either built or bought from a vendor, which allows you to manage the lifecycle and metadata of your principals and offer services for those principals.
In layman’s terms this means: Companies use identity providers to centrally store their user information. when we talk about users, these are almost always, but not necessarily, their employees. Keep that in mind going forward in this post.
Think of it like a school registry that keeps track of all students, teachers, staff, … and on top of that what classes they are in, which faculty, which department, … .
You might have heard Azure Entra ID, Okta, … . These are Identity Providers.
From here on out I will be referring to Identity Providers as IDPs.
Why should we use an IDP solution?
Storing your users (and other principals, but let’s keep it at users for the scope of this blog post) centrally is one thing but by itself doesn’t solve a problem for your company.
That is where the second part of the technical definition - offer services for those principals - kicks in.
IDPs offer services that bring immediate value next to storing your users. A few of these services could be
Configurable password requirements and authentication policies such as Multi Factor Authentication (MFA), group based authentication policies, mandatory password resets, … . With this, you can set up authentication flows that work for your company and your compliance requirements. This is a great way to have a low effort, high reward protection layer for your company against cyber threats.
Once your users have set up a password based on the password requirements your defined and other actions they might need to take, they can now use Single Sign On (SSO) which allows them to sign into all their tools with their IDP credentials. This requires some configuring by the company’s IT team but IDPs tend to have a marketplace where tools like Showpad offer an app to make the setup for this a lot easier.
Continuous user provisioning from your IDP into the tools. This means that new users who are onboarded into the IDP and assigned certain tools will have an account based on their email created into those tools. For example, if you have a “Sales rep group”, and you have configured a continuous sync between this group and the Showpad app, any new sales rep will have an account automatically created in Showpad. Later, they will be able to use SSO as mentioned before to log in.
Device Management, to keep track of devices, software versions, pushing OTA (over the air) updates and many more.
We’ll go into detail on some of these services in later blog posts but I already wanted to highlight these.
When you look at a few of these services it shows that the power of an IDP is easy management for IT teams and the ability to enforce best practices so your company is always in line with required compliances and can act swiftly on potential threats or efficiently do general tasks like on/off boarding users, … .
I want to add that companies who built their own IDP will generally need to figure out how to implement these services themselves or will decide they don’t need (all) these services.
Build vs Buy
You might be wondering what the best solution is for your company at this point. Build your own system or buy a solution from a vendor? Below I’ve listed topics that are crucial when considering your options.
Financial Cost
Third party systems costs money and those will likely scale with your company’s size. You might not need all of the things a vendor has to offer while you do pay for them. Look at pricing plans and what features you really need determine if a vendor is an option to start with.
Calculating the direct financial impact of any built systems is more difficult, but together with the technical cost you might be able to roughly estimate this.
Technical Cost
The technical cost for a buy system should be close to 0 because the vendor manages all of it. They might require you occasionally to change some configuration or might deprecate features as part of their effort to modernise their system but generally they will try to avoid this. Scalability, security issues and maintenance overhead is taken care of by them.
In a build system, all of this falls on the company itself. This means you are required to have this knowledge in house and assign a specific group of people to maintain and scale this system.
Requirements
Vendors interact with a broad range of companies and because of that have dealt with a diverse set of problems for which they have solutions in their product. It’s likely they have all the tools you need to satisfy the requirements you have.
It’s always possible that they you have very specific needs. This will most of the time have to do with compliance and potentially laws in the countries in which you operate. In that case, a vendor might not be adequate.
Be critical of your process and needs here. What are actual requirements for your business, and which needs are legacy process overhead? It’s ok to come back on something that was decided in the past but is not relevant anymore today!
Company Structure
Most company structures are relatively simple. Its workforce consists of departments and with a simple (or sometimes slightly more complicated…) group structure, you can satisfy your company’s structure in a third party IDP.
However, this isn’t always the case as I’ve experienced in my interactions with companies. For example, some companies might have a central control structure, but have specific independent dealers that they can not/will not centrally manage for specific reasons.
Other companies might require individuals to onboard into their platforms but with personal email addresses and don’t want these in their IDP.
In these cases, an IDP and the services they offer might not bring you all the value you need and you could end up managing multiple systems to get everything working.
My opinionated conclusion
Use a vendor like Okta or Azure Entra ID instead of building your own solution unless it’s absolutely necessary. Even then, check with these vendors if they can cover your use case.
Most in house systems I’ve seen today are from companies who have scaled over years or decades. The historical context in this case is important as these companies very likely started on these tools before vendors became mainstream and reliable. They have their internal system which they’ve invested in for a long time and which run stable for them. In this case, changing to an IDP initially could be a big investment for these companies. However, for companies that are flexible and can afford such a migration, it feels like a no brainer. It’s just not a choice new companies really make today anymore unless for very specific reasons.
It’s also very unlikely this a differentiator for your business. If you do not have any historical requirements, just let companies who make it their core business deal with the complexities so you can focus on the real thing: The customer value you want to bring.
