Identity & Access management in under 10 — Single Sign On
Before we head into this third blogpost of my series “Identity & Access Management in under 10”, which is about Single Sign On, have a look at previous post on Identity Providers.
What is Single Sign-On?
Single Sign-on (or SSO) is an authentication solution provided by IDPs. It allows your users to log in into different systems from one central location.
The problem
Imagine you are in charge of a rapidly growing company. You are onboarding and ofboarding users in different roles, using different tools for their day to day work.
Take the example of a software engineer. They might require access to Gitlab , AWS , Sentry , DataDog, …
On the other hand, you Sales reps might require access to Showpad, Salesforce, Zoom, …
As your company scales you have to
- keep track of which users are assigned to which apps
- keep track of whether your users are using your company guidelines when it comes to passwords requirements, authentication policies, … (might be impossible if the product you use does not allow configuring this)
- assign new employees all the apps they need to do their work
- ofboard employees from apps so they can’t access them anymore after they have left the company
And on top of that, for your employees it’s a hassle as well as they need to remember all the tools they might have at their disposal, all their passwords, … .
The added security risk here is that they will just end up reusing passwords, won’t have 2FA enabled if it’s not enforced, …
These are some examples that make it very clear that it becomes an administrative nightmare to deal with all of this if you can’t do it from a centralised place.
As I stated in the previous blogpost, an IDP might keep all your users stored in a central location but that in itself doesn’t do a whole lot, but it is a crucial building block to start using solutions for these problems.
The solution
So how does SSO really solve any of this? Let’s analyse this. step by step. In order to get to SSO, an IT Ops specialist has a little bit of setup to do.
First they invite all the employees or required people into their Okta Instance.
At that point, they will be placed into a set of groups depending on what makes sense for their organisation structure. In this case, it’s bound by job role.
Assigning users to groups is as simple as selecting a group (which gives you an overview of the users in it) and clicking the “Assign people” button to then add them.
At this point we have our users in the correct groups already. Now it’s just a matter of installing the necessary (if they have an Okta app) or creating your own with some of the templates provided. for purpose of this post let’s look at products that do offer an Okta app.
At this point you’ll see for example both Sentry (which engineers use) and Showpad (which Sales reps use).
Let’s assume all the configuration between the app and your IDP is done already (which is relatively simple for your IT Ops Specialist).
Depending on how this configuration is set up, you might end up having to set up an account in the app you are using with the same email as the user has in Okta or if the product you are using offers it, users might be provisioned Just-In-Time (JIT SSO). That means users are created into the system on first login through the IDP.
Because your IT Ops specialist set up the apps already and assigned your users to the correct groups, there is nothing more to do for them at this point other than assigning the groups to the app.
At this point, we’ve solved the first part the management side of things:
- keep track which users are assigned which apps ✅
- keep track of whether your users are using your company guidelines when it comes to passwords requirements, authentication policies ✅ (done indirectly by using an IDP)
- onboard new employees into the apps they need to do their work ✅
- ofboard employees from apps so they can’t access them with their credentials anymore to access data they are not allowed to see anymore ✅ (Done by deleting a user from your IDP)
how does this solve anything for employees?
At this point employees basically just need to log in into the IDP with their credentials (f.e. password they set up after being invited into the Okta instance, see below).
The password requirements, authentication flows, … can be tailored to your organisation’s requirements. So for example, you can enforce 2FA, security questions, password being longer than X, etc etc.
Once they have logged in (in this example, the Software Engineer), they will see all the apps they have assigned to them.
Clicking on an app will open it in a new browser tab and will automatically sign them in into the app through their Okta account!
Conclusion
While we skipped most of the technical aspects of SSO I hope the convenience for an employee and someone managing your organisation is clear (If you’re interested in the technical implementation between an IDP and an app, let me know!).
End users only have to log in once into the IDP and have access to all the apps that they are assigned, without having to deal with password policy requirements or keeping track of which apps they have access to.
For IT Ops specialists, the convenience of having a central place where they can manage all users, have a clear overview of their app directory as well as user directory and the relationship between those is extremely high.
